Básicamente, debe colocar dichas consultas en procedimientos almacenados debido a algunas limitaciones en LIMIT . No puede usar selecciones secundarias o variables en sql simple. En los procedimientos almacenados puede usar variables.
Esto funciona, desafortunadamente no puedo mostrarlo en sqlfiddle porque parecen tener soporte limitado para procedimientos almacenados.
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();
Elaboración de índices agrupados de InnoDB
Después de las discusiones en una de las otras respuestas con @fthiella, decidí elaborar un poco sobre cómo puede funcionar esto.
Una tabla que use InnoDB como motor siempre tendrá un índice agrupado. Siempre. Es la forma en que se almacenan los datos en InnoDB y de ninguna manera es posible crear una tabla sin un índice agrupado.
InnoDB elegirá la clave principal si hay uno o el primer índice único con todas las columnas configuradas como no nulas. Si no existe tal índice, InnoDB creará una columna oculta con una identificación de fila. Esta identificación de fila funciona de manera similar al incremento automático y si ayuda pensar en ella como una columna invisible con incremento automático, creo que está bien.
Además, InnoDB devolverá filas de acuerdo con el índice utilizado. Siempre usará algún índice (la única forma de recuperar datos es usar un índice secundario, el índice agrupado o una combinación), por lo que en el caso de que no haya índices creados explícitamente, el índice agrupado oculto devuelve las filas.
Esto significa que una consulta en una tabla sin clave principal y sin índices únicos con todas las columnas configuradas como no nulas y sin ORDER BY devolverá las filas en el orden en que se insertaron.
Este es el caso de esta pregunta y la base de la mía y muchas otras respuestas.
No quiero decir que esta sea una buena manera de trabajar con los datos. Aquí hay algunas cosas en las que debe pensar antes de usar esta solución:
- Si alguna vez se crea un índice que se puede usar como índice agrupado, la tabla se reescribirá para usar ese índice y, al hacerlo, ordenará los datos en el disco. Si el índice se descarta más tarde, el orden de inserción original se pierde y no se puede recuperar.
- Si se crea un índice, incluso si no es único, el optimizador podría elegirlo para usarlo y las filas se ordenarán por ese índice en su lugar.
Todo esto está documentado y para 5.5 es la tercera viñeta en esta página
