UPDATE vs INSERT performance

Question

¿Es correcto suponer que una consulta UPDATE requiere más recursos que una consulta INSERT?

Gracias,

Answer 1

No soy un gurú de la base de datos pero aquí mi granito de arena:

Personalmente no piensa que tiene mucho que hacer en este sentido, incluso si INSERT sería más rápido (todo a ser probado), ¿puedes convertir una actualización en un inserto? francamente, no creo que puedas hacerlo todo el tiempo.

durante un INSERTAR no suele tener que usar DONDE identificar qué fila actualizar, pero dependiendo de sus índices en esa tabla, la operación puede tener algún costo.

durante una actualización si no cambia ninguna columna incluida en ningún índice, podría tener una ejecución rápida, si la cláusula where es lo suficientemente fácil y rápida.

no hay nada escrito en las piedras y realmente me imagino que depende de la configuración de toda la base de datos, índices, etc.

todos modos, éste nos pareció como referencia:

Top 84 MySQL Performance Tips

Answer 2

Depende. Una ACTUALIZACIÓN simple que utiliza una clave principal en la cláusula WHERE y actualiza solo un único campo no indexado probablemente sería menos costoso que un INSERT en la misma tabla. Pero incluso eso depende del motor de base de datos involucrado. Sin embargo, una ACTUALIZACIÓN que implique modificar muchos campos indexados podría ser más costosa que INSERTAR en esa tabla porque se requerirían más modificaciones de clave de índice. Una ACTUALIZACIÓN con una cláusula WHERE mal construida que requiera un escaneo de tabla de millones de registros sería sin duda más costosa que un INSERT en esa tabla.

Estas declaraciones pueden tomar muchas formas, pero si limita la discusión a sus formularios "básicos" que involucran un solo registro, entonces la mayor parte del costo generalmente estará dedicada a modificar los índices. Cada campo indexado que se modifica durante una ACTUALIZACIÓN normalmente implicará dos operaciones básicas (eliminar la clave anterior y agregar la nueva) mientras que INSERT requerirá una (agregue la nueva clave). Por supuesto, un índice agrupado podría agregar algunas otras dinámicas como problemas de bloqueo, aislamiento de transacción, etc. Por lo tanto, en última instancia, la comparación entre estas declaraciones en un sentido general no es realmente posible y probablemente requeriría la evaluación comparativa de declaraciones específicas si realmente importaba

Típicamente, sin embargo, tiene sentido usar la declaración correcta y no preocuparse, ya que generalmente no es una opción elegir entre una ACTUALIZACIÓN y un INSERTAR.

Answer 3

Depende. Si la actualización no requiere cambios de la clave, lo más probable es que solo cueste como una búsqueda y, luego, probablemente cueste menos que una inserción, a menos que la base de datos esté organizada como un montón.

Esto es lo único que puedo decir, porque el rendimiento depende en gran medida de la organización de la base de datos utilizada.

Si, por ejemplo, utiliza MyISAM que supongo que está organizado como un isam, insert debería costar generalmente lo mismo en términos de acceso de lectura de base de datos, pero requerirá alguna operación de escritura adicional.

Answer 4

No se puede comparar un INSERT y una ACTUALIZACIÓN en general. Danos un ejemplo (con definición de esquema) y explicaremos cuál cuesta más y por qué. Además, puede compilar un INSERT concreto y una ACTUALIZACIÓN revisando su plan y el tiempo de ejecución.

Algunas reglas de los pulgares aunque:

• si sólo se actualizan sólo un campo, que no está indexada y sólo se actualizan un registro y se utilizan rowid clave/primaria para encontrar ese registro a continuación, esta actualización tendrá un costo menos de
• un INSERT, que también afectará solo a una fila, aunque esta fila tendrá muchos campos indexados no nulos; y todos esos índices tienen que mantenerse (por ejemplo, agregar una nueva hoja)

Answer 5

En Sybase/SQL Server una actualización que afecta a una columna con un índice de solo lectura se reemplaza internamente por una eliminación y luego una inserción, por lo esto es obviamente más lento que insertar. No conozco la implementación de otros motores, pero creo que esta es una estrategia común, al menos cuando se trata de índices. Ahora, para tablas sin índices (o para solicitudes de actualización que no incluyen ningún índice), supongo que hay casos en los que la actualización puede ser más rápida, según la estructura de la tabla.

Answer 6

El recurso clave aquí es el acceso al disco (IOPS para ser precisos) y debemos evaluar cuáles resultan en un mínimo de eso.

Concuerde con otros acerca de cómo es imposible dar una respuesta genérica, pero algunas reflexiones lo guiarán en la dirección correcta, suponga que una tienda de clave-valor simple y la clave están indexadas. La inserción está insertando una nueva clave y la actualización está actualizando el valor de una clave existente.

Si ese es el caso (un caso muy común), la actualización sería más rápida que la inserción porque la actualización implica una búsqueda indexada y el cambio de un valor existente sin tocar el índice. Puede suponer que se trata de una lectura de disco para obtener los datos y, posiblemente, un disco de escritura. Por otro lado, la inserción implicaría dos grabaciones de disco, una para índice y otra para datos. Pero el otro costo oculto es la división del nodo btree y la creación de un nuevo nodo que ocurriría en segundo plano mientras que la inserción lleva a un mayor acceso al disco en promedio.

Answer 7

Si planea realizar un gran procesamiento (como calificación o facturación para una empresa de telefonía celular), esta pregunta tiene un gran impacto en el rendimiento del sistema.

Realizar actualizaciones a gran escala frente a la creación de muchas tablas e índices nuevos ha demostrado que reduce el proceso de facturación de mi compañía de 26 horas a 1 hora.

Lo he probado en 2 millones de registros para 100.000 clientes. Primero creé la tabla de facturación y luego cada llamada al resumen del cliente, actualicé la tabla de facturación con la duración, precio, descuento ... un total de 10 campos.

En la segunda opción creé 4 fases. Cada fase lee la (s) tabla (s) anterior (es), crea el índice (después de completar la tabla insertada) y usa: "insertar en de seleccionar ..." He creado la siguiente tabla para la siguiente fase.

Resumen Aunque la segunda alternativa requiere mucho más espacio en disco (todas las vistas y tablas temporales eliminado al final) hay 3 ventajas principales de esta opción: 1. era 4 veces más rápido que la opción 1. 2. En caso de que hubiera un problema en el medio del proceso, podría comenzar el proceso desde el punto en que falló, ya que todas las tablas para el comienzo de la fase estaban listas y el proceso podría reiniciarse desde este punto. Si el proceso falla implementando la primera opción, deberá comenzar nuevamente todo el proceso. 3. Esto hizo que el desarrollo y el control de calidad funcionaran mucho más rápido, ya que podían funcionar en paralelo .