índices deben ser creados para optimizar la consulta SQL con múltiples o condiciones

tengo una consulta como esta:índices deben ser creados para optimizar la consulta SQL con múltiples o condiciones

SELECT * 
FROM T 
WHERE A = @A AND ([email protected] OR [email protected] OR [email protected] OR @E=E) 
ORDER BY F

Qué índices debo añadir para mejorar el rendimiento de las consultas? También tendré que implementar la paginación para que esta consulta sea más compleja.

Supongo que se deben crear cuatro índices: (A, B, F), (A, C, F), (A, D, F) (A, E, F), pero no soy seguro y realmente no puedo probarlo ya que aún no tengo suficientes datos.

¿Alguien tiene algo de experiencia para compartir? Gracias.

Fuente

2010-09-06 Marko

En Oracle tiene Bitmap Index, con el cual tiene que crear solo 5 índices separados (en A, en B, ...) para cubrir todas sus combinaciones. Funciona mejor para columnas de baja cardinalidad (es decir, que tienen un número bastante limitado de valores posibles, como el género y los colores). Intenta buscar en Google algo como 'ms sql alternative to oracle bitmap index'. Espero que ayude –

Lo intentaré. Gracias – Marko

Además, ten cuidado; un índice puede disminuir el tiempo necesario para disparar consultas SELECT, pero puede aumentar drásticamente el tiempo que tarda una inserción. Esto es algo con lo que hemos tenido que lidiar en nuestra base de datos de producción. – Rob

Los índices generalmente no lo ayudan con este tipo de lógica OR. Al no saber la cantidad de datos que está obteniendo o la complejidad de los objetos, solo puedo hablar subjetivamente pero a menudo es más rápido usar consultas sindicales para ordenar los datos.

SELECT * from T 
WHERE a= @a and B= @b 
UNION 
SELECT * from T 
WHERE a= @a and c= @c 
UNION 
SELECT * from T 
WHERE a= @a and d= @d 
union 
SELECT * from T 
WHERE a= @a and e= @e

Fuente

2010-09-07 07:02:21 u07ch

solo quería decir lo mismo –

tenga en cuenta que UNION elimina duplicados, por lo que su enfoque puede ser lento –

Es un punto válido; esto replica la funcionalidad de la consulta original con índices más discretos que el o enfoque. En mi experiencia en bases de datos de alta rotación de datos, el enfoque de unión es más eficiente que los grandes índices de cobertura ya que el costo del índice en la creación y eliminación de filas es demasiado alto. – u07ch

Un índice de cobertura debería hacer.

created nonclustered index ([IDX_Cover]) 
on dbo.Table (columns to select) 
include (columns in where clause)

Recuerde, seleccione * no es fácilmente indexable. en su lugar, indexe lo que necesita.

Fuente

2010-09-07 14:35:08 DForck42

'select * no es fácilmente indexable' La pregunta de qué índice se utilizará depende de la cláusula where, no de la cláusula select. –

índices deben ser creados para optimizar la consulta SQL con múltiples o condiciones

Respuesta

Cuestiones relacionadas