Cómo reducir agrupado coste recorrido de índice mediante el uso de consulta SQL

¿Cómo puedo reducir el costo de exploración índice agrupado de consultaCómo reducir agrupado coste recorrido de índice mediante el uso de consulta SQL

DECLARE @PARAMVAL varchar(3) 

set @PARAMVAL = 'CTD' 
select * from MASTER_RECORD_TYPE where [email protected]

mencionados a continuación si se me acaba la consulta anterior que estaba mostrando recorrido de índice 99%

encuentre aquí más adelante mis particularidades de mesa:

enter image description here

aquí abajo he pegado mi índice para la tabla:

CREATE TABLE [dbo].[MASTER_RECORD_TYPE] ADD CONSTRAINT [PK_MASTER_REPORD_TYPE] PRIMARY KEY CLUSTERED 
(
    [Record_Type_Id] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY] 
GO

amablemente asesorar cómo puedo reducir el costo de escaneo de índice?

Fuente

2012-08-06 user1494292

En primer lugar, si busca RECORD_TYPE_CODE, debe asegurarse de tener un índice en esa columna.

Además de eso principalmente dos cosas:

No uso SELECT * - que siempre tendrá que volver al índice agrupado para obtener la página completa de datos; utilice un SELECT que especifica explícitamente las columnas que se utilizan
si es que es posible, tratar de encontrar una manera de tener una cubriendo índice no agrupado, por ejemplo, un índice que contiene todas las columnas necesarias para satisfacer la consulta

Si usted tiene un índice no agrupado tal que cubre, a continuación, el optimizador de consultas más probable es que el uso que cubre índice (en lugar del índice agrupado real que es la completa datos de la tabla) para obtener los resultados

Fuente

2012-08-06 10:26:46

gracias por su pronta respuesta, puede usted por favor me guía para crear un índice no agrupado que cubre, qué claves para ser incluido en ese índice me puede ayudar a su compañero en esta – user1494292

CREAR NONCLUSTERED ÍNDICE [MST_IDX_FOR_REC_TYPE ] ENCENDIDO [dbo].[MASTER_RECORD_TYPE] ( \t [Record_Type_Code] ASC ) con (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, LÍNEA = OFF, ALLOW_ROW_LOCKS = ON, allow_page_locks = ON) ON [PRIMARY ] IR Ahora el escaneo del índice se ha convertido en la búsqueda del índice del 100% – user1494292

@ user1494292: OK - entonces ahora tiene el ** index seek ** - que es la manera más eficiente (y más rápida) de buscar (algunas filas) of) data –

Debe probar y usar un índice cubierto. Pero el problema que vas a tener es que estás usando SELECT *. ¿Realmente necesitas todo el disco?

De cualquier manera, agregue RECORD_TYPE_CODE a otro índice y ayudará con la consulta porque al menos ese campo se puede leer de una página de índice.

Fuente

2012-08-06 10:27:47

hi mate, gracias por su pronta respuesta, aunque si uso select 1 de Master_record_type entonces también el mismo costo de escaneo de índice estaba lanzando – user1494292

En su consulta, ha utilizado la columna RECORD_TYPE_CODE que no es parte de clustered index y tampoco está incluida en ninguna non-clustered index. Entonces SQL Optimizer decidirá escanear el índice agrupado para hacer la comparación del predicado cláusula where.

Why is there a scan on my clustered index?

Fuente

2012-08-06 10:32:34 sundar

Um, sí, es parte del índice agrupado = la tabla. No hay otro índice. – Suncat2000

Cómo reducir agrupado coste recorrido de índice mediante el uso de consulta SQL

Respuesta

Cuestiones relacionadas