FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Optimización de tiempo de ejecución de Update en Sentencia SQL
Hola a tod@s.
Como sigo siendo algo lelo en temas de SQL os consulto a ver si me podéis echar un cable. Supongamos que tengo dos tablas con los siguientes campos: Código:
MOVIMIENTOS CODIGO CLIENTE TIPO 000001 000001 000002 000001 000003 000002 000004 000001 000005 000002 000006 000003 Código:
CLIENTES CODIGO NOMBRE TIPO 000001 FULANO 1 000002 ZUTANO 1 000003 MENGANO 2
Esto funciona pero si atacamos a una tabla MOVIMIENTOS de unos cuantos miles de registros se hace lento. Necesitaría ver si hay una forma de hacer que solo se actualicen en la tabla MOVIMIENTOS los registros correspondientes a los clientes que tengan un TIPO determinado para acotar el número de registros a actualizar en función de los clientes que tengan ese TIPO determinado, o sea, que solo actualice los registros de la tabla MOVIMIENTOS que afecten a clientes que tengan en la tabla CLIENTES el tipo 1 por ejemplo. No sé si "mexplico". Gracias y un saludo
__________________
Be water my friend. Última edición por nlsgarcia fecha: 18-02-2015 a las 20:12:23. Razón: Sintaxis SQL |
#2
|
||||
|
||||
Añádele la condición que quieres:
De todas formas es raro que sea lento. |
#3
|
||||
|
||||
Hola.
Pensé en la misma opción que te dá Casimiro, pero le agregaría: para evitar que asigne NULL cuando la consulta arroje resultados no coincidentes. Lo que no sé, es si será mas eficiente que la primera... Saludos
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
#4
|
||||
|
||||
En mi opinión, la asignación via subconsulta es muy lenta. Yo haría algo así:
// Saludos |
#5
|
||||
|
||||
Por cierto, ¿nadie va a regañar al forista por tan mala selección de título para su mensaje?
// Saludos |
#6
|
||||
|
||||
Cita:
|
#7
|
||||
|
||||
A Newtron me lo respetan...
|
#8
|
||||
|
||||
Cita:
Gracias a todos, haré pruebas y os comento qué me resulta más eficiente.
__________________
Be water my friend. |
#9
|
||||
|
||||
Bueno.
He hecho pruebas y las soluciones de Casimiro y ecfisa tardan lo mismo que la mía inicial con la diferencia de que, como bien dice ecfisa, con la de Casimiro asigna valor null cuando los resultados no son coincidentes así que nos quedamos como estamos. La consulta de roman no me funciona, me dice exactamente "Expected SET but instead found LEFT", o sea, que después del "UPDATE....." no deja poner otra cosa que no sea "SET ...". Igual eso funciona en Firebird pero en mi base de datos (ElevateDB) no va. Efectivamente el problema de la lentitud es que por cada linea de la tabla MOVIMIENTOS tiene que hacer un SELECT a la tabla CLIENTES para buscar el valor cuando sería bastante más rápido que fuera a buscar primero a la tabla CLIENTES los registros que coincidan con el campo TIPO=loquesea y luego fuera a la tabla MOVIMIENTOS y cambiara solo los de esos clientes, que en este caso serían pocos. Saludos
__________________
Be water my friend. |
#10
|
||||
|
||||
Yo probaría a hacer dos consultas. Primero, encontrar la lista de registros que tienen que actualizarse (y los valores a asignar), y luego hacer la actualización en un bucle. Puede que sea más rápido, o no, que no lo he probado.
|
#11
|
||||
|
||||
Cita:
Gracias por el comentario.
__________________
Be water my friend. |
#12
|
||||
|
||||
Decir mi programa es "Lento", es como cuando dicen "mi programa tiene un problema".
Programador profesional? No se aceptan esas afirmaciones. Por fa: - Define lento - Define rapido - Define tamaño ("cuantos miles"?????) - Usa profiling (DONDE es lento), y en este caso, muestra el plan de ejecucion - Ambiente de ejecución (Que motor, version, RAM, CPU, uso de CPU, RAM, DISCO) = Que exactamente? Pues pa eso es el profiling.
__________________
El malabarista. |
#13
|
||||
|
||||
Cita:
Lento: lo suficiente para preguntar en el foro Rápido: lo suficiente para no preguntar en el foro Tamaño: el de mi tabla real Profiling: es lento desde que empieza hasta que termina // Saludos |
#14
|
||||
|
||||
Cita:
Yo solamente he puesto una sentencia SQL y preguntaba si había forma de optimizarla (como bien me han corregido en el título del post) no creo que para eso haya que dar un informe "hipermegadetallado" de la situación. Gracias por tu interés y un saludo
__________________
Be water my friend. |
#15
|
||||
|
||||
Cita:
Cita:
Para ser mas conciso? Casi siempre se puede reducir a plan de ejecución. Y chico, que motor es??? Dependiendo de cual se puede usar esto o aquello, pero asi en la oscuridad total.... ---- P.D: Y porque eso no esta en un trigger?
__________________
El malabarista. |
#16
|
||||
|
||||
Cita:
Cita:
Esa si que es una buena observación. No está en un trigger porque es un campo que se utiliza en una opción del programa que pueden usar un 1% de los usuarios y creo que no merece la pena montar triggers y un índice en la tabla para mantener ese campo actualizado. Resumiendo, que es lo que hay y ya está, si el usuario tiene que esperar un poco a que se ejecute la instrucción que espere. Gracias a todos por vuestros comentarios y un saludo.
__________________
Be water my friend. |
#17
|
|||
|
|||
Ya se que de esto hace una semana pero tenia ganas de poner algo en el foro.
Mi SQL para SQL Server seria
Espero que ayude. |
#18
|
||||
|
||||
Ok, gracias pero hay algo que no veo claro:
con esto lo que haces es actualizar solo los que en la tabla de movimientos tienen el campo TIPO=NULL, ¿no?. La idea es evaluar en la tabla MOVIMIENTOS solo los movimientos correspondientes a los clientes que tengan X en el campo TIPO sin tener que hacer una búsqueda en la tabla CLIENTES por cada registro de la tabla MOVIMIENTOS. Saludos
__________________
Be water my friend. |
#19
|
|||
|
|||
Buenas newtron,
La clausula where es para updatar solo los que no tienen valor en el campo TIPO, de esta forma optimizamos la consulta y no volvemos a modificar registros que ya tienen un valor correcto. Pero si CLIENTES se modifica en la tabla MOVIMIENTOS después puedes quitar la clausula para modificar todos los registros, aunque no es muy optimo. Saludos. |
#20
|
||||
|
||||
Cita:
Gracias y un saludo
__________________
Be water my friend. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Crear una sentencia para update. | Adrian Murua | MySQL | 8 | 19-10-2012 08:38:16 |
Insertar sentencia SQL despues de Insert,update o delete | vivamotos | Firebird e Interbase | 10 | 02-08-2011 18:24:30 |
Modificar una sentencia SQL en tiempo ejecución | Alexandro | Conexión con bases de datos | 8 | 15-05-2008 17:22:01 |
Sentencia UPDATE | kikecg | SQL | 5 | 16-10-2006 11:23:24 |
Optimizacion de Tiempo | Luis Alberto | Varios | 14 | 09-11-2005 01:11:34 |
|