como evitar que mysql se cuelgue despues de un UPDATE

el_apronte · #1 (**permalink**) 21/11/2011, 15:55

Hola amigos, vengo buscando documentación para ver si consigo hacer updates en una tabla mediana que me está trayendo muchos dolores de cabeza (18000 filas y unas 60 columnas, la gran mayoría booleanas) pero no hay caso...

He leído quienes aconsejan trabajar bases de datos paralelas, otros que hablan de dividir el update y la verdad es que no sé que es lo mejor... También estoy evaluando dividir la tabla en tres tablas distintas...

Ya optimicé los select y los update como aconsejan los manuales pero no hay caso, en las horas pico, cuando algún usuario actualiza la tabla se queda colgada...
Había pensado, y me gustaría saber vuestra opinión, hacer el update a una tabla con idénticos campos y luego volcar desde esa tabla el update a la tabla principal para evitar que mysql trabe la tabla mientras se actualiza, pero no tengo claro, si esto podría servir, o si es mejor trabajar con tablas temporales... en fin, si alguien me puede dar una pista por donde buscar info para solucionar el problema se los voy a agradecer!
Saludos y gracias por adelantado!

quimfv · #2 (**permalink**) 22/11/2011, 03:30

Habria que ver el diseño que tienes, y el tipo de updates que haces.

Por otro lado trabajar con tablas paralelas (tablas que no bases) es peligroso ya que te puede dejar el sistema incoherente, imagina que un usuario esta actualizando en la tabla paralela y otro consulta la principal, o tambien la quiere modificar....

Como se hace la selección de los registros a modificar?
Tienes indices sobre los campos de esa selecció?
Se modifican la 60 columnas con la misma frecuencia?
Entre las no booleanas, hay campos especiales (LONG TEXT, binarios...)?
Tambien se modifican con la misma frecuencia?
...

Como ves dificilmente podemos decirte nada con lo que nos dices.....

el_apronte · #3 (**permalink**) 22/11/2011, 12:43

Hola quimfv gracias por tu respuesta, te cuento:
Lo de trabajar las tablas paralelas que pueda dejar el sistema incoherente no lo comprendo, quizas sea porque no me he explicado bien.

Es una web de inmobiliaria donde cada usuario maneja su stock.
seleccionan su propiedad por ID y tras los cambios en un form se realiza el UPDATE

Durante este proceso es que he detectado que mysql se queda colgado, pero no es que traba la tabla y enseguida vuelve a estar arriba, sino que se queda colgada hasta que reinicio los servicios....

Si, tengo un único índice sobre el campo "Activo" quizás sea eso ?

Aquí dejo la estructura de la tabla, veo que me he quedado corto con las 60 columnas, son algunas más...
Gracias de antemano

