SQL Server Tips de rendimiento y directrices

Introducción

Los siguientes consejos y directrices son muy importantes desde la perspectiva del rendimiento de su desarrollo de SQL Server o base de datos de producción. La mejor manera de lograr beneficios óptimos de rendimiento es experimentar con las siguientes orientaciones al usar / ver un plan de ejecución de la consulta, con y sin la aplicación de la respectiva punta / guía.

Consejos y Guías

• Como práctica común, cada tabla debe tener un índice agrupado. Generalmente, pero no siempre, el índice agrupado debe estar en una columna que aumenta monótonamente, como una columna de identidad o alguna otra columna donde el valor es único. En muchos casos, la clave primaria es la columna ideal para un índice agrupado.

• Índices debe medirse en todas las columnas que se utilizan con frecuencia en DONDE , ORDER BY , GROUP BY , TOP y DISTINCT cláusulas.

• No agregue automáticamente los índices de una tabla porque parece que lo que hay que hacer. Sólo añadir índices si saben que van a ser utilizados por las consultas ejecutadas contra la mesa.

• Para históricas (estática) tablas, crear los índices con un FILLFACTOR y un PAD_INDEX de 100 para asegurar que no hay espacio perdido. Esto reduce la E / S, lo que ayuda a mejorar el rendimiento general.

• Las consultas que devuelven una sola fila son igual de rápido con un índice no agrupado como un índice agrupado.

• Las consultas que devuelven un rango de filas igual de rápido con un índice agrupado como un índice no agrupado.

• No añadir más índices en las tablas OLTP para minimizar la sobrecarga que se produce con los índices durante las modificaciones de datos.

• No agregue el mismo índice más de una vez en una mesa con nombres diferentes.

• Descartar todos los índices que no son utilizadas por el optimizador de consultas, en general. Es probable que no desea agregar un índice a una tabla con las siguientes condiciones:

Si el índice no es usado por el optimizador de consultas. Utilice el Analizador de consultas de «Ejecución del Plan Mostrar» para ver si sus consultas en una tabla específica, usar un índice o no.
Si la tabla es pequeña, la mayoría de los índices de probabilidad no se utilizará.
Si la columna (s) para ser indexados son muy amplios.
Si la columna (s) se definen como TEXT , NTEXT o IMAGEN tipos de datos.
Si la tabla es raramente consultar pero inserción, la actualización es frecuente.
• Para proporcionar hasta al día las estadísticas, el optimizador de consultas tiene que tomar decisiones inteligentes de optimización de la consulta. En general, usted tendrá que dejar el «Auto Update Estadísticas» opción en la base de datos. Esto ayuda a asegurar que las estadísticas del optimizador son válidos, asegurando que las consultas se optimizado correctamente cuando se ejecutan.

• Mantenga el «ancho» de los índices lo más estrecha posible. Esto reduce el tamaño del índice, y reduce el número de operaciones de E / S lecturas necesarias para leer el índice.

• Si es posible, trate de crear índices en columnas que tienen valores enteros en lugar de caracteres. Los valores enteros utilizan menos espacio que los valores de caracteres.

• Si usted tiene dos o más tablas que con frecuencia se unen entre sí, entonces las columnas utilizadas para las juntas deben tener un índice apropiado. Si las columnas utilizadas para las uniones no son naturalmente compacto, entonces considerar la adición de claves sustitutas para las tablas que se compacta con el fin de reducir el tamaño de las teclas. Esto disminuirá E / S durante el proceso de unión, lo que aumenta el rendimiento general.

• Al crear índices, tratar de hacerles índices únicos, si es posible. SQL Server menudo puede buscar a través de un índice único más rápido que un índice no único. Esto se debe a que, en un índice único, cada fila es única y una vez que el expediente se encuentra necesario, SQL Server no tiene que buscar más.

• Si una consulta determinada en una tabla que se ejecuta con poca frecuencia y la adición de un índice acelera en gran medida el rendimiento de la consulta, pero el rendimiento de INSERTOS , ACTUALIZACIONES y SUPRIME se ve negativamente afectada por la adición del índice, considere crear el índice para el tabla para la duración de cuando se ejecuta la consulta y, a continuación quitar el índice. Un ejemplo de esto es cuando informes mensuales se ejecuta al final del mes en una aplicación OLTP.

