2012-02-02 7 views
7

estoy recibiendo las filas en orden diferente cuando uso¿Por qué "SET TRANSACTION ISOLATION LEVEL LECT UNCOMMITTED" devuelve las filas en orden diferente?

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 

en mi procedimiento almacenado.

A continuación se muestra la consulta definida en el procedimiento almacenado.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; 

SELECT CaseRateDetailId,AmtPerWeek 
FROM CaseRateDetails 
WHERE CaseRateInfoId = @CaseRateInfoId 

Devuelve AmtPerWeek así:

10000,15000,5000,20000,25000,.. 

Cuando ejecuto la misma consulta sin utilizar

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 

comunicado que devuelve las filas en el orden correcto es decir 5000,10000,15000,20000,25000,....

Puedo usar el orden por la cláusula AmtPerWeek en la consulta anterior, pero quiero saber el ¿Por qué se está comportando así? ¿Por qué está cambiando el orden de las filas?

+8

No hay una orden ** correcta ** sin una orden por cláusula. –

+3

No 'ORDER BY' -> no hay orden definido o garantizado o implícito - si necesita un pedido, necesita tener un' ORDER BY' - ** always. ** –

+4

+1 para "pero quiero saber la razón por la cual se está comportando así ". –

Respuesta

10

En NOLOCK o TABLOCK puede obtener un allocation ordered scan que lee las páginas en orden de archivo en lugar de seguir el nivel de hoja de un índice.

No aparece en el plan de ejecución si usa este método o no. Sin ORDER BY no se garantiza la orden.

+0

Eso es fascinante: tienes razón, no aparece en el plan de presentación. Eliminé mi respuesta ya que has probado que estaba mal. – Ben

+1

@Ben - Cuando el plan muestra un escaneo de índice con 'Ordered: False' el motor relacional indica que no le importa en qué orden se devuelven las filas, lo que significa que el motor de almacenamiento considerará esto como una opción preferible para los índices> 64 páginas y donde los datos no pueden cambiar (tablock) o el nivel de aislamiento es tal que prefiere la velocidad a cualquier garantía de consistencia. Los escaneos ordenados por asignación son mucho más propensos a perder filas o leer filas dos veces en condiciones de modificaciones concurrentes de datos que un escaneo ordenado por índice. –

+0

Woah, buena captura! – Alexandre

Cuestiones relacionadas