Reducir las búsquedas clave

Question

Estoy usando SQL Server y he estado mirando de cerca el concepto de búsqueda clave,

http://blog.sqlauthority.com/2009/10/07/sql-server-Query-optimization-remove-bookmark-ighting-remove-rid-lookup-remove-key-lookup/

Entonces, si tiene una búsqueda clave, puede crear un índice con las columnas 'incluir' para cubrir las columnas que no tienen índice que tenga en la instrucción SELECT.

Por ejemplo,

SELECT ID, FirstName FROM OneIndex WHERE City = 'Las Vegas'
GO

Este índice incluirá una búsqueda clave,

CREATE NONCLUSTERED INDEX [IX_OneIndex_City] ON [dbo].[OneIndex]
(
[City] ASC
) ON [PRIMARY]
GO

Pero este eliminará la búsqueda de llave,

CREATE NONCLUSTERED INDEX [IX_OneIndex_Include] ON [dbo].[OneIndex]
(
City
) INCLUDE (FirstName,ID) ON [PRIMARY]
GO

Quiero decir, ¿cuánto impacto tendrá esto en el rendimiento? La búsqueda clave tiene un costo de operador de 0.295969 (99%), pero ¿qué significa eso realmente?

¿Cómo sabe que necesita el segundo índice allí, y en qué punto se convierte en el caso que está tratando de agregar demasiados índices y no vale la pena?

Me parece que algunas consultas pueden incluir escaneos índices, búsqueda clave y aún parecen funcionar muy rápido.

Answer 1

Imagine que la compañía telefónica tiene una lista de números de teléfono, incluido quién es el cliente, dónde vive, cuál es su número de facturación, etc. La clave principal podría ser el número de teléfono.

Te dan las páginas blancas. Eso es como un índice no agrupado, que ordenó por nombre, incluidas columnas como la dirección.

Si desea encontrar todos los Farleys en el libro y está interesado en sus direcciones, entonces las páginas blancas son todo lo que necesita. Puede buscar rápidamente a los Farleys (encontrar el FS, etc.), y luego tiene toda la información que necesita.

Pero si desea sus números de facturación, entonces debe hacer una búsqueda. Puede encontrar rápidamente todos los números de teléfono de los Farleys, pero luego debe tomar cada uno de ellos (cientos) y hacer otra búsqueda (búsqueda) en el índice principal (agrupado), el que ordena el número de teléfono. Cada uno de ellos es aproximadamente el mismo costo que la búsqueda de encontrar los Farleys, lo que empeora su consulta de magnitud.

Y hay un umbral. En algún momento, la base de datos se dará cuenta de que es más rápido pasar por cada página del índice agrupado, verificando cada registro para ver si es de interés.

En serio, deshazte de las búsquedas. Sus consultas pueden ser rápidas ahora, pero probablemente no se escalarán.

Answer 2

Fondo

En el peor de los casos, una consulta que contiene una búsqueda debe ir al almacenamiento físico para filas que requieren datos de columna no cubiertos por el índice no agrupado. En el muy peor De los peores casos, cada búsqueda requerirá una E/S separada, y la ejecución tendrá que esperar a que regrese los datos de esa sola fila antes de continuar. Este escenario generalmente tiene graves implicaciones de rendimiento si la búsqueda tiene que procesar un importante número de filas.

Es por eso que las búsquedas obtienen una prensa tan mala. Por otro lado, considere que se introdujo la capacidad de hacer búsquedas en SQL Server 2000. En SQL Server 7.0, el procesador de consultas solo podía usar un índice no agrupado si se contenía todos la información necesaria para satisfacer la consulta; En todos los demás casos, tuvo que acceder a los datos a través de un índice agrupado (si está presente, o un escaneo de montón de otra manera). Si las búsqueda siempre fueran muy malas, SQL Server seguramente nunca las habría introducido.

En SQL Server 2000+, entonces, donde tenemos un índice no agrupado que proporciona pedidos útiles y/o (la mayoría de) las columnas requeridas por una consulta, y donde es probable que el número de búsquedas sea relativamente pequeño, utilizando el índice no agrupado y la realización de rendimiento a número limitado Es probable que las búsquedas en la tabla base sean el método de acceso más barato disponible (aunque un índice no agrupado completamente cubierto podría ser aún más barato, por supuesto).

En muchos casos, es solo no practico Para crear tantos índices no agrupados como se necesitaría para evitar escanear la tabla base para todas las consultas comunes. Una razón podría ser que INSERT/UPDATE/DELETE/MERGE El rendimiento es más importante que la velocidad de consulta (recuerde que las operaciones de modificación de datos también deben mantener todos los índices no agrupados afectados). Otra razón podría ser el espacio; Cada índice no agrupado representa una copia de un subconjunto de las columnas de la tabla base (o expresiones al respecto) simplemente se clasifica de manera diferente. Más copias de los datos significa más espacio de almacenamiento y más cosas que compiten por el espacio en la memoria caché de datos en memoria de SQL Server.