• Evite usar FLOAT o REALES tipos de datos como claves principales, ya que una sobrecarga innecesaria que puede perjudicar el rendimiento.

• Si desea mejorar el rendimiento de una consulta que incluye una Y en el operador DONDE cláusula, considere lo siguiente:

De los criterios de búsqueda en la DONDE cláusula, al menos uno de ellos debe estar basada en una columna altamente selectiva que tiene un índice.
Si al menos uno de los criterios de búsqueda en el DONDE cláusula no es muy selectivo, considerar la adición de índices para todas las columnas de referencia en el DONDE cláusula.
Si ninguna de las columnas del DONDE cláusula son lo suficientemente selectiva como para utilizar un índice por su cuenta, considere la creación de un índice de cobertura para esta consulta.
• El optimizador de consultas siempre se llevará a cabo un recorrido de tabla o un recorrido de índice agrupado en una tabla si el DONDE cláusula de la consulta contiene un O operador y si alguna de las columnas referenciadas en el OR cláusula no están indexados (o no tienen una utilidad índice). Debido a esto, si utiliza muchas consultas con O cláusulas, usted querrá asegurarse de que cada columna referenciada en el DONDE cláusula tiene un índice.

• Si usted tiene una consulta que utiliza OR s y no está haciendo el mejor uso de índices, considere volver a escribir como un UNION y luego las pruebas de rendimiento. Sólo a través de pruebas puede estar seguro de que una versión de la consulta será más rápida que la otra.

• Si utiliza el SOUNDEX función contra una columna de la tabla en una DONDE cláusula, el optimizador de consultas se ignorarán los índices disponibles y realizar una exploración de tabla.

• Las consultas que incluyen tanto la DISTINCT o GROUP BY cláusulas se puede optimizar mediante la inclusión de índices apropiados. Cualquiera de las estrategias de indexación pueden utilizar los siguientes:

Incluye una cubierta, índice no agrupado (que abarca las columnas apropiadas) de la DISTINCT o GROUP BY cláusulas.
Incluya un índice agrupado en las columnas del GROUP BY cláusula.
Incluya un índice agrupado en las columnas que se encuentran en el SELECT cláusula.
Adición de índices adecuados a las consultas que incluyen DISTINCT o GROUP BY es muy importante para aquellas consultas que se ejecutan con frecuencia.
• Evite los índices agrupados en columnas que ya están «cubiertos» por los índices no agrupados. Un índice agrupado en una columna que ya está «cubierto» es redundante. Utilice el índice agrupado para las columnas que mejor pueden hacer uso de ella.

• Idealmente un índice agrupado debe basarse en una sola columna (no varias columnas) que son tan estrechos como sea posible. Esto no sólo reduce el tamaño físico del índice agrupado, sino que también reduce el tamaño físico de los índices no agrupados y aumenta el rendimiento general de SQL Server.

• Cuando se crea un índice agrupado, trata de crear un índice agrupado único, no es un índice no agrupado único.

• SET NOCOUNT ON al inicio de cada procedimiento almacenado que escribes. Esta declaración debe incluir en cada procedimiento almacenado, desencadenador, etc que usted escribe.

• Mantenga las transacciones de Transact-SQL lo más breve posible dentro de un procedimiento almacenado. Esto ayuda a reducir el número de bloqueos, ayudando a acelerar el rendimiento general de la aplicación SQL Server.

• Si va a crear un procedimiento almacenado para ejecutar en una base de datos distinta de la base de datos principal, no utilice el prefijo sp_ en su nombre. Este prefijo especial está reservado para los procedimientos almacenados del sistema. Aunque el uso de este prefijo no impedirá que un procedimiento almacenado definido por el usuario de trabajo, lo que puede hacer es retrasar su ejecución muy ligeramente.

• Antes de que haya terminado con su código de procedimiento almacenado, lo examinará para cualquier código no utilizado, los parámetros o variables que pueden haber olvidado de quitar mientras se estaban haciendo cambios y eliminarlos. Código no utilizado sólo añade hinchazón innecesaria a los procedimientos almacenados, aunque no necesariamente afectan negativamente a la funcionalidad del procedimiento almacenado.

• Para un mejor rendimiento, todos los objetos que se llaman dentro del mismo procedimiento almacenado debe ser propiedad del dueño del mismo objeto o esquema, preferiblemente dbo , y también debe ser mencionado en el formato de object_owner.object_name o schema_owner.object_name .

