Cita: 1. Siempre es mejor poner los indices en columnas que sean enteros pq ocupan menos espacio y en consecuencia aumentan la velocidad del query.
2. En caso de crear un indice que cubra varias columnas, siempre es mejor que estas esten en el orden de menor cardinalidad a mayor.
Cardinalidad hace referencia al posible numero de valores que puede tener una columna en particular.
3. Procurar que las columnas esten declaradas como not null, para que el indice ocupe menos y en consecuencia la busqueda sea mas rapida.
1) Si, es cierto, los índices basados en columnas numéricas son más rápidos, pero eso no implica que sean funcionales para las consultas que necesites hacer. Los índices deben hacerse sobre las columnas que afectan la búsqueda, no porque si, o siguiendo al pie de la letra una "regla" estandarizada.
Como ejemplo, hace unos días tenía que procesar 30.000.000 de registros indexados por su PK numérica, y básicamente usaba la PK para realizar la vinculación. Pero tardaba más de 10 minutos en devolverme los 350.000 registros que cumplian con lo que necesitaba.
Implementé un índice de tipo INDEX sobre tres columnas, dos VARCHAR y una DATETIME, ninguna de las cuales tenía alta selectividad, y el descenso de tiempo hizo que la respuesta tardase 22,47 segundos...
Moraleja: Lo que sirve en todos los casos, no necesariamente sirve en
tu caso.
2) Es relativo. Como dije, el tema no es seguir una regla. Poner las columnas de alta selectividad en un índice de múltiples columnas no reduce la cantidad de entradas al índice, porque las mismas se crean en base a la clave completa y no a parte de ella.
Si la primera de tres claves tiene 100 variaciones de valores en su tabla, la segunda 1500 y la tercera 10.000, el primer valor aparecerá de todos modos en 1.500.000.000 de entradas de índice. Su cardianlidad no reduce ni la cantidad de entradas del índice ni la cantidad de bloques a leer de esa clave.
3) Una columna definida en tabla como NOT NULL , usada en un índice no reduce la cantidad de entradas al índice por sí misma. Reduce las entradas porque no puedes ingresar un valor nuevo a la tabla que sea NULL en esos campos, y por tanto hay una entrada menos en el índice en ese caso.
Pero el índice tendrá la misma cantidad de entradas si son NULL que si son NOT NULL. la única diferencia sería que la rama donde el valor de ese campo sea NULL será más larga que en el resto, y por tanto si la incidencia de NULLs en ese campo es alta en la tabla, puede que la performance de ese indice base, pero sólo en el caso de los NULL de esa columna.
Resumiendo:
- No generes índices porque sí. Cuando generas uno estás afectando la performance de las inserciones/actualizaciones negativamente (todo índice debe ser actualizado cuando un valor usado en clave cambia o se inserta).
- Genera los índices especialmente para aquellas consultas que sean críticas en su performance, y presta atención especial a las que manejan cantidades masivas de registros.
- Los indices declarados sobre los mismos campos que se consultan el el SELECT suelen hacer más rápidas las consultas, porque MySQL lee el índice directamente y nunca lee la tabla si todos los valores están allí.
- El uso de índices mejora si en el WHERE las condiciones son "=", y no si son ">", "<", o "LIKE". Estas son de baja performance.
- Los agrupamientos y ordenaciones son pésimos para la performance. ´Susalos sólo cuando sea necesario.
- Aprovecha las tablas temporales y las derivadas (subconsultas) para hacer preselecciones que mejoren la performance.