Firebird21

Por favor ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Búsqueda Avanzada  

Noticias:

Nuevo Post: "Evitando que el tamaño de la Base de Datos se incremente demasiado" checalo en Firebird21.wordpress.com

Autor Tema: Índices en UTF8 no se usan en consultas agregadas  (Leído 170 veces)

0 Usuarios y 1 Visitante están viendo este tema.

mando

  • Bit
  • *
  • Karma: +0/-0
  • Mensajes: 6
    • Ver Perfil
Índices en UTF8 no se usan en consultas agregadas
« en: Junio 08, 2017, 10:40:39 am »

Buenas tardes:

Estoy migrando una base de datos en paradox a FB. Lo estoy haciendo poco a poco y ahora le ha tocado el turno a la tabla mayor de toda la BD. Tiene cerca de 80.500 registros.
Cuando me plantee la creación de la BD, y tras muchas y muchas consultas y pruebas, llegué a la conclusión de que debía ser en UTF8. Entre otras cosas porque el ISO8895_1 no soporta el caracter €.

He hecho el traspaso de los datos siguiendo el artículo de walter del blog "Insertando una gran catidad de filas" . Que, por cierto funciona a las mil maravillas.
Se trata de una tabla de detalle que guarda, entre otras cosas, el código del artículo, cantidad, etc..

Bien, ahora viene el problema. Haciendo pruebas de consultas, me he dado cuenta que en las consultas de agregados, tal como esta:
SELECT Articulo, Count(Articulo), SUM(Cantidad) FROM Tabla

tardaba lo mismo en obtener los resultados que la tabla equivalente en la base de datos Paradox. Lo que me dejo desconcertado.
Investigando, me di cuenta de que no se usa el índice por el campo Artículo, es más, si fuerzo la consulta para que lo use con la cláusa ORDER, no funciona, usa el SORT NATURAL y si le especifico PLAN, me arroja un error " index IDX_1 cannot be used in the specified plan"

Así que he seguido haciendo mis pruebas. La primera es crear otra tabla idéntica, pero con CHARSET ISO8859_1 COLLATE ES_ES_CI_AI, y, para mi sorpresa, la misma consulta anterior sobre esta tabla, tarda un 1/4 que sobre la tabla UTF8, ya que ahora sí utiliza el índice.
He hecho un ciclo backup/restore y la cosa sigue igual.
Otra prueba ha sido crear un campo idéntico, pero, nuevamente con CHARSET ISO8859_1 COLLATE ES_ES_CI_AI., con su índice correspondiente.
Ahora ejecuto la consulta sobre este último campo y la velocidad vuelve a subir, esta vez sobre la tabla original. Efectivamente, ahora usa el índice.
Revisando todas las demás tablas, ocurre lo mismo. No lo había notado porque son mucho más pequeñas.


Conclusión, en consultas agregadas, no se usará un índice definido sobre un campo UTF8 COLLATE UNICODE_CI_AI.

¿Es cierto esto? ¿Que solución podría tener? (Supongo que direis: no utilices códigos alfanuméricos como clave foránea, usa un ID numérico....ya, lo sé. Errores de diseño)

Adjunto la información sobre la BD.



Muchas gracias.


« Última modificación: Junio 08, 2017, 04:56:34 pm por mando »
En línea


Walter

  • Administrator
  • Megabyte
  • *****
  • Karma: +16/-0
  • Mensajes: 481
    • Ver Perfil
Re:Índices en UTF8 no se usan en consultas agregadas
« Respuesta #1 en: Junio 08, 2017, 05:58:59 pm »

En un SELECT como el siguiente, jamás se usará un índice:

SELECT Articulo, Count(Articulo), SUM(Cantidad) FROM Tabla

¿por qué?

Porque los índices solamente se usan para hacer búsquedas o para ordenar el conjunto de resultados, en otras palabras cuando usas la cláusula WHERE o la cláusula ORDER BY.

Si un índice no puede ser utilizado en un PLAN eso significa que no coinciden las columnas de ese índice con las columnas de tu tabla, por ejemplo la columna es ISO8859_1 y el índice es UTF_8.

El símbolo del Euro no está contemplado en ISO8859_1 y jamás estará porque ISO8859_1 ya está lleno, no hay más lugares libres. Sin embargo hay un derivado llamado ISO8859_15 que sí tiene al símbolo del Euro, puedes probar usándolo y comprueba si ya obtienes lo que quieres.

UTF_8 siempre será más lento que ISO8859_XX porque UTF_8 usa más bytes para almacenar a los caracteres.

Saludos.

Walter.
En línea

mando

  • Bit
  • *
  • Karma: +0/-0
  • Mensajes: 6
    • Ver Perfil
Re:Índices en UTF8 no se usan en consultas agregadas
« Respuesta #2 en: Junio 09, 2017, 03:19:38 am »

Buenos días, Walter:

En primer lugar, muchas gracias por tu respuesta. Pero permiteme que discrepe. Tanto desde FlameRobin como con ISQL, cuando hago la consulta utilizando el campo con codificación ISO, el plan , o por lo menos es lo que pone en el resultado de la ejecución, usa el ÍNDICE sobre el campo. (PLAN  (TABLA ORDER IDX_2))
¿Me está engañado ISQL?

Por otro lado. ¿Cómo puedo especificar ISO8859_15? FlameRobin no me da la opción. ¿EMS tal vez sí?


Estoy usando el server 2.5 (WI-V2.5.5.26952).



Saludos. Muchas gracias.
« Última modificación: Junio 09, 2017, 03:45:22 am por mando »
En línea

mando

  • Bit
  • *
  • Karma: +0/-0
  • Mensajes: 6
    • Ver Perfil
Re:Índices en UTF8 no se usan en consultas agregadas
« Respuesta #3 en: Junio 15, 2017, 03:48:10 pm »

Buenas tardes:

Me respondo yo mismo.

No se usará indice en consultas con campos agregados cuando el campo sea UTF8 con collate UNICODE_CI o UNICODE_CI_AI.
Si en campo es UTF8 sin collate, sí se usará.
Lo que se gana por un lado, se perderá por el otro, ya que no se distiguirá entre mayúsculas/minúsculas y entre carácteres acentuados/no acentuados, tanto en agregadas, como en consultas de selección.

saludos.
En línea
 

Enlaces

Blog de Firebird21 WebMaster