`IDPropiedad` int(11) NOT NULL auto_increment,
`Activo` tinyint(1) default '0',
`Fecha1` date default NULL,
`Fecha2` date default NULL,
`Fecha3` date default NULL,
`IDDestino` int(11) default '0',
`IDTipoInmueble` int(11) default '0',
`Ambientes` int(11) default NULL,
`Dormitorios` int(11) default '0',
`IDZona` int(11) default '0',
`IDCiudad` int(11) default '0',
`Moneda` char(3) NOT NULL default 'USD',
`Precio` int(11) default '0',
`Dueno` tinyint(1) default '0',
`IDAnunciante` int(11) default '0',
`telefono` varchar(20) NOT NULL default '',
`Ubicacion` varchar(255) default NULL,
`NumeroCalle` int(11) default '0',
`Piso` varchar(7) default NULL,
`Puerta` varchar(12) default NULL,
`Superficie` int(11) default '0',
`AptoProf` tinyint(1) default '0',
`Dependencia` tinyint(1) default '0',
`Cochera` tinyint(1) default '0',
`ymedio` tinyint(1) default '0',
`MasCuotas` tinyint(1) default '0',
`Lavadero` tinyint(1) default '0',
`Baulera` tinyint(1) default '0',
`Antiguedad` varchar(5) default NULL,
`PorEscalera` tinyint(1) default '0',
`Orientacion` varchar(10) default NULL,
`Disposicion` varchar(15) default NULL,
`Plantas` char(2) default NULL,
`Salones` char(1) default NULL,
`Banos` char(2) default NULL,
`Aseos` char(2) default NULL,
`Terrazas` char(2) default NULL,
`Balcones` char(2) default NULL,
`Patio` char(2) default NULL,
`Jardines` char(2) default NULL,
`Expensas` varchar(50) default NULL,
`Superficie_Ext` int(11) default '0',
`Amueblado` tinyint(1) default '0',
`AireA` tinyint(1) default '0',
`Piscina` tinyint(1) default '0',
`Ascensor` char(1) default '0',
`Reservado` tinyint(1) default '0',
`Parrilla` tinyint(1) default '0',
`Estado` varchar(20) default NULL,
`horade1` varchar(5) default NULL,
`horahasta1` varchar(5) default '0',
`horade2` varchar(5) default '0',
`horahasta2` varchar(5) default '0',
`horade3` varchar(5) default '0',
`horahasta3` varchar(5) default '0',
`Alarma` tinyint(1) default '0',
`AptoHipoteca` tinyint(1) default '0',
`Sum` tinyint(1) default '0',
`EspacioAereo` tinyint(1) default '0',
`FechaAlta` date default '2011-05-10',
`DescripcionDetallada` text,
`PalierPriv` tinyint(1) default '0',
`Vestidor` tinyint(1) default '0',
`Escritorio` tinyint(1) default '0',
`Toilette` tinyint(1) default '0',
`DobEntrada` char(1) default NULL,
`Urgente` tinyint(1) default '0',
`Laundry` tinyint(1) default '0',
`Solarium` tinyint(1) default '0',
`Vistas` char(1) default NULL,
`Sauna` tinyint(1) default '0',
`Suite` tinyint(1) default '0',
`Recepcion` tinyint(1) default '0',
`SalFiestas` tinyint(1) default '0',
`Gym` tinyint(1) default '0',
`PlayRoom` tinyint(1) default '0',
`LosaRad` tinyint(1) default '0',
`Parquet` tinyint(1) default '0',
`Jacuzzi` tinyint(1) default '0',
`Hidromasaje` tinyint(1) default '0',
`Quincho` tinyint(1) default '0',
`Categoria` tinyint(1) default '0',
`Seguridad` tinyint(1) default '0',
`Amenities` tinyint(1) default '0',
`original` text,
`modificado_anunciante` tinyint(1) default '0',
`Destacado` char(1) default NULL,
PRIMARY KEY (`IDPropiedad`),
KEY `Activo` (`Activo`)

el_apronte · #4 (**permalink**) 22/11/2011, 21:05

anteriormente tenia claves en `IDDestino``IDTipoInmueble``IDZona` y `IDCiudad` pero las quité porque pude apreciar que las consultas eran mas lentas...
quizás no hice bien ( ? ) y es preferible que tarden un poco mas las consultas pero que sea mas estable... no lo sé
como podrán ver, voy dando manotazos de ahogado...
ya he probado tantas cosas con tal de no dividir la tabla en varias (que es un trabajo chino que preferiría no hacer)
Y si hago un replace en vez de un update? podría ayudar?

gnzsoloyo · #5 (**permalink**) 22/11/2011, 21:36

Perdona que intervenga en algo que ya quimfv está tratando contigo, pero a mi entender lo que tienes es un diseño muy malo para ese tipo de sistemas. Una tabla para definir una propiedad no necesita de semejante cantidad de columnas, porque se establece por medio de un sistema de entidades con relaciones donde defines qué es lo que la propiedad tiene en función de los items que se le agregan en tablas relacionales, donde se vincula con otras tablas que describen los tipos de ambiente, o los electrodomésticos con que cuenta, la cantidad de habitaciones, la ubicación, su tipo, etc.
En otras palabras: Esa tabla en realidad está integrando lo que debería ser un conjunto de tablas mejor diseñadas.
Por allí empieza tu problema.

A ciencia cierta no sé si vas a poder mejorar tu performance sin tener que rediseñar toda la base.

el_apronte · #6 (**permalink**) 22/11/2011, 21:52

Cita:

Iniciado por gnzsoloyo

En otras palabras: Esa tabla en realidad está integrando lo que debería ser un conjunto de tablas mejor diseñadas.
Por allí empieza tu problema.

