Du skal grundlæggende lægge sådanne forespørgsler ind i lagrede procedurer på grund af nogle begrænsninger på LIMIT . Du kan ikke bruge undervalg eller variabler i almindelig sql. I lagrede procedurer kan du bruge variabler.
Dette virker, jeg kan desværre ikke vise det i sqlfiddle fordi de ser ud til at have begrænset støtte til lagrede procedurer.
drop procedure if exists all_but_3;
delimiter //
create procedure all_but_3()
begin
declare v_max bigint unsigned default ~0;
select * from your_table limit 3, v_max;
end//
delimiter ;
drop procedure if exists last_3;
delimiter //
create procedure last_3()
begin
declare v_max bigint;
declare v_mid bigint;
select count(*) from your_table into v_max;
set v_mid := v_max - 3;
select * from your_table limit v_mid, v_max;
end//
delimiter ;
call all_but_3();
call last_3();
Udarbejdelse af InnoDB Clustered Indexes
Efter diskussioner i et af de andre svar med @fthiella har jeg besluttet at uddybe lidt om, hvordan dette kan fungere.
En tabel, der bruger InnoDB som motor, vil altid have et klynget indeks. Altid. Det er den måde, data gemmes i InnoDB, og det er på ingen måde muligt at oprette en tabel uden et klynget indeks.
InnoDB vil vælge den primære nøgle, hvis der er et eller det første unikke indeks med alle kolonner sat til ikke null. Hvis der ikke findes et sådant indeks, vil InnoDB oprette en skjult kolonne med et række-id. Dette række-id fungerer på samme måde som automatisk stigning, og hvis det hjælper at tænke på det som en usynlig kolonne med automatisk stigning, synes jeg, det er fint.
Yderligere vil InnoDB returnere rækker i henhold til det anvendte indeks. Det vil altid bruge et eller andet indeks (den eneste måde at hente data på er at bruge enten et sekundært indeks, det klyngede indeks eller en kombination), så i tilfældet hvor der ikke er nogen eksplicit oprettede indekser, returneres rækker af det skjulte klyngeindeks.
Det betyder, at en forespørgsel mod en tabel uden primær nøgle og uden unikke indekser med alle kolonner sat til ikke null og ingen ORDER BY vil returnere rækker i den rækkefølge, de blev indsat.
Dette er tilfældet for dette spørgsmål og grundlaget for mit og mange andre svar.
Jeg mener ikke at sige, at dette er en god måde at arbejde med data på. Her er nogle ting, du bør tænke over, før du bruger denne løsning:
- Hvis der nogensinde bliver oprettet et indeks, der kan bruges som et klynget indeks, vil tabellen blive omskrevet til at bruge det indeks og ved at gøre det sortere dataene på disken. Hvis indekset senere slettes, går den oprindelige indsættelsesrækkefølge tabt og kan ikke genfindes.
- Hvis et indeks oprettes, selvom det ikke er unikt, kan det vælges af optimeringsværktøjet, der skal bruges, og rækkerne vil i stedet blive sorteret efter det indeks.
Alt dette er dokumenteret, og for 5.5 er det 3. punktopstilling på denne side