2010-01-05 10 views
8

Tengo la siguiente instrucción de selección que termina casi al instante.¿Por qué una ACTUALIZACIÓN toma mucho más tiempo que una SELECCIÓN?

declare @weekending varchar(6) 
set @weekending = 100103 

select InvoicesCharges.orderaccnumber, Accountnumbersorders.accountnumber 
from Accountnumbersorders, storeinformation, routeselecttable,InvoicesCharges, invoice 
where InvoicesCharges.pubid = Accountnumbersorders.publication 
and Accountnumbersorders.actype = 0 
and Accountnumbersorders.valuezone = 'none' 
and storeinformation.storeroutename = routeselecttable.istoreroutenumber 
and storeinformation.storenumber = invoice.store_number 
and InvoicesCharges.invoice_number = invoice.invoice_number 
and convert(varchar(6),Invoice.bill_to,12) = @weekending 

Sin embargo, la instrucción de actualización equivalente toma 1m40s

declare @weekending varchar(6) 
set @weekending = 100103 
update InvoicesCharges 
set InvoicesCharges.orderaccnumber = Accountnumbersorders.accountnumber 
from Accountnumbersorders, storeinformation, routeselecttable,InvoicesCharges, invoice 
where InvoicesCharges.pubid = Accountnumbersorders.publication 
and Accountnumbersorders.actype = 0 
and dbo.Accountnumbersorders.valuezone = 'none' 
and storeinformation.storeroutename = routeselecttable.istoreroutenumber 
and storeinformation.storenumber = invoice.store_number 
and InvoicesCharges.invoice_number = invoice.invoice_number 
and convert(varchar(6),Invoice.bill_to,12) = @weekending 

Incluso si añado:

and InvoicesCharges.orderaccnumber <> Accountnumbersorders.accountnumber 

al final de la instrucción de actualización reducir el número de escrituras a cero, toma la misma cantidad de tiempo.

¿Estoy haciendo algo mal aquí? ¿Por qué hay una gran diferencia?

+0

La cláusula adicional AND sigue siendo una buena idea, ¿por qué actualizar 50,000 filas cuando solo necesita actualizar 2? – HLGEM

Respuesta

21
  • archivo de registro de transacciones escribe
  • actualizaciones del índice
  • Búsquedas de clave externa
  • cascadas de clave externa
  • vistas indizadas
  • columnas calculadas
  • restricciones de comprobación
  • cerraduras
  • pestillos
  • extensión de bloqueo
  • aislamiento de instantánea
  • DB reflejo
  • crecimiento archivo
  • otros procesos de lectura/escritura
  • divisiones de página/índice agrupado inadecuada
  • casos de sobre flujo hacia adelante puntero/fila
  • pobres índices
  • estadísticas fuera de fecha
  • mala distribución del disco (por ejemplo, una gran RAID para todo)
  • Restricciones de comprobación con las UDF que tienen acceso a la tabla
  • ...

Aunque, el sospechoso habitual es un disparador ...

Además, su condición extra no tiene ningún significado: ¿cómo sabe SQL Server ignorarla? Aún se genera una actualización con la mayor parte del equipaje ... incluso el gatillo aún se disparará.Cerraduras deben ser sostenidos cuando las filas se buscaron otras condiciones, por ejemplo

Editado Sep 2011 y 2012 FEB con más opciones

+2

Sí, un desencadenante fue la causa. Soy nuevo en esto y el "código" no es mío. Gracias por el aviso. Agregué la condición adicional porque pensé que podría tomar mucho tiempo escribir en el disco, por lo que no hubo escrituras innecesarias en el disco. Una vez más, muchas gracias. – Nodja

+0

+1. Buena respuesta. –

+0

Y, especialmente, los desencadenantes que están "diseñados" para desplazarse por todas las filas en lugar de ejecutarse de forma predeterminada. – HLGEM

1

Porque la lectura no afecta a los índices, desencadenantes y ¿qué tiene?

6

La actualización debe bloquear y modificar los datos en la tabla, y también registrar los cambios en el registro de transacciones. El seleccionado no tiene que hacer ninguna de esas cosas.

+0

Nitpick: * Puede * tener DML en una instrucción SELECT, simplemente no está escrito ... a menos que sea un INSERT INTO ... SELECT ... –

+1

Y también modifique cualquier índice en la tabla. Cuantos más índices, más larga es la escritura. – womp

+0

entonces ¿por qué toma mucho tiempo incluso con la condición adicional? No debería haber cambios en las tablas, pero aún lleva mucho tiempo. – Nodja

1

En servidores lentos o gran base de datos que suelen utilizar ACTUALIZACIÓN retraso, que espera una "ruptura" para actualizar la base de datos en sí.

Cuestiones relacionadas