Bepaal de laatste rij die is toegevoegd als er geen index aanwezig is

Nee, er is geen vooraf gedefinieerde functie in SQL Server die de "laatste rij" van een tabel retourneert.

Een tabel is per definitie een ongeordende reeks rijen. Stel je voor dat je een bos knikkers in een zak gooit. Open nu de zak en vraag iemand anders welke knikker er als eerste of als laatste in is gegaan. Gooi ze nu allemaal op de grond, en als iemand anders de kamer binnenkomt, vraag dan welke de vloer het eerst of het laatst raakt. Je kunt het niet doen, omdat er geen aanvullende informatie is die iets aangeeft over de volgorde waarin ze zijn gevallen.

Hetzelfde geldt voor een tabel in SQL Server. Tenzij u een IDENTITY-kolom of een datetime-kolom of een trigger toevoegt, of externe functionaliteit gebruikt zoals het bijhouden van wijzigingen, CDC, auditing, enz., kan SQL Server u niet vertellen welke rij het laatst is ingevoegd. Je zou kunnen denken dat gewoon selecteren uit de tabel zonder een volgorde op clausule lijkt alsof het gegevens in de juiste volgorde retourneert, dit is puur toeval. Hier is een voorbeeld:

CREATE TABLE dbo.floobat
(
  ID INT PRIMARY KEY, 
  n VARCHAR(16), 
  x CHAR(4000) NOT NULL DEFAULT ''
);

INSERT dbo.floobat(ID,n) VALUES(1,'Sparky');
INSERT dbo.floobat(ID,n) VALUES(2,'Aaron');
INSERT dbo.floobat(ID,n) VALUES(3,'Norbert'); -- <-- inserted last

SELECT ID, n FROM dbo.floobat;

Ok, dus standaard lijkt dit in orde te zijn. Resultaten:

ID    n
--    -------
1     Sparky
2     Aaron
3     Norbert -- < yes, this is right

Laten we echter een wijziging aanbrengen in de tabel waarvan uw toepassing of wat dan ook afhankelijk is van de bovenstaande volgorde, geen idee heeft:

CREATE NONCLUSTERED INDEX x ON dbo.floobat(n);

SELECT ID, n FROM dbo.floobat;

Oh Oh! Resultaten:

ID    n
--    -------
2     Aaron
3     Norbert
1     Sparky -- < oops, this is no longer right

U moet dit onthouden:als u geen ORDER BY-clausule opneemt, vertelt u SQL Server dat je niet om orde geeft. Het gaat dus de meest efficiënte manier vinden om de gegevens te retourneren, en dat zou kunnen leiden tot een andere waargenomen volgorde. Door de bovenstaande index toe te voegen, kreeg SQL Server een beter toegangspad om de gegevens op te halen. Het gebruikte nog steeds een scan, maar die index was veel dunner dan de geclusterde index (die maar op twee rijen op een pagina kon passen).

Zelfs zonder de index zou je waarschijnlijk niet de resultaten krijgen die je verwacht, omdat het ingewikkeld is door het feit dat je Cust_ID kolom wordt niet in oplopende volgorde ingevoegd. Dus als u 5 . invoegt en dan 2 , selecteren zonder ORDER BY resulteert in 2 dan 5 (ervan uitgaande dat er geen betere index bestaat).

Andere dingen dan het maken (of verwijderen, wijzigen of herbouwen) van een index kunnen dezelfde soort verandering in het bestelgedrag veroorzaken. Een servicepack, CU of hotfix toepassen; de procedurecache leegmaken; verschillende RECOMPILE-opties gebruiken; het bijwerken van statistieken; het herstarten van de server; een traceringsvlag toevoegen of uitschakelen; opties voor een serveroptie wijzigen; het verplaatsen van de database naar een andere server; enz. enz.

Dus als u deze informatie wilt bijhouden, moet u deze op de een of andere manier zelf toevoegen, zoals in verschillende van de andere antwoorden is aangegeven.