• Cuando tenga que ejecutar una serie de instrucciones Transact-SQL, debe utilizar el sp_executesql procedimiento almacenado en lugar de la EJECUTAR comunicado.

• Si utiliza parámetros de entrada en los procedimientos almacenados, debe validar todos ellos al inicio de su procedimiento almacenado. De esta manera, si hay un problema de validación y la aplicación de cliente debe ser notificado del problema, que ocurre antes de cualquier transformación procedimiento almacenado toma su lugar, evitando desperdicio de esfuerzo y aumenta el rendimiento.

• Cuando se llama a un procedimiento almacenado desde la aplicación, es importante que usted lo llama con su nombre completo, por ejemplo:

Collapse | Copiar código
ejecutivo dbo.myProc
… En lugar de:

Collapse | Copiar código
ejecutivo myProc
• Si considera que un procedimiento almacenado devolverá sólo un valor único y no un conjunto de registros, considere la devolución del valor único como parámetro de salida.

• Utilizar procedimientos almacenados en lugar de puntos de vista. Ellos ofrecen un mejor rendimiento.

• No incluya el código, variables o parámetros que no hacen nada.

• No tenga miedo de hacer de mente amplia utilización de in-line y los comentarios de bloque en el código Transact-SQL. No afectará el rendimiento de la aplicación y que mejorará su productividad cuando tienes que volver al código y tratar de modificarlo.

• Si es posible, evite el uso de cursores de SQL Server. Por lo general, utilizan una gran cantidad de recursos de SQL Server y reducir el rendimiento y la escalabilidad de las aplicaciones.

• Si usted tiene la opción de usar una unión o una subconsulta para realizar la misma tarea dentro de una consulta, por lo general la combinación es más rápido. Esto no es siempre el caso, sin embargo, y es posible que desee probar la consulta utilizando los dos métodos para determinar qué es más rápido para su aplicación en particular.

• Si su aplicación requiere la creación de tablas temporales para su uso en un uso global o por conexión, considere la posibilidad de crear índices para las tablas temporales. Aunque la mayoría de las tablas temporales probablemente no necesite – o incluso utilizar – un índice, algunas mesas más grandes temporales pueden beneficiarse de ellas. Un índice diseñado adecuadamente en una tabla temporal puede ser tan grande beneficio como un índice diseñado adecuadamente sobre una mesa de base de datos estándar.

• En lugar de utilizar tablas temporales, considere el uso de una tabla derivada en su lugar. Una tabla derivada es el resultado del uso de un SELECT declaración en el DE cláusula de una ya existente SELECT comunicado. Mediante el uso de tablas derivadas en lugar de tablas temporales, puede reducir la E / S y, a menudo mejorar el rendimiento de la aplicación.

• Para un mejor rendimiento, si usted necesita una tabla temporal en el código Transact-SQL, puede utilizar una variable de tabla en lugar de crear una tabla temporal convencional.

• No volver a utilizar varias veces la misma función para calcular el mismo resultado una y otra vez dentro de su código Transact-SQL.

• Si utiliza BULK INSERT para importar datos en SQL Server, a continuación, utilizar el TABLOCK pista junto con él. Esto evitará que SQL Server se quede sin bloqueos durante las importaciones de gran tamaño y también aumentará el rendimiento debido a la reducción de la contención de bloqueo.

• Siempre especifique las columnas más estrechas que pueda. Cuanto más estrecho es la columna, menor cantidad de datos SQL Server tiene que almacenar más rápido y el servidor de SQL es capaz de leer y escribir datos. Además, si algún tipo deben realizarse en la columna, más estrecho de la columna, más rápida es la especie será.

• Si tiene que almacenar cadenas de grandes volúmenes de datos y son menos de 8000 caracteres, use un VARCHAR tipo de datos en lugar de un TEXTO tipo de datos. TEXTO tipos de datos tienen sobrecarga adicional que arrastrar el rendimiento.

• No utilice el NVARCHAR o NCHAR tipos de datos a menos que necesite para almacenar 16-bits de caracteres (Unicode) de datos. Ocupan espacio el doble de lo VARCHAR o CHAR tipos de datos, aumentando servidor de E / S y desperdiciar espacio innecesario en su caché del búfer.

