Grundsätzlich müssen Sie solche Abfragen in gespeicherte Prozeduren aufgrund einiger Einschränkungen bei LIMIT . Sie können keine Unterauswahlen oder Variablen in einfachem SQL verwenden. In gespeicherten Prozeduren können Sie Variablen verwenden.
Das funktioniert, leider kann ich es nicht in sqlfiddle anzeigen weil sie anscheinend nur begrenzte Unterstützung für gespeicherte Prozeduren haben.
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();
Ausarbeitung zu InnoDB Clustered Indexes
Nach Diskussionen in einer der anderen Antworten mit @fthiella habe ich beschlossen, einiges darüber zu erläutern, wie dies funktionieren kann.
Eine Tabelle, die InnoDB als Engine verwendet, hat immer einen Clustered-Index. Stets. Auf diese Weise werden Daten in InnoDB gespeichert und es ist auf keinen Fall möglich, eine Tabelle ohne Clustered-Index zu erstellen.
InnoDB wählt den Primärschlüssel, wenn es einen oder den ersten eindeutigen Index gibt, bei dem alle Spalten auf nicht null gesetzt sind. Wenn kein solcher Index existiert, erstellt InnoDB eine versteckte Spalte mit einer Zeilen-ID. Diese Zeilen-ID funktioniert ähnlich wie die automatische Inkrementierung, und wenn es hilft, sie als unsichtbare Spalte mit automatischer Inkrementierung zu betrachten, denke ich, dass das in Ordnung ist.
Außerdem gibt InnoDB Zeilen gemäß dem verwendeten Index zurück. Es wird immer ein Index verwendet (die einzige Möglichkeit zum Abrufen von Daten besteht darin, entweder einen sekundären Index, den Clustered-Index oder eine Kombination davon zu verwenden). Wenn also keine explizit erstellten Indizes vorhanden sind, werden Zeilen vom Hidden Clustered-Index zurückgegeben.
Dies bedeutet, dass eine Abfrage einer Tabelle ohne Primärschlüssel und ohne eindeutige Indizes, bei der alle Spalten auf nicht null und ohne ORDER BY gesetzt sind, Zeilen in der Reihenfolge zurückgibt, in der sie eingefügt wurden.
Dies ist der Fall für diese Frage und die Grundlage für meine und viele andere Antworten.
Ich will damit nicht sagen, dass dies eine gute Möglichkeit ist, mit den Daten zu arbeiten. Hier sind einige Dinge, die Sie bedenken sollten, bevor Sie diese Lösung verwenden:
- Wenn jemals ein Index erstellt wird, der als Clustered-Index verwendet werden kann, wird die Tabelle neu geschrieben, um diesen Index zu verwenden und dadurch die Daten auf der Festplatte zu ordnen. Wenn der Index später gelöscht wird, geht die ursprüngliche Insert-Reihenfolge verloren und kann nicht wiederhergestellt werden.
- Wenn ein Index erstellt wird, auch wenn er nicht eindeutig ist, kann er vom Optimierer zur Verwendung ausgewählt werden, und die Zeilen werden stattdessen nach diesem Index geordnet.
All dies ist dokumentiert und für 5.5 ist es der 3. Aufzählungspunkt auf diese Seite
