Tengo una tabla con columnas de esta manera:Optimización de MySQL "así como" vs "="
| Country.Number | CountryName |
| US.01 | USA |
| US.02 | USA |
me gustaría modificar esto para:
| Country | Number | CountryName |
| US | 01 | USA |
| US | 02 | USA |
En cuanto a la optimización, es allí una diferencia en el rendimiento si uso:
select * from mytable where country.number like "US.%"
o
select * from mytable where country = "US"
La diferencia de rendimiento probablemente sea minúscula en este caso particular, ya que mysql usa un índice en "US.%". La degradación del rendimiento se siente principalmente cuando se busca algo como "%.US" (el comodín está al frente). Como lo hace un tablescan sin usar índices.
EDITAR: se puede ver en ello como esto:
MySql internamente tiendas varchar índices como los árboles con primer símbolo siendo la raíz y la ramificación a cada letra siguiente.
Por lo tanto, al buscar = "US" busca , luego baja un paso para S y luego otro para asegurarse de que ese es el final del valor. Eso es tres pasos.
Buscando LIKE "US.%" se ve de nuevo por U, entonces S, entonces . y luego se detiene la búsqueda y muestra los resultados - que también está a sólo tres pasos, ya que no le importa si el valor termina allí.
EDIT2: No estoy de ninguna manera promoviendo la desnormalización de la base de datos, solo quería llamar su atención que este asunto puede no ser tan directo como parece a primera vista.
La consulta más adelante:
select * from mytable where country = "US"
debería ser mucho más rápido Debido a que MySQL no tiene que buscar patrones comodines a diferencia LIKE consulta. Simplemente busca el valor que se ha ecualizado.
Creo que estás equivocado. No busca patrones, pero usa el índice para los primeros tres caracteres e inmediatamente muestra el resultado. Eso puede ser más rápido que '=" US "' pero no * mucho *. – raveren
Simplemente ejecutando consultas manuales obtuve algunos resultados bastante anómalos. En el primer par de consultas, '=' tomó _17.49s_ contra 19.18s para 'like'. En la segunda ejecución, fue 3.20s contra _0.42s_. Y en la 3ª ejecución, _0.39s_ contra 0.42s. En cada ejecución después de que ambas consultas tomaron 0,41s o 0,39 segundos para ejecutar, sin ventajas para las consultas después de 10 conjuntos adicionales de consultas. Supongo que necesitarás usar un generador de perfiles como sugiere Piskvor para obtener resultados más definitivos. Pero esta es probablemente una micro-optimización innecesaria en la mayoría de los casos. –
Use 'SELECT sql_no_cache ...'. De todos modos, '17.49s vs. 19.18s' es realmente minúsculo. – raveren
El segundo es más rápido si hay un índice en el país de la columna. MySQL tiene que escanear menos entradas de índice para producir el resultado.
Si necesita optimizar, un simple = es mucho mejor que un like.
¿Por qué?
= ya sea la cadena es exactamente el mismo y es verdad o no coincide y es falsa.Por el bien de su base de datos, use SELECT * FROM 'mytable' WHERE country = "US".
No es técnicamente una respuesta a la pregunta ... pero ... Entiendo que estén lo suficientemente cerca para que no (por lo general) importe - por lo tanto, usar "=" sería mejor ya que muestra la intención en una forma más obvia
¿por qué no acaba de hacer country_id una letra pequeña unsigned y tiene una columna iso_code varchar (3) que es única? (lo salva de todas las BS)
Tiene 2 filas llamadas 'País'. –
@Rocket: ¿te refieres a las columnas? –
Sí, soy disléxico, lo siento. –