A ciencia cierta no sé si vas a poder mejorar tu performance sin tener que rediseñar toda la base.

gnzsoloyo; Gracias por intervenir!
y es lo que me temía...
solo que a esta altura plantearme dividir esa tabla se me hace como escalar el everest... despues de una maratón de 42 km...
por eso estoy tratando por todos los medios de no hacerlo y como no controlo mucho la optimización de tablas, mas bien lo vengo experimentando a ensayo error, quería consultar si no había algo obvio que no estuviera viendo mas alla del diseño que me comentas...
¿Podría ayudar meter las especificaciones dentro de un único campo separado pero ejemplo por comas? o estaría mas o menos en lo mismo?
Gracias de antemano!

gnzsoloyo · #7 (**permalink**) 22/11/2011, 22:06

Cita:

¿Podría ayudar meter las especificaciones dentro de un único campo separado pero ejemplo por comas? o estaría mas o menos en lo mismo?

No. Eso se denomina campo multivaluado, y no sólo están prohibidos en las bases de datos, sino que lo único que te producirían serían más problemas.

Lo que si es cierto es que sin saber qué tanto impactan los cambios y cuáles son los más habituales, estamos hablando un poco en el aire... Lo que me extraña es que comentes que se "cuelga" al hace un UPDATE, como si hubiese algún tipo de inconsistencias en el proceso.
¿Está controlada la concurrencia de usuarios?

Por cierto, a lo que se refiere quimfv con "incoherencias" entre tablas paralelas es que si no se mantiene una actualización entre ambas, al hacer cambios en una, pero no en la otra en el mismo registro se produce lo que se denomina "inconsistencia de datos", ya que tienes el mismo registro con datos contradicgtorios entre ambas.
¿Se comprende?
Usar tablas "paralelas" no es solución, a menos que implementes sistemas de replicación y balanceo de datos.

el_apronte · #8 (**permalink**) 22/11/2011, 22:45

Comprendido lo de campo multivaluado, seguiré tu consejo, ya lo descarto

Creo que lo que yo llamaba "tablas paralelas" es algo que leí por ahí (vengo leyendo mucho y cada vez voy mas confundido...) y lo mas probable es que sea algo como lo que me decís de sistemas de replicación y balanceo de datos. Lo que yo comprendí es que sugerían usar dos servidores sincronizados, pero no me enteré mucho porque descarté la idea de solo pensar en dos servidores (se me hace insostenible técnica y monetariamente...)

Pude observar es que no hay problema mientras los usuarios crean nuevas filas dentro de la tabla, pero si cuando actualizan algún dato (en general fechas para reactivar la publicación) y casi siempre tiene que ver en horas pico de visitas o cuando tengo algún robot haciendo sus múltiples peticiones... (pero quizás esto sea casualidad y no tenga nada que ver)
Me preguntas si tengo controlada la concurrencia de usuarios ¿te refieris a si tengo limitada concurrencia de los usuarios? no... o controlada a qué nivel? estadísticas? (perdón si es muy obvio lo que me preguntas pero no me entero)

Si comprendo lo que me dices de la incoherencia, pero lo que yo planteaba es lo siguiente:
pongamos por caso que hago un update en una tabla2 donde el público no realiza consultas. Esta actualización entiendo que no ocasionaría problemas con trabas para la escritura y el update se haría rápida y correctamente. Una vez tengo actualizada la tabla2 vuelco internamente la fila actualizada a la tabla1 que es idéntica y es donde hace las consultas el público. Esto trabaría la tabla igual que si hago el update por post?

quizás hay algo a nivel conceptual que se me escapa y estoy diciendo una burrada tamaño casa...

quimfv · #9 (**permalink**) 23/11/2011, 03:21

El problema como te dice gnzsoloyo es de diseño.... apesar de ello no veo porque se tiene que colgar, una cosa es que vaya lento y otra que haga saltar el servicio....

no nos has mostrado un update tipico de los que te producen el error....

Si el update termina con un "WHERE IDPropiedad=X" donde X es el registro a modificar estaria actuando el indice de la PK y no veo porque no te lo tiene que hacer con una cierta velocidad... otro tema serian updates masivos, pero por lo que dices no es el caso.