Otras veces, podemos crear solo algunos índices adicionales (tal vez filtrados en SQL Server 2008+) con suficiente INCLUDE columnas para satisfacer la gran mayoría de las consultas críticas de rendimiento, sin comprometer demasiado el rendimiento de la modificación de datos y sin usar demasiado espacio de disco adicional. Equilibrar las consideraciones competitivas es lo que hace que el índice ajuste más arte que la ciencia.

Costo

Preguntas cuál es el costo del 99% para el operador de búsqueda realmente medio en el plan de consulta. El componente de costos del optimizador de consulta produce un estimado Costo para esa operación que es el 99% del total estimado para la consulta. El número en sí (0.29) no significa mucho en absoluto; Para todos los efectos prácticos, debe considerarlo como un número sin unidad utilizado internamente por el optimizador al comparar estrategias alternativas para esa consulta específica.

El costo estimado no tiene en cuenta su hardware, configuración, necesidades de aplicaciones o mucho más. El modelo de costo utilizado por el optimizador incluye un número significativo de heurísticas y supuestos simplificadores que suceder Producir planes razonables la mayor parte del tiempo, para la mayoría de las consultas, en la mayoría de los hardware. Eso no quiere decir que haya no correlación entre los operadores de alto costo en planes y rendimiento; Más bien, el enlace a menudo es mucho más débil de lo que comúnmente esperaba. Por supuesto, verifique primero las razones para los operadores de planes de costo de alto estimado, pero no trate la información como otra cosa que no sea una estimación muy posiblemente defectuosa.

Impacto

También quiero mencionar un par de factores que pueden mejorar el impacto de las búsquedas. Primero, mencioné justo al principio que el peor de los casos involucra E/s física de fila por fila. Obviamente, esto se evitará si las páginas de datos (índice agrupado o montón) necesitaban satisfacer las búsquedas ya están en la memoria (caché de datos). Cuando este es el caso, la diferencia de tiempo de ejecución entre un plan con una búsqueda versus un índice de cobertura puede ser inconmensurable. Incluso cuando se requiere E/S física, si el número de lecturas es pequeña, aún no le importa. (La probabilidad de que las páginas de datos para una tabla estén en el caché de datos dependan de muchos factores y serán específicas de su hardware y circunstancias).

Donde se necesita más de una pequeña E/S física, el impacto de las búsquedas aún puede reducirse por las optimizaciones presentes en el plan de consulta. Si SQL Server espera que el número de búsquedas sea significativa, puede optar por ordenar explícitamente las filas que ingresan a los bucles anidados que se unen a la búsqueda en el orden de las claves no agrupadas. Este reordenamiento promueve la lectura secuencial del índice no agrupado, que puede ser mucho más rápido que la E/S aleatoria en su hardware.

Con o sin un tipo explícito, los bucles anidados se unen a conducir la búsqueda pueden tener el WithOrderedPrefetch o WithUnorderedPrefetch atributos presentes. En cualquier caso, el motor de ejecución de consultas 'mira hacia adelante' en la secuencia de clave de índice que impulsa las búsquedas y problemas leer por adelantado lectura. La idea es emitir asincrónico Lea las solicitudes al sistema de E/S para páginas de datos que se necesitarán pronto, de modo que para cuando la búsqueda necesita una página de datos, ya esté presente en la memoria.

En condiciones ideales (baja fragmentación, buen plan de consulta, sistema de E/S de alto rendimiento), el mecanismo de lectura puede ser lo suficientemente rápido como para evitar que incluso los planes de consulta paralelo grandes que esperen en la E/S se completen. Esto es especialmente cierto en Enterprise Edition, que puede emitir solicitudes de E/S únicas muy grandes (hasta 2 MB por solicitud si la memoria sirve). Por otro lado, en condiciones menos que ideales (¡más normales!), Su consulta puede sufrir horriblemente, ya que espera en las largas colas de E/S, o no puede impulsar el sistema de E/S lo suficiente. El peor de los casos de búsqueda clave puede ser muy pobre.

Resumen

En resumen, lo harás en general quiero evitar las búsquedas donde tiene sentido hacerlo. Para pequeñas consultas (que van a seguir siendo pequeñas), puede decidir que la sobrecarga de índices adicionales (espacio y mantenimiento) no está justificado, dado el debido peso a las necesidades más amplias del sistema y sus usuarios.

En última instancia, todo esto es parte del arte y la ciencia que es el desarrollo y la administración de la base de datos.