mysql limit pagination
¿Hay algún punto usando MySQL "LIMIT 1" cuando se consulta en el campo indexado/único? (4)
Por ejemplo, estoy consultando un campo que sé que será único y está indexado, como una clave principal. Por lo tanto, sé que esta consulta solo arrojará 1 fila (incluso sin el LIMIT 1)
SELECT * FROM tablename WHERE tablename.id=123 LIMIT 1
o solo actualiza 1 fila
UPDATE tablename SET somefield=''somevalue'' WHERE tablename.id=123 LIMIT 1
¿Agregar el LIMIT 1 mejoraría el tiempo de ejecución de la consulta si el campo está indexado?
¿Hay algún punto usando MySQL "LIMIT 1" cuando se consulta en la clave principal / campo único?
No es una buena práctica usar LIMIT 1 cuando consulta con criterios de filtro que están en contra de una clave principal o restricción única. Una clave principal, o restricción única, significa que solo hay una fila / registro en la tabla con ese valor, solo se devolverá una fila / registro. Es contradictorio tener el LIMIT 1 en una clave principal / campo único: alguien que mantenga el código más tarde podría confundir la importancia y adivinar su código.
Pero el indicador final es el plan de explicación:
explain SELECT t.name FROM USERS t WHERE t.userid = 4
...devoluciones:
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
-----------------------------------------------------------------------------------------------------
1 | SIMPLE | users | const | PRIMARY | PRIMARY | 4 | const | 1 |
...y:
explain SELECT t.name FROM USERS t WHERE t.userid = 4 LIMIT 1
...devoluciones:
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
-----------------------------------------------------------------------------------------------------
1 | SIMPLE | users | const | PRIMARY | PRIMARY | 4 | const | 1 |
Conclusión
Sin diferencias, sin necesidad. Parece optimizado en este caso (solo buscando contra la clave primaria).
¿Qué pasa con un campo indexado?
Un campo indexado no garantiza la exclusividad del valor que se filtra, puede haber más de una ocurrencia. Entonces, el LIMIT 1 tendría sentido, suponiendo que quieras devolver una fila.
Dado que la consulta solo devolverá, en cualquier momento dado, un registro; entonces la adición de LIMIT 1 no aumentará su tiempo de ejecución.
No estoy seguro de qué algoritmo MySQL usa para realizar solicitudes LIMIT 1 . Por irónico que sea, puede usar expresiones de comparación o iteradores para devolver solo 1 registro, en cuyo caso, la adición de LIMIT 1 puede demorar el tiempo de ejecución por varias instrucciones.
En la mayoría de los casos en los que realizo consultas en campos únicos, sigo utilizando el LIMIT 1 . Principalmente hago esto porque quiero asegurarme de que no importa lo que alguien haga con la base de datos / tablas, mi consulta nunca regresará ni manipulará más de una fila.
Por lo general, esto también debería cubrir el caso de una consulta malformada dinámicamente para desordenar la base de datos completa (y no, no estoy hablando de inyección de SQL).
Si el campo tiene un índice único, no puedo ver este tiempo de ejecución de mejora en absoluto, es un tramo incluso para los estándares de micro-optimización.
Sin embargo, puedo verlo potencialmente enmascarando otros problemas. Supongamos que agrega el LÍMITE 1 a estas consultas, y de alguna manera el campo sobre el que está consultando pierde su índice único y el archivo db obtiene varias filas con el mismo valor. Este código seguirá traqueteando felizmente. Creo que en lugar de eso, podrías querer fallar rápido para darte cuenta (y corregir) el problema subyacente más grande.
En mi propio código de interfaz db, tengo un método queryOneRow () que ejecuta algunos SQL y arroja una excepción si obtiene más de una fila. Para mí, tiene más sentido manejar esto explícitamente en la capa de aplicación en lugar de defenderse en SQL.