Cuáles son algunos de los desarrolladores de SQL métodos/técnicas experimentados utilizan para determinar si una consulta SQL determinada escalará así como aumenta la carga, las filas en las tablas asociadas aumentan etc.¿Cómo saber si una consulta escalará bien?
Algunas reglas que sigo que hacen la mayor diferencia.
¿No uso de funciones por fila en sus consultas como if, case, coalesce y así sucesivamente. Redúzcalos poniendo datos en la base de datos en el formato que va a necesitar, incluso si eso implica datos duplicados.
Por ejemplo, si necesita buscar apellidos rápidamente, guárdelos en el formulario ingresado y en su forma en minúscula e indexe el formulario en minúscula. Entonces no tiene que preocuparse por cosas como select * from tbl where lowercase(surname) = 'smith';
Sí, sé que rompe 3NF pero aún puede garantizar la integridad de los datos mediante el uso juicioso de activadores o columnas precalculadas. Por ejemplo, un desencadenador de inserción/actualización en la tabla puede forzar que la columna lower_surname se establezca en la versión en minúscula de surname.
Esto mueve el costo de conversión al insert/update (que ocurre con poca frecuencia) y lejos del select (que ocurre un montón más). Básicamente amortizas el costo de la conversión.
asegurarse de que cada columna utilizada en una cláusula where está indexado. No necesariamente por sí solo, sino al menos como la parte principal de una clave compuesta.
siempre a empezar en 3NF y sólo volverá si tiene problemas de rendimiento en la producción (). 3NF es a menudo el más fácil de manejar y revertir solo debe hacerse cuando sea absolutamente necesario.
Perfil, en producción (o en otro lugar, siempre que tenga datos de producción y esquemas).El ajuste de la base de datos no es una operación de configuración y olvido a menos que los datos en sus tablas nunca cambien (muy raros). Debe supervisar, y posiblemente ajustar, periódicamente para evitar la posibilidad de que el cambio de datos disminuya el rendimiento.
No, a menos que sea absolutamente necesario, permita consultas simples a su base de datos. Intenta controlar qué consultas se pueden ejecutar. Su trabajo como DBA será mucho más difícil si algún administrador puede venir y simplemente ejecuta:
select * from very_big_table order by column_without_index;
en su base de datos.
Si los gerentes desean ejecutar consultas ad-hoc, dele un DBMS (o réplica) clonado para que sus usuarios reales (los que necesitan rendimiento) no se vean afectados.
No utilice union cuando union all será suficiente. Si sabe que no puede haber duplicados entre dos selecciones de una unión, no tiene sentido dejar que el DBMS intente eliminarlos.
De manera similar, no use select distinct en una tabla si está recuperando todas las columnas de clave principal (o todas las columnas en una restricción única). Hay no posibilidad de duplicados en esos casos por lo que, nuevamente, le está pidiendo al DBMS que haga un trabajo innecesario.
Ejemplo: teníamos un cliente con una vista que usaba select distinct * en una de sus tablas. Consultar la vista tomó 50 segundos. Cuando lo reemplazamos con una vista que comienza en select *, el tiempo bajó a menos de segundo. Ni que decir tiene, me dieron una buena botella de vino tinto de ese :-)
tratar de evitar select * tanto como sea posible. En otras palabras, solo obtenga las columnas que necesita. Esto hace poca diferencia cuando estás usando MySQL en tu PC local, pero cuando tienes una aplicación en California que consulta una base de datos en Mongolia Interior, quieres minimizar la cantidad de tráfico que se envía a través del cable tanto como sea posible.
Lanzar un sh * tload de los datos a ella, y perfil.
Eso, y asegúrese de que sigue las mejores prácticas para la indexación, el diseño del esquema, etc.
no hacen tablas de ancho, mantenerlos reducir, así como los índices. Asegúrese de que las consultas estén completamente cubiertas por los índices y que esas consultas sean SARGables.
prueba con un montón de datos antes de entrar en la producción, echar un vistazo a esto: Your testbed has to have the same volume of data as on production in order to simulate normal usage
Además (y en el mismo sentido) a la sugerencia de Robert, tenga en cuenta el plan de ejecución. ¿Está utilizando índices? ¿Hay algún escaneo o tal? ¿Puedes simplemente para la consulta de alguna manera? Por ejemplo, elimine IN en favor de EXISTS y únase a las tablas que necesita para unirse.
No menciona la tecnología: tenga en cuenta que las diferentes tecnologías pueden afectar la eficiencia de las consultas más complejas.
Tire hacia arriba el plan de ejecución y busque cualquiera de los siguientes:
Cualquiera de esas cosas (en orden descendente de más a menos escalable) significa que la base de datos/consulta probablemente no se escalará a tablas mucho más grandes. Una consulta ideal tendrá, en su mayoría, búsquedas de índices, uniones hash o merge, el ordenamiento ocasional y otras operaciones de bajo impacto (spools, etc.).
La única manera de demostrar que es según la escala, como han señalado otras respuestas, es probarlo con datos del tamaño deseado. Lo anterior es solo una regla empírica.
Recomiendo leer algo de material de referencia sobre esto.Este (hipervínculo a continuación) es probablemente un libro bastante bueno para examinar. Asegúrese de buscar en "Selectividad", entre otros temas.