none
Creación de índices RRS feed

  • Pregunta

  • Buenos días.

    Estoy realizando un procedimiento almacenado, y estoy viendo que al añadir un JOIN con una tabla para realizar un COUNT se demora la consulta demasiado.

    Le doy a Mostrar plan de ejecución estimado, y me aparece lo siguiente:

    El procesador de consultas estima que la implementación del siguiente índice podría mejorar el costo de la consulta en un 99.6022%.

    /*
    USE [pruebas]
    GO
    CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
    ON [dbo].[user] ([origin_id],[date_join])
    INCLUDE ([hardbounce])
    GO
    */

    Pero no suelo realizar consultas para hardbounce, es más es una columna que apenas uso pero en esa consulta la utilizo, es más la tabla que hago el join no tiene nada que ver con la columna hardbounce.

    ¿Debería hacer caso a la ayuda que proporciona SQLSERVER y crear ese index, para mejorar la consulta?

    Gracias.

    martes, 24 de mayo de 2016 8:18

Respuestas

  • Saludos

    Puedes crear el índice sin el include, esto lo que hace es parte de lo que el motor por sus datos ve que incluyes en el select o en el cuerpo principal de tu query pero no es algo que afecte de gran manera el desempeño del indice.

    • Marcado como respuesta dudasc jueves, 15 de diciembre de 2016 8:06
    martes, 24 de mayo de 2016 17:52
  • [...] la tabla que hago el join no tiene nada que ver con la columna hardbounce.

    La cláusula INCLUDE en el índice no sirva para BUSCAR por ese campo, sino para hacerlo disponible para que salga en la lista de columnas del SELECT. Seguro que la consulta que estás optimizando devuelve esa columna (aunque no busque por ella ni intervenga en el JOIN). Al incluirla en el índice, se evita un salto desde el índice nonclustered hacia heap o el clustered index, con lo que la consulta se resuelve más rápido.
    • Marcado como respuesta dudasc jueves, 15 de diciembre de 2016 8:06
    miércoles, 25 de mayo de 2016 5:13

Todas las respuestas

  • Saludos

    Puedes crear el índice sin el include, esto lo que hace es parte de lo que el motor por sus datos ve que incluyes en el select o en el cuerpo principal de tu query pero no es algo que afecte de gran manera el desempeño del indice.

    • Marcado como respuesta dudasc jueves, 15 de diciembre de 2016 8:06
    martes, 24 de mayo de 2016 17:52
  • [...] la tabla que hago el join no tiene nada que ver con la columna hardbounce.

    La cláusula INCLUDE en el índice no sirva para BUSCAR por ese campo, sino para hacerlo disponible para que salga en la lista de columnas del SELECT. Seguro que la consulta que estás optimizando devuelve esa columna (aunque no busque por ella ni intervenga en el JOIN). Al incluirla en el índice, se evita un salto desde el índice nonclustered hacia heap o el clustered index, con lo que la consulta se resuelve más rápido.
    • Marcado como respuesta dudasc jueves, 15 de diciembre de 2016 8:06
    miércoles, 25 de mayo de 2016 5:13