• Si los datos de texto en una columna varía mucho en longitud, use un VARCHAR tipo de datos en lugar de CHAR tipo de datos. La cantidad de espacio ahorrado utilizando VARCHAR sobre CHAR en columnas de longitud variable puede reducir la E / S dice que la memoria caché utiliza para almacenar los datos, mejorando el rendimiento general del servidor SQL.

• Si los datos de una columna no varían mucho en longitud, puede utilizar una longitud fija CHAR en vez de un campo VARCHAR . Si bien puede tomar un poco más de espacio para almacenar los datos, procesar columnas de longitud fija es más rápido en SQL Server que procesar columnas de longitud variable.

• Si tiene una columna que está diseñado para soportar sólo números, utilice un tipo de datos numérico, como INTEGER en lugar de un VARCHAR o CHAR tipo de datos. Tipos de datos numéricos generalmente requieren menos espacio para mantener el mismo valor numérico que hace un tipo de datos de caracteres. Esto ayuda a reducir el tamaño de las columnas y puede aumentar el rendimiento cuando las columnas se buscan ( DONDE cláusula), se unió a otra columna o ordenados.

• Si utiliza el CONVERT función para convertir un valor a una longitud variable de tipo de datos, como VARCHAR , siempre especifique la longitud del tipo de datos variables. Si no lo hace, SQL Server supone una longitud predeterminada de 30. Idealmente, usted debe especificar la longitud más corta para llevar a cabo la tarea requerida. Esto ayuda a reducir el uso de memoria y recursos de SQL Server.

• Evite utilizar el nuevo BIGINT tipo de datos a menos que usted realmente necesita su capacidad de almacenamiento adicional. El BIGINT tipo de datos utiliza 8 bytes de memoria, frente a 4 bytes para el INT tipo de datos.

• No utilice el DATETIME tipo de datos como clave principal. Desde una perspectiva de rendimiento, es más eficaz utilizar un tipo de datos que utiliza menos espacio. Por ejemplo, la DATETIME tipo de datos utiliza 8 bytes de espacio, mientras que la INT tipo de datos sólo ocupa 4 bytes. El espacio inferior utilizado, menor será la tabla y el índice, y la menor de E / S de arriba que es necesario para acceder a la clave principal.

• Si va a crear una columna que sabes que va ser objeto de muchas clases, considere hacer la columna entera basada y no basada en caracteres. Esto se debe a que SQL Server puede ordenar los datos enteros mucho más rápido que los datos de caracteres.

• Evalúe cuidadosamente si el SELECT consulta necesita la DISTINCT cláusula o no. Algunos desarrolladores añadir automáticamente esta cláusula para cada una de sus SELECT declaraciones, aun cuando no es necesario. Este es un mal hábito que debe ser detenido.

• Cuando tenga que utilizar SELECT INTO opción, tenga en cuenta que puede bloquear las tablas del sistema, impidiendo que otros usuarios puedan acceder a los datos que necesitan, mientras que los datos se inserta. Con el fin de evitar o reducir al mínimo los problemas ocasionados por tablas bloqueadas, trate de programar el uso de SELECT INTO de SQL Server cuando está menos ocupado. Además, trata de mantener la cantidad de datos insertados en un mínimo. En algunos casos, puede ser mejor para llevar a cabo varios más pequeños SELECT INTO s en lugar de realizar una grande SELECT INTO .

• Si es necesario verificar la existencia de un registro en una tabla, no utilice SELECT COUNT (*) en su código Transact-SQL para identificarlo. Esto es muy ineficiente y desperdicia recursos del servidor. En su lugar, utilice la instrucción Transact-SQL IF EXISTS para determinar si el registro en cuestión existe, que es mucho más eficiente.

• De forma predeterminada, algunos desarrolladores – especialmente aquellos que no han trabajado con SQL Server antes – de forma rutinaria incluir código similar a éste en su DONDE cláusulas cuando se hacen comparaciones de cadenas:

Collapse | Copiar código
SELECT nombre_columna DE table_name
 DONDE LOWER (column_name) = ‘ nombre ‘
En otras palabras, estos desarrolladores están haciendo la suposición de que los datos en SQL Server distingue entre mayúsculas y minúsculas, lo que por lo general no lo es. Si su base de datos de SQL Server no está configurado para estar entre mayúsculas y minúsculas, no es necesario utilizar INFERIOR o SUPERIOR a la fuerza el caso de texto a ser igual para una comparación a realizar. Deje estas funciones fuera de su código. Esto acelerará el rendimiento de la consulta, ya que cualquier uso de las funciones de texto en una DONDE cláusula perjudica el rendimiento.