La solución de las dos tablas a parte de que mientras un usuario modifica un registro otro puede estarlo consultando con datos obsoletos, esta en el ultimo paso que propones para "volcar internamente" la fila deberias hacerlo o con un update con lo que seguiriamos con el problema o con un delete y un insert (es decir borrar he insertar el nuevo registro actualizado, con lo que cambiaria de indentificador ...) no se si con esto vas a ganar nada... Olvidate de ella, de hecho cuando un usuario quiere hacer una modificación lo que hace primero es consultar el registro, traer los datos a la pantalla, hacer las modificaciones, en la panatalla, y finalmente volcarlas a la tabla con lo que es prácticamente lo mismo....

Si haciendo el update "internamente" te lo hace bien luego es evidente que el problema lo tienes en otro lado, es decir en el proceso que lanza el update "externamente"... En este caso no solo tendrias problemas de diseño en la bbdd si no tambien en la aplicacion que te la gestiona...

Muestranos una sentencia de update que te este provocando el error a ver si vemos algo...

UPDATE ... ;

Nota: por cierto sea bien venido gnzsoloyo a cualquier hilo en el que yo haya intervenido.

el_apronte · #10 (**permalink**) 23/11/2011, 07:38

Gracias quimfv
no sé porque se cuelga... :( para mi es un misterio, la he ido migrando a servidores superiores en dos oportunidades hasta acabar en uno dedicado, y en todos me ha pasado lo mismo...
y no solo lo hace con la sentencia que pego a continuación, sino también me ha pasado alguna vez que he modificado una entrada desde phpmyadmin... por lo que evidentemente tendré que dividir la tabla y cambiar todos y cada uno de los archivos.... (de pensarlo me dan ganas de llorar)
cuando se cuelga, tras esperar varios minutos que vuelva (en algunos casos más de 10') termino reiniciando el servicio porque no hay caso, te digo más, en oportunidades me cuelga el servicio para las otras webs que tengo en el mismo servidor dedicado...

Aguna vez copie toda una tabla a otra con una sentencia del tipo:
INSERT INTO `nueva_tabla`( SELECT Columna_1, Columna_2, Columna_3 FROM `tabla_vieja` )
y la operación ha sido rápido y exitosa con una tabla de 18Mb, a esto me refería con volcar "internamente"

Aqui dejo la sentencia de mi update:

UPDATE propiedades set IDPropiedad = '$IDPropiedad', Activo = '$Activo', Fecha1 = '$Fecha1', Fecha2 = '$Fecha2', Fecha3 = '$Fecha3', IDDestino = '$IDDestino', IDTipoInmueble = '$IDTipoInmueble', Ambientes = '$Ambientes', Dormitorios = '$Dormitorios', IDZona = '$IDZona', IDCiudad = '$IDCiudad', Moneda = '$Moneda', Precio = '$Precio', Dueno = '$Dueno', IDAnunciante = '$IDAnunciante', telefono = '$telefono', Ubicacion = '$Ubicacion', NumeroCalle = '$NumeroCalle', Piso = '$Piso', Puerta = '$Puerta', Superficie = '$Superficie', AptoProf = '$AptoProf', Dependencia = '$Dependencia', Cochera = '$Cochera', ymedio = '$ymedio', MasCuotas = '$MasCuotas', Lavadero = '$Lavadero', Baulera = '$Baulera', Antiguedad = '$Antiguedad', PorEscalera = '$PorEscalera', Orientacion = '$Orientacion', Disposicion = '$Disposicion', Plantas = '$Plantas', Salones = '$Salones', Banos = '$Banos', Aseos = '$Aseos', Terrazas = '$Terrazas', Balcones = '$Balcones', Patio = '$Patio', Jardines = '$Jardines', Expensas = '$Expensas', Superficie_Ext = '$Superficie_Ext', Amueblado = '$Amueblado', AireA = '$AireA', Piscina = '$Piscina', Ascensor = '$Ascensor', Reservado = '$Reservado', Parrilla = '$Parrilla', Estado = '$Estado', horade1 = '$horade1', horahasta1 = '$horahasta1', horade2 = '$horade2', horahasta2 = '$horahasta2', horade3 = '$horade3', horahasta3 = '$horahasta3', Alarma = '$Alarma', AptoHipoteca = '$AptoHipoteca', Sum = '$Sum', EspacioAereo = '$EspacioAereo', FechaAlta = '$FechaAlta', DescripcionDetallada = '$DescripcionDetallada', PalierPriv = '$PalierPriv', Vestidor = '$Vestidor', Escritorio = '$Escritorio', Toilette = '$Toilette', DobEntrada = '$DobEntrada', Urgente = '$Urgente', Laundry = '$Laundry', Solarium = '$Solarium', Vistas = '$Vistas', Sauna = '$Sauna', Suite = '$Suite', Recepcion = '$Recepcion', SalFiestas = '$SalFiestas', Gym = '$Gym', PlayRoom = '$PlayRoom', LosaRad = '$LosaRad', Parquet = '$Parquet', Jacuzzi = '$Jacuzzi', Hidromasaje = '$Hidromasaje', Quincho = '$Quincho', Categoria = '$Categoria', Seguridad = '$Seguridad', Amenities = '$Amenities', aviso_original = '$aviso_original', modificado_anunciante = '$modificado_anunciante', Destacado = '$Destacado' WHERE IDPropiedad = $IDPropiedad LIMIT 1;

otra duda que tengo es que las variables que vienen "vacias" no las estoy convirtiendo en null, imagino que eso no esta demasiado bien, pero no creo que tenga que ver... sino no se colgaría con phpmyadmin, verdad?

gnzsoloyo · #11 (**permalink**) 23/11/2011, 07:47

Cita:

UPDATE propiedades set IDPropiedad = '$IDPropiedad', Activo = '$Activo', Fecha1 = '$Fecha1', Fecha2 = '$Fecha2', Fecha3 = '$Fecha3', IDDestino = '$IDDestino', IDTipoInmueble = '$IDTipoInmueble', Ambientes = '$Ambientes', Dormitorios = '$Dormitorios', IDZona = '$IDZona', IDCiudad = '$IDCiudad', Moneda = '$Moneda', Precio = '$Precio', Dueno = '$Dueno', IDAnunciante = '$IDAnunciante', telefono = '$telefono', Ubicacion = '$Ubicacion', NumeroCalle = '$NumeroCalle', Piso = '$Piso', Puerta = '$Puerta', Superficie = '$Superficie', AptoProf = '$AptoProf', Dependencia = '$Dependencia', Cochera = '$Cochera', ymedio = '$ymedio', MasCuotas = '$MasCuotas', Lavadero = '$Lavadero', Baulera = '$Baulera', Antiguedad = '$Antiguedad', PorEscalera = '$PorEscalera', Orientacion = '$Orientacion', Disposicion = '$Disposicion', Plantas = '$Plantas', Salones = '$Salones', Banos = '$Banos', Aseos = '$Aseos', Terrazas = '$Terrazas', Balcones = '$Balcones', Patio = '$Patio', Jardines = '$Jardines', Expensas = '$Expensas', Superficie_Ext = '$Superficie_Ext', Amueblado = '$Amueblado', AireA = '$AireA', Piscina = '$Piscina', Ascensor = '$Ascensor', Reservado = '$Reservado', Parrilla = '$Parrilla', Estado = '$Estado', horade1 = '$horade1', horahasta1 = '$horahasta1', horade2 = '$horade2', horahasta2 = '$horahasta2', horade3 = '$horade3', horahasta3 = '$horahasta3', Alarma = '$Alarma', AptoHipoteca = '$AptoHipoteca', Sum = '$Sum', EspacioAereo = '$EspacioAereo', FechaAlta = '$FechaAlta', DescripcionDetallada = '$DescripcionDetallada', PalierPriv = '$PalierPriv', Vestidor = '$Vestidor', Escritorio = '$Escritorio', Toilette = '$Toilette', DobEntrada = '$DobEntrada', Urgente = '$Urgente', Laundry = '$Laundry', Solarium = '$Solarium', Vistas = '$Vistas', Sauna = '$Sauna', Suite = '$Suite', Recepcion = '$Recepcion', SalFiestas = '$SalFiestas', Gym = '$Gym', PlayRoom = '$PlayRoom', LosaRad = '$LosaRad', Parquet = '$Parquet', Jacuzzi = '$Jacuzzi', Hidromasaje = '$Hidromasaje', Quincho = '$Quincho', Categoria = '$Categoria', Seguridad = '$Seguridad', Amenities = '$Amenities', aviso_original = '$aviso_original', modificado_anunciante = '$modificado_anunciante', Destacado = '$Destacado' WHERE IDPropiedad = $IDPropiedad LIMIT 1;

Datos, no variables. Un ejemplo de datos entrantes.
Captura esa consulta antes de que sea enviada, una vez que ya se ha creado la cadena de texto y postea eso.

Las variables no nos dicen nada. Son inaccesibles para el MySQL y no sabemos qué es lo que contienen. Es el comportamiento de los datos lo que nos interesa.

el_apronte · #12 (**permalink**) 23/11/2011, 08:10

ok, mil gracias, haré que una vez tenga la cadena, me la envíe por mail antes de actualizar nada.
No se me ocurre otra manera de capturarla. en mi versión local de phpmyadmin hay una solapa "traking" que al parecer registra los cambios, pero en el servidor no la tengo... no sé si hay algún otro método...
reporto en cuanto tenga novedades
gracias de nuevo!

quimfv · #13 (**permalink**) 23/11/2011, 08:10

Lo que te ha dicho gnzsoloyo... así veremos real mente lo que le llega al servidor....

puedes hacer

echo "la sentencia con variables" ;

an tes de lanzarla al servidor y mostrará la sentencia con los valores luego copias y pegas...

Aqui

....WHERE IDPropiedad = $IDPropiedad LIMIT 1;

te sobra ese LIMIT 1....

el_apronte · #14 (**permalink**) 23/11/2011, 08:42

Cita:

Iniciado por quimfv

....WHERE IDPropiedad = $IDPropiedad LIMIT 1;

te sobra ese LIMIT 1....

Lo sé, es un índice primario y no hay mas que uno con ese número...
llevo un mareo con esto que a ratos dudo de como me llamo....
poner set IDPropiedad = 'x', entiendo que tampoco hace falta

dejo un update de los tres que hice, pero ahora no se está colgando
como cuando llevas el coche al taller! ahora va como un violín!

UPDATE propiedades set IDPropiedad = '57679', Activo = '1', Fecha1 = '2011-11-20', Fecha2 = '0000-00-00', Fecha3 = '0000-00-00', IDDestino = '4', IDTipoInmueble = '1', Ambientes = '2', Dormitorios = '', IDZona = '1', IDCiudad = '21', Moneda = 'USD', Precio = '118000', Dueno = '', IDAnunciante = '370', telefono = '', Ubicacion = 'Guemes', NumeroCalle = '4100', Piso = '0', Puerta = 'B', Superficie = '40', AptoProf = '1', Dependencia = '', Cochera = '', ymedio = '', MasCuotas = '', Lavadero = '1', Baulera = '', Antiguedad = '', PorEscalera = '', Orientacion = '', Disposicion = 'Interno', Plantas = '', Salones = '', Banos = '', Aseos = '', Terrazas = '', Balcones = '', Patio = '1', Jardines = '', Expensas = '380', Superficie_Ext = '3', Amueblado = '', AireA = '', Piscina = '', Ascensor = '', Reservado = '', Parrilla = '', Estado = 'A NUEVO', horade1 = '15', horahasta1 = '18', horade2 = '15', horahasta2 = '18', horade3 = '15', horahasta3 = '18', Alarma = '', AptoHipoteca = '', Sum = '', EspacioAereo = '', FechaAlta = '23/11/2011', DescripcionDetallada = '', PalierPriv = '', Vestidor = '', Escritorio = '', Toilette = '', DobEntrada = '', Urgente = '', Laundry = '', Solarium = '', Vistas = '', Sauna = '', Suite = '', Recepcion = '', SalFiestas = '', Gym = '', PlayRoom = '', LosaRad = '', Parquet = '', Jacuzzi = '', Hidromasaje = '', Quincho = '', Categoria = '', Seguridad = '', Amenities = '', aviso_original = '', modificado_anunciante = '', Destacado = '1' WHERE IDPropiedad = 57679

acabo de ver que aquí hay un problema con la fecha de alta, a ver si va a ser eso....

quimfv · #15 (**permalink**) 24/11/2011, 02:47

Cita:

UPDATE propiedades set
IDPropiedad = '57679',
Activo = '1',
Fecha1 = '2011-11-20',
Fecha2 = '0000-00-00',
Fecha3 = '0000-00-00',
IDDestino = '4',
IDTipoInmueble = '1',
Ambientes = '2',
Dormitorios = '',
IDZona = '1',
IDCiudad = '21',
Moneda = 'USD',
Precio = '118000',
Dueno = '',
IDAnunciante = '370',
telefono = '',
Ubicacion = 'Guemes',
NumeroCalle = '4100',
Piso = '0',
Puerta = 'B',
Superficie = '40',
AptoProf = '1',
Dependencia = '',
Cochera = '',
ymedio = '',
MasCuotas = '',
Lavadero = '1',
Baulera = '',
Antiguedad = '',
PorEscalera = '',
Orientacion = '',
Disposicion = 'Interno',
Plantas = '',
Salones = '',
Banos = '',
Aseos = '',
Terrazas = '',
Balcones = '',
Patio = '1',
Jardines = '',
Expensas = '380',
Superficie_Ext = '3',
Amueblado = '',
AireA = '',
Piscina = '',
Ascensor = '',
Reservado = '',
Parrilla = '',
Estado = 'A NUEVO',
horade1 = '15',
horahasta1 = '18',
horade2 = '15',
horahasta2 = '18',
horade3 = '15',
horahasta3 = '18',
Alarma = '',
AptoHipoteca = '',
Sum = '',
EspacioAereo = '',
FechaAlta = '23/11/2011',
DescripcionDetallada = '',
PalierPriv = '',
Vestidor = '',
Escritorio = '',
Toilette = '',
DobEntrada = '',
Urgente = '',
Laundry = '',
Solarium = '',
Vistas = '',
Sauna = '',
Suite = '',
Recepcion = '',
SalFiestas = '',
Gym = '',
PlayRoom = '',
LosaRad = '',
Parquet = '',
Jacuzzi = '',
Hidromasaje = '',
Quincho = '',
Categoria = '',
Seguridad = '',
Amenities = '',
aviso_original = '',
modificado_anunciante = '',
Destacado = '1'
WHERE IDPropiedad = 57679

Primero como dices el update sobre la PK sobra, esto podria ser lo que te esta dando problemas puesto que una modificacion sobre la PK aun que en realidad no estas cambiando nada puede que fuerce la reconstrucción del indice asociado a la PK. Si se fuerza esa reconstrucció tambien pasaria con el indice sobre Activo...

Efectivamente esa fecha no llega con el formato adecuado.

Estas poniendo el delimitador ' ' a todos los campos con independencia del formato, no hace falta ni en los numericos ni en los booleanos (si en fechas y strings) pero esto es mas de estilo cuando tiene valor mysql lo considera con el tipo adequado. Lo que ya no es de estilo es que estas pasando booleanos a '' cadena vacia eso deberia dar error un booleano es 1=true 0=false o null pero no '' cadena vacia (no se si MySql tambien lo passa a null ... el manual dice que todo valor distinto de cero es considerado TRUE pero en los ejemplos solo habla de valores numericos, no se que hace con un string).

Por otro lado estas modificando todos los campos, mi pregunta es efectivamente se modifican todos siempre?

Si es que si nada, si no un script te podria construir un update dinamico que solo modifique los campos que realmente se hayan modificado...

Si solo se ha cambiado el telefono por decir algo deberias mandar el siguiente update supongamos que hemos quitado el telefono

UPDATE propiedades set telefono = '' WHERE IDPropiedad = 57679

por cierto de que te sirve declarar

`telefono` varchar(20) NOT NULL default '',

el telefono no puede ser null pero por defecto es cadena vacia, no parece logico....

Tienes claro que quando haces SET uncampo='' estas conviertiendo el contenido del campo a '' cadena vacia (cadena vacia <> null) y por tanto si habia algo en el campo habra desaparecido....

el_apronte · #16 (**permalink**) 24/11/2011, 09:47

Gracias quimfv!
te cuento, el update sobre la clave primaria IDPropiedad ya lo quité junto con el limit y corregí el formato de la fecha, de momento viene funcionando todo de maravilla!
Tambíen liberé espacio de la tabla, baje de 18000 entradas a 10000 y parece que va mejor... puede que por un tiempo no me traiga problemas (eso espero)
igual estoy capturando como me sugeristeis via mail todos los updates que se hacen, así que cuando se cuelgue, probablemente no esté tan a ciegas como venía...

Cita:

Iniciado por quimfv

Lo que ya no es de estilo es que estas pasando booleanos a '' cadena vacia eso deberia dar error un booleano es 1=true 0=false o null pero no '' cadena vacia (no se si MySql tambien lo passa a null ... el manual dice que todo valor distinto de cero es considerado TRUE pero en los ejemplos solo habla de valores numericos, no se que hace con un string).

Cuando envío el campo vacío lo pasa a 0 y sobreescribe el 1 que existía, con esto no "parece" haber problema al igual que los delimitadores, sé lo que me comentas, pero como no da error me resultó mas rápido construirlo de esa manera.

Cita:

Iniciado por quimfv

Por otro lado estas modificando todos los campos, mi pregunta es efectivamente se modifican todos siempre?
Si es que si nada, si no un script te podria construir un update dinamico que solo modifique los campos que realmente se hayan modificado...

No, cambian solo algunas cosas. Había pensado hacer un update dinámico como el que me comentas para reemplazar solo los valores que han cambiado, pero había observado en alguna versión de phpmyadmin (que lo acabo de mirar y por lo visto no es en las versiones que tengo ahora, o solo lo hace en algunos casos, o yo he visto cualquier cosa en su momento! ...no sería raro... ) construye una sintaxis super compleja, por ejemplo:
UPDATE 'tabla' set el_campo_que_cambia = 'valor'
WHERE
campo_1 = 'valor_campo_1' AND
campo_2 = 'valor_campo_2' AND
campo_3 = 'valor_campo_3'
(etc... toooodos los campos de la tabla)
LIMIT 1
de ahí había sacado lo del limit 1

Ahora lo he mirado de nuevo y no, lo hace como bien dices:
UPDATE propiedades set telefono = '' WHERE IDPropiedad = 57679 (en versión phpMyAdmin - 3.3.9)
y en phpMyAdmin - 2.11.11.3 mete el "limit 1"

Por tanto me preocupaba mandar una sintaxis tan escueta cuando phpMyAdmin era tan explícita... pero mi percepción me indica que sería más rápido y mejor hacerlo como me dices. Es el paso siguiente que haré antes de dividir las tablas si vuelven los problemas.

Cita:

Iniciado por quimfv

por cierto de que te sirve declarar
`telefono` varchar(20) NOT NULL default '',

es verdad! debo corregirlo y por defecto debe ser NO que es lo que necesito según como tengo programados los scripts

También había leído (que imagino que es una chapuza de mucho cuidado) que alguien sugería dividir el update o mejor dicho dividir la cadena e ir haciendo updates cada x cantidad de campos...
llegado el caso lo probaré y luego os digo... cualquier cosa antes de dividir la tabla y tener que cambiar toooodos los archivos del sitio!

quimfv mil gracias por tu tiempo! con estos cambios espero que se estabilice!
Saludos y gracias otra vez!

gnzsoloyo · #17 (**permalink**) 24/11/2011, 19:29

Tip: Si los campos son opcionales, es decir, pueden o no llevar algún valor válido, es mejor declararlos NULL y no como NOT NULL.
NOT NULL es una restricción que exige al MySQL verificar cada vez que se hace una inserción o actualización (UPDATE) que esa columna tenga un valor. Esto, al procesar una tabla de las dimensiones de la tuya, y con tantos registros, eventualmente afecta la performance.
Coloca como NOT NULL sólo aquellos campos que deban contener obligatoriamente algún valor.

quimfv · #18 (**permalink**) 25/11/2011, 05:29

Es lo mismo tener un telefono igual NO que tenerlo nulo y como te dice gnzsoloyo eliminar NOT NULL le quita trabajo al servidor de bbdd que es de lo que se trata....

Me alegro que te haya servido.

el_apronte · #19 (**permalink**) 25/11/2011, 06:55

ok, hago los cambios quie me dicen y reporto de haber novedades
de momento no se ha colgado mas!
veremos entre el sábado y el lunes (que son los días de mas visitas) a ver que pasa
Gracias, saludos!