Vous devez essentiellement placer ces requêtes dans des procédures stockées en raison de certaines limitations sur LIMIT . Vous ne pouvez pas utiliser de sous-sélections ou de variables dans sql ordinaire. Dans les procédures stockées, vous pouvez utiliser des variables.
Cela fonctionne, malheureusement je ne peux pas le montrer dans sqlfiddle car ils semblent avoir un support limité pour les procédures stockées.
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();
Élaboration sur les index clusterisés InnoDB
Après des discussions dans l'une des autres réponses avec @fthiella, j'ai décidé d'élaborer sur la façon dont cela peut fonctionner.
Une table utilisant InnoDB comme moteur aura toujours un index clusterisé. Toujours. C'est ainsi que les données sont stockées dans InnoDB et il n'est en aucun cas possible de créer une table sans index clusterisé.
InnoDB choisira la clé primaire s'il existe un ou le premier index unique avec toutes les colonnes définies sur non nulles. Si aucun index de ce type n'existe, InnoDB créera une colonne masquée avec un identifiant de ligne. Cet identifiant de ligne fonctionne de la même manière que l'incrémentation automatique et s'il est utile de le considérer comme une colonne invisible avec incrémentation automatique, je pense que c'est bien.
De plus, InnoDB renverra des lignes en fonction de l'index utilisé. Il utilisera toujours un index (le seul moyen de récupérer des données est d'utiliser un index secondaire, l'index clusterisé ou une combinaison), donc dans le cas où il n'y a pas d'index créés explicitement, les lignes sont renvoyées par l'index clusterisé caché.
Cela signifie qu'une requête sur une table sans clé primaire et sans index unique avec toutes les colonnes définies sur non nulles et sans ORDER BY renverra les lignes dans l'ordre dans lequel elles ont été insérées.
C'est le cas pour cette question et la base de la mienne et de nombreuses autres réponses.
Je ne veux pas dire que c'est une bonne façon de travailler avec les données. Voici quelques éléments auxquels vous devriez penser avant d'utiliser cette solution :
- Si un index pouvant être utilisé comme index clusterisé est créé, la table sera réécrite pour utiliser cet index et, ce faisant, ordonnera les données sur le disque. Si l'index est supprimé ultérieurement, l'ordre d'insertion d'origine est perdu et ne peut pas être récupéré.
- Si un index est créé, même s'il n'est pas unique, il peut être choisi par l'optimiseur pour être utilisé et les lignes seront triées par cet index à la place.
Tout ceci est documenté et pour la 5.5 c'est le 3e point sur cette page
