2010-03-15 6 views
7

Al medir el rendimiento en mi consulta me ocurrió con una dependencia entre el nivel de aislamiento y el tiempo transcurrido que fue sorprendente para míqué mejor nivel de aislamiento significa un mejor rendimiento en SQL Server

READUNCOMMITTED - 409024 
READCOMMITTED - 368021 
REPEATABLEREAD - 358019 
SERIALIZABLE - 348019 

la columna izquierda es mesa de pista, y la columna de la derecha es el tiempo transcurrido en microsegundos (sys.dm_exec_query_stats.total_elapsed_time). ¿Por qué un mejor nivel de aislamiento ofrece un mejor rendimiento? Esta es una máquina de desarrollo y no ocurre concurrencia alguna. Esperaría que READUNCOMMITTED fuera el ayuno debido a una menor sobrecarga de bloqueo.

Actualización: Me hice medir esto con

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE 

emitidas y perfiles confirma Todavía no hay aciertos de caché sucediendo.

+0

Estoy seguro de que tengo ese hábito, gracias por el recordatorio. Remus me ha proporcionado una contribución bastante valiosa, aunque todavía espero tener una idea de por qué ocurre el fenómeno que observo. –

Respuesta

4

En primer lugar, debe ejecutar la consulta varias veces debajo de cada nivel de aislamiento y promediar el resultado, descartando el que tenga el tiempo máximo. Esto eliminará el impacto de calentamiento del búfer: desea que todas las ejecuciones estén en un caché cálido, que una consulta no caliente el caché y pague la penalización en comparación.

A continuación, debe asegurarse de medir en un escenario de simultaneidad realista. SI tendrá actualizaciones/inserciones/eliminaciones en la vida real, entonces debe agregarlas a su prueba, ya que afectarán tremendamente las lecturas en varios niveles de aislamiento. Lo último que desea es concluir que "las lecturas serializables son más rápidas, permite usarlas en todas partes" y luego ver cómo el sistema se derrite en la producción porque todo está serializado.

Aparte de eso, el único nivel de aislamiento que es legítimamente más rápido es el sucio lee, ya que no adquiere bloqueos. La instantánea de lectura confirmada (que no midió) tampoco adquiere bloqueos, pero sí afecta el rendimiento en general debido a la sobrecarga de las versiones de las filas.

+0

Encuentre actualizaciones de mi pregunta para abordar algunos de los puntos en su respuesta. Por "lecturas sucias" te refieres a READUNCOMMITTED, ¿no? –

+0

1) La ejecución de la consulta en un caché frío no es precisa. Sus consultas de producción no se ejecutarán en un caché frío, optimizará un escenario poco realista y no mide la consulta, realmente está midiendo el rendimiento de lectura del disco. También necesita medir el rendimiento en un caché cálido y realizar un seguimiento de ambos (tiempo de ejecución en frío, tiempos de ejecución cálidos). 2) las lecturas sucias se leen sin compromiso. –

+0

¿Cuán relevante es la memoria caché para una consulta grande (millones de filas) que en circunstancias normales se ejecuta solo una vez para datos particulares? –

0

Ahora que entiendo mejor los niveles de aislamiento, veo que un mejor nivel de aislamiento podría permitir algunas optimizaciones inteligentes. Por ejemplo, una vez que la transacción se lee, algún nivel de aislamiento de datos puede estipular que debe usar esa información hasta el final en lugar de intentar volver a leerla desde el disco.

Todavía estaría interesado en leer un vistazo en profundidad sobre esto.

Cuestiones relacionadas