Los fundamentos de la indexación, etc., funcionan exactamente de la misma manera, por lo que, estrictamente hablando, ¡la única diferencia es el costo de equivocarse!
Dicho esto, aquí hay una lista (no necesariamente completa) de cosas que vale la pena tener en cuenta:
- Es probable que los índices del árbol B tengan un nivel adicional, por lo que el costo de usarlos es ligeramente mayor. Sin embargo, en un DW debería usar índices de mapa de bits (suponiendo que tenga la edición Enterprise)
- Tomará mucho más tiempo calcular las estadísticas para toda la tabla, hasta el punto en que no sea posible en la ventana normal de la noche a la mañana. Esto puede ser superado por
- Usando un más pequeño
estimate_percentcuando se recopilan estadísticas, se muestrea menos de la tabla.
- Uso de la recopilación de estadísticas incrementales (sin embargo, solo es relevante si tiene índices globales en tablas particionadas)
- Los histogramas para índices están limitados a 254 cubos. Es probable que más filas signifiquen valores más distintos, lo que significa que los valores "casi populares" pueden ser un problema mayor para los datos asimétricos.
- Las posibilidades de que toda la tabla quepa en la memoria caché del búfer se aproximen a cero, lo que significa que es más probable que tenga más lecturas físicas (de disco). Su conjunto de trabajo normal también puede ser demasiado grande para almacenar en caché.
- Particionar puede ser tu amigo, si lo haces bien. Si generalmente modifica y consulta datos en varias particiones, puede costarle más que tablas simples.
- Las vistas materializadas pueden ser muy útiles para reducir su conjunto de trabajo. por ejemplo, si tiene más de 10 años de datos, pero la gran mayoría de las consultas de los usuarios son solo en los últimos 2 años, entonces crear un MV limitado solo a estos datos puede ser de gran ayuda.
- Cuanto más grande sea la base de datos, menos probable es que la empresa (pueda) financiar una base de datos de prueba que sea un duplicado completo del entorno en vivo. Esto dificulta la reproducción de problemas de rendimiento en las pruebas, ya que las consultas lentas pueden deberse a la escala y / o al almacenamiento físico de los datos. No puede contar con poder extrapolar resultados de consultas de una base de datos de prueba mucho más pequeña al rendimiento correspondiente en vivo.
Si aún no está familiarizado con la lectura y la comprensión de los planes de ejecución, pasaré algún tiempo aprendiendo esto: es probable que tenga problemas de rendimiento en algún momento, por lo que saber cómo diagnosticar el problema correctamente será más importante, ya que es más difícil agregar nuevos indexa o realiza cambios de esquema cuando los recuentos de filas son más grandes.
