Zasadniczo musisz umieścić takie zapytania w procedurach przechowywanych ze względu na pewne ograniczenia LIMIT . Nie możesz używać subselekcji ani zmiennych w zwykłym sql. W procedurach składowanych można używać zmiennych.
To działa, niestety nie mogę tego pokazać w sqlfiddle ponieważ wydaje się, że mają ograniczone wsparcie dla procedur składowanych.
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();
Opracowanie indeksów klastrowych InnoDB
Po dyskusjach na temat jednej z innych odpowiedzi z @fthiella postanowiłem wyjaśnić, jak to może działać.
Tabela używająca InnoDB jako silnika zawsze będzie miała indeks klastrowy. Zawsze. W ten sposób dane są przechowywane w InnoDB i nie jest w żaden sposób możliwe utworzenie tabeli bez indeksu klastrowego.
InnoDB wybierze klucz podstawowy, jeśli istnieje jeden lub pierwszy unikalny indeks ze wszystkimi kolumnami ustawionymi na wartość niezerową. Jeśli taki indeks nie istnieje, InnoDB utworzy ukrytą kolumnę z identyfikatorem wiersza. Ten identyfikator wiersza działa podobnie do automatycznego przyrostu i jeśli pomaga myśleć o nim jako o niewidocznej kolumnie z automatycznym przyrostem, myślę, że to w porządku.
Ponadto InnoDB zwróci wiersze zgodnie z użytym indeksem. Zawsze będzie używał jakiegoś indeksu (jedynym sposobem pobierania danych jest użycie indeksu dodatkowego, indeksu klastrowego lub kombinacji), więc w przypadku, gdy nie ma jawnie utworzonych indeksów, wiersze są zwracane przez ukryty indeks klastrowy.
Oznacza to, że zapytanie dotyczące tabeli bez klucza podstawowego i unikatowych indeksów ze wszystkimi kolumnami ustawionymi na wartość nie null i bez ORDER BY zwróci wiersze w kolejności ich wstawienia.
Tak jest w przypadku tego pytania i podstawy dla moich i wielu innych odpowiedzi.
Nie chcę przez to powiedzieć, że to dobry sposób na pracę z danymi. Oto kilka rzeczy, o których powinieneś pomyśleć przed użyciem tego rozwiązania:
- Jeśli kiedykolwiek zostanie utworzony indeks, który może być używany jako indeks klastrowy, tabela zostanie przepisana, aby używać tego indeksu i dzięki temu uporządkować dane na dysku. Jeśli indeks zostanie później usunięty, pierwotna kolejność wstawiania zostanie utracona i nie będzie można jej odzyskać.
- Jeśli tworzony jest indeks, nawet jeśli nie jest unikalny, optymalizator może go wybrać, a wiersze zostaną uporządkowane według tego indeksu.
Wszystko to jest udokumentowane i dla wersji 5.5 jest to trzeci punkt na ta strona
