La partición es nunca una opción para mejorar el rendimiento. Lo mejor que puede esperar es tener un rendimiento a la par con una tabla sin particiones. Por lo general, obtiene una regresión que aumenta con el número de particiones. Para el rendimiento necesita índices, no particiones. Las particiones son para operaciones de administración de datos:ETL, archivo, etc. Algunos afirman que la eliminación de particiones es una posible ganancia de rendimiento, pero para cualquier cosa, la eliminación de particiones puede dar resultados mucho mejores al colocar la clave de índice principal en la misma columna que la columna de partición.
Esa consulta necesita un índice en State . De lo contrario, es un escaneo de tabla y escaneará toda la tabla. Un escaneo de tabla sobre una tabla particionada es siempre más lento que un escaneo sobre una tabla sin particiones del mismo tamaño. El índice en sí se puede alinear en el mismo esquema de partición, pero la clave principal debe ser State .
El paralelismo no tiene nada que ver con la partición, a pesar de la idea errónea común de lo contrario. Tanto los escaneos de rango particionados como los no particionados se pueden usar con un operador paralelo, será la decisión del Optimizador de consultas.
No
Un índice ayudará. Si el índice tiene que estar alineado, entonces debe particionarse. Un índice sin particiones será más rápido que uno con particiones, pero no se puede eludir el requisito de alineación del índice para las operaciones de encendido/apagado.
Si está pensando en crear particiones, debería ser porque necesita realizar operaciones rápidas de cambio de entrada y salida para eliminar datos antiguos que hayan pasado el período de la política de retención o algo similar. Para el rendimiento, debe observar los índices, no las particiones.