Sin embargo, lo que si su base de datos se ha configurado para distinguir entre mayúsculas y minúsculas? En caso de que utilice los INFERIOR y SUPERIOR funciones para asegurar que las comparaciones están debidamente comparados? No. El ejemplo anterior es todavía pobre codificación. Si usted tiene que tratar con la garantía de caso es consistente para hacer comparaciones adecuadas, utilizar la técnica descrita a continuación, junto con los índices correspondientes de la columna en cuestión:

Collapse | Copiar código
SELECT nombre_columna DE table_name
 DONDE column_name = ‘ NOMBRE ‘  o column_name = ‘ nombre ‘
Este código se ejecutará mucho más rápido que el primer ejemplo.

• Si actualmente tiene una consulta que utiliza NO EN , que ofrece un rendimiento pobre porque el optimizador de SQL Server tiene que utilizar una exploración de tabla anidada para llevar a cabo esta actividad, en lugar de tratar de utilizar una de las opciones siguientes, todos los cuales ofrecen un mejor rendimiento:

Utilice EXISTS o NOT EXISTS
Utilice EN
Realizar un LEFT OUTER JOIN y compruebe si hay NULL condición
• Cuando usted tiene la opción de utilizar el IN o EXISTS cláusula de Transact-SQL, por lo general, tendrá que usar el EXISTS cláusula, ya que suele ser más eficiente y lleva a cabo con mayor rapidez.

• Si usted encuentra que SQL Server utiliza una exploración de tabla en lugar de una búsqueda de índice cuando se utiliza un EN / O cláusula como parte de su DONDE cláusula, aun cuando las columnas están cubiertas por un índice, considere el uso de una sugerencia de índice para forzar la consulta Optimizador de usar el índice.

• Si utiliza LIKE en su DONDE cláusula, trate de utilizar uno o más protagonistas en la cláusula, si es posible. Por ejemplo, utilice:

Collapse | Copiar código
LIKE  ‘ % m ‘ en lugar de  LIKE ‘% m’
• Si su aplicación necesita para recuperar datos de resumen a menudo, pero no quiero tener la sobrecarga de cálculo sobre la marcha cada vez que sea necesario, considerar el uso de un disparador que actualiza los valores de resumen después de cada transacción en una tabla resumen.

• Cuando usted tiene la opción de utilizar el IN o BETWEEN cláusulas en su Transact-SQL, por lo general, tendrá que usar el ENTRE cláusula, ya que es mucho más eficiente. Por ejemplo …

Collapse | Copiar código
SELECT task_id, nombre_tarea
 DE tareas
 DONDE task_id en ( 1000 , 1001 , 1002 , 1003 , 1004 )
… Es mucho menos eficiente que este:

Collapse | Copiar código
SELECT task_id, nombre_tarea
 DE tareas
 DONDE task_id ENTRE  1000  y  1004
• Si es posible, trate de evitar el uso de la SUBSTRING función en sus WHERE cláusulas. Dependiendo de cómo se construye, con el SUBSTRING función puede forzar una exploración de tabla en lugar de permitir que el optimizador utiliza un índice (asumiendo que existe). Si la subcadena que está buscando no incluye el primer carácter de la columna que está buscando, a continuación, un recorrido de tabla se realiza.

• Si es posible, se debe evitar el uso de la SUBSTRING y utilizar la función LIKE condición en vez de mejorar el rendimiento. En vez de hacer esto:

Collapse | Copiar código
DONDE SUBSTRING (nombre_tarea, 1 , 1 ) = ‘ b ‘
Trate de usar en su lugar:

Collapse | Copiar código
DONDE nombre_tarea LIKE  ‘ % b ‘
• Evite el uso de las sugerencias del optimizador en sus WHERE cláusulas. Esto se debe a que por lo general es muy difícil de adivinar por el optimizador de consultas. Sugerencias del optimizador son palabras que se incluyen con la consulta a la fuerza cómo el optimizador de consultas ejecuta. Si decide incluir una pista en una consulta, esto obliga al optimizador de consultas para llegar a ser estática, evitando que el optimizador de consultas de forma dinámica para adaptarse al entorno actual para la consulta dada. Más a menudo que no, esto duele – no ayuda – rendimiento.

• Si usted tiene una DONDE cláusula que incluye expresiones conectadas por dos o más Y los operadores, SQL Server las evaluará de izquierda a derecha en el orden en que están escritas. Esto supone que no hay paréntesis se han utilizado para cambiar el orden de ejecución. Debido a esto, es posible que desee considerar una de las siguientes cuando se utiliza Y :

Localice el menos probable que así sea Y la primera expresión.
Si las dos partes de una AND expresión tienen la misma probabilidad de ser falso, poner la menos compleja Y primera expresión.
Es posible que desee considerar el uso de Analizador de consultas o Management Studio para ver los planes de ejecución de consultas para ver qué es lo mejor para su situación
• No utilice ORDER BY en tus SELECT declaraciones a menos que usted realmente necesita, ya que añade un montón de gastos extra. Por ejemplo, tal vez puede ser más eficiente para ordenar los datos en el cliente que en el servidor.

• Siempre que SQL Server tiene que realizar una operación de clasificación, los recursos adicionales tienen que ser utilizados para realizar esta tarea. Ordenando a menudo se produce cuando alguna de las siguientes instrucciones Transact-SQL se ejecutan:

ORDER BY
GROUP BY
SELECT DISTINCT
UNION
• Si usted tiene que ordenar una columna en particular a menudo, considerar la posibilidad de que la columna de un índice agrupado. Esto se debe a que los datos ya están preclasificados para usted y el servidor SQL es lo suficientemente inteligente como para no recurrir a los datos.

• Si su DONDE cláusula incluye una EN operador junto con una lista de valores que se analizarán en la consulta, ordenar la lista de valores para que los más frecuentemente encontrados son colocados al inicio de la lista y los que con menor frecuencia se encuentra situado al final de la lista. Esto puede acelerar el rendimiento porque la EN opción devuelve verdadero tan pronto como cualquiera de los valores en la lista de producir un partido. Cuanto antes se realice la coincidencia, más rápida la consulta completa.

• Si la aplicación realiza comodín muchos ( LIKE% ) búsquedas de texto en CHAR o VARCHAR columnas, considere el uso de SQL Server de texto completo opción de búsqueda. El servicio de búsqueda puede acelerar significativamente búsquedas con comodines de texto almacenados en una base de datos.

• El GROUP BY cláusula puede ser utilizada con o sin una función de agregado. Sin embargo, si quieres un rendimiento óptimo, no utilice el GROUP BY cláusula sin una función de agregado. Esto se debe a que se puede lograr el mismo resultado utilizando el DISTINCT opción en su lugar, y es más rápido. Por ejemplo, usted podría escribir su duda dos formas diferentes:

Collapse | Copiar código
SELECT task_id
 DE tareas
 DONDE task_id ENTRE  10  Y  20
DEL GRUPO  DE OrderID
O …:

Collapse | Copiar código
SELECT  DISTINCT task_id
 DE tareas
 DONDE task_id ENTRE  10  Y  20
• Es importante diseñar aplicaciones que mantienen transacciones lo más corto posible. Esto reduce de bloqueo y aplicación aumentan al mismo tiempo, lo que ayuda a aumentar el rendimiento.

• Con el fin de reducir el tráfico de red entre el cliente o el servidor de nivel medio y SQL – y también para aumentar el rendimiento de SQL Server-based aplicación – sólo los datos que necesita el cliente o nivel medio debe ser devuelto por SQL Server. En otras palabras, no devuelva más datos (filas y columnas) de SQL Server que usted necesita para el cliente o nivel medio y reducir aún más los datos a los datos que realmente necesita en el cliente o nivel medio. Es un despilfarro de recursos de SQL Server y ancho de banda de la red.

• Para realizar consultas complejas más fáciles de analizar, considerar descomponerlos en sus componentes más pequeños. Una forma de hacer esto es simplemente crear listas de los componentes clave de la consulta, tales como:

Una lista de todas las columnas que van a ser devuelto
Enumerar todas las columnas que se utilizan en la DONDE cláusula
Enumere todas las columnas utilizadas en el JOIN s (si procede)
Enumere todas las tablas utilizadas en JOIN s (si procede)
Una vez que tenga la información anterior organizado en este fácil de comprender la forma, es mucho más fácil identificar las columnas que potencialmente podrían hacer uso de los índices cuando se ejecuta.