2011-06-23 10 views
9

estoy procesar un formulario que tiene un montón de campos para un usuario que está editando un registro existente. el usuario puede haber cambiado solo un campo, y normalmente haría una consulta de actualización que establece los valores de todos los campos, aunque la mayoría de ellos no cambian. podría hacer algún tipo de seguimiento para ver qué campos realmente han cambiado, y solo actualizar los pocos que sí lo hicieron. ¿Hay una diferencia de rendimiento entre actualizar todos los campos en un registro vs solo el que cambió? ¿Hay otras razones para ir con cualquiera de los métodos? el método de escopeta es bastante fácil ...(Mi) el rendimiento de SQL: actualización de un campo frente a muchos campos unneccesary

+0

Estoy interesado en la respuesta con respecto al rendimiento específico. Sin embargo, creo que lo dijiste tú mismo - * el método de escopeta es bastante fácil *. Es decir, IMO, independientemente de la optimización que pueda ofrecer la actualización de campo único, vale * la sobrecarga del seguimiento. El rendimiento es un equilibrio. –

+3

MySQL detectará si un campo no cambia y no hará ningún trabajo adicional en él, por lo que la carga no es tan mala como cree. – Johan

+0

gracias, a todos. – changokun

Respuesta

7

yo diría que depende de lo siguiente:

  • El tamaño de los datos que se está procesados ​​
  • La ubicación del servidor de base de datos relativa a la aplicación
  • El tiempo necesario para completar todas las comprobaciones para el cambio de datos

Si va a transferir grandes cantidades de datos y/o la conexión es remota, entonces debe hacer algunas pruebas para ver si puede mejorar el rendimiento mediante el seguimiento de los cambios. De lo contrario, probablemente encontrará que es insignificante suponiendo que un registro está siendo manipulado.

1

Por supuesto, habría algunos gastos generales en la actualización de varios campos, pero la sobrecarga será menor en comparación con el costo de mantener el estado de los campos cambiados. Si esta es una tabla, no me preocuparía actualizar las columnas de forma selectiva según el estado de su formulario.

Además, puede ser útil examinar un marco de base de datos como Hibernate para abstraer algunos de estos detalles.

0

Me gustaría ir por el método de escopeta y es fácil de entender e implementar. El golpe de rendimiento debe ser inaceptable.

2

Si usted está hablando de una cantidad razonable de datos (por ejemplo, 1 kb +), entonces la optimización podría valer la pena. Si esta declaración/tabla se está ejecutando/actualizando frecuentemente (varias veces por segundo?), Por múltiples usuarios, etc., puede valer la pena optimizarla.

ya debe tener una copia de los datos originales, por lo que averiguar lo que ha cambiado no es un gran problema, y ​​tampoco lo es el cambio de la instrucción de actualización para dar cabida a sólo rellene los campos modificados.

lo que no puede ser una mala idea, pero a menos que usted está mirando para ahorrar ancho de banda, o siente que necesita para mejorar el rendimiento, no es probable que sea necesario.

3

yo diría que ir a por la escopeta, pero realmente depende de muchas cosas y el uso que tiene en el PP.

  • ¿Un usuario o millones de usuarios concurrentes?
  • ¿Son los campos pequeños o hay campos de texto/blob grandes también?
  • ¿La aplicación donde se llena el formulario se encuentra cerca de la base de datos o a través de una red o la web?

Hay que tener en cuenta que el UPDATE tendrá que no sólo almacenar el nuevo (incluso los no modificados) Los campos en la tabla sino también:

  • de verificación de claves foráneas actualización
  • todos los índices en los campos actualizados

En todos los casos, sin embargo, puede implementar de la manera más fácil y probar cualquier problema de rendimiento para que sea seguro.

1

En realidad, es posible que pierda rendimiento solo actualizando campos individuales. Si está utilizando declaraciones preparadas, entonces la base de datos ya compiló el plan de consulta para actualizar todos los campos. Si comienza a actualizar campos aleatorios, tendrá que analizar la consulta cada vez que actualice, perdiendo el beneficio de las declaraciones preparadas. No estoy seguro de cuánto efecto tendría esto en MySQL, pero sé que puede ser significativo con SQL Server y Oracle.

Cuestiones relacionadas