El día 25 de noviembre de 2009 09:35, OSiUX <[email protected]> escribió: > Jose C. Masson escribió: >> >> German escribió: >>> >>> Sergio Gómez escribió: >>>> >>>> Jose C. Masson escribió: >>>>> >>>>> Hola a todos, >>>>> >>>>> A ver si a alguien alguna vez le pasó esto con MySQL. >>>>> >>>>> Situación: >>>>> >>>>> La aplicación con la que estoy laburando (SugarCRM) en una parte de >>>>> su interfaz y para >>>>> mostrar ciertos datos genera automagicamente una consulta, en la cual >>>>> hace uso de "LEFT >>>>> JOIN" entre dos tablas (leads, y leads_cstm) de no más de 9000 >>>>> registros cada una. >>>>> Esta consulta, por algún extraño motivo al MySQL le cuesta un huevo y >>>>> la mitad del otro >>>>> (450 segundos). >>>>> >>>>> Si ejecuto esta misma consulta directamente sobre la consola de MySQL >>>>> o desde PHPMyadmin, >>>>> tarda lo mismo... pero si la modifico levemente, y en cambio de usar >>>>> LEFT JOIN uso INNER >>>>> JOIN, tarda menos de un segundo en ejecutarse. >>>>> >>>>> Vale aclarar que en este caso en particular es al pedo usar LEFT JOIN >>>>> porque la relación >>>>> entre las tablas es 1 a 1... con lo cual no habría registros de >>>>> "leads" que no tengan su >>>>> contraparte en "leads_cstm", así que podría usar INNER JOIN sin >>>>> dramas... pero para esto >>>>> tendría que ponerme a meterle mano al core de la aplicación, y es >>>>> algo que preferiría evitar. >>>>> >>>>> Estuve buscando por la red y no logré encontrar el por qué de esta >>>>> diferencia entre LEFT >>>>> JOIN e INNER JOIN.... alguien conoce si existe alguna forma de tunear >>>>> MySQL para que LEFT >>>>> JOIN no tarde tanto o mi destino está escrito y tendré que meterle >>>>> mano a la aplicación >>>>> para cambiar la forma en la cual hace la consulta?? >>>>> >>>>> Abrazos >>>>> >>>> >>>> No podes pegar el sql aquí? >>>> Normalmente no hay esa diferencia que mencionas entre los distintos >>>> tipos de joins >>>> Habría que ver la consulta. >>>> >>> Hola >>> No sera posible que tengas dañana alguna de las tablas, o bien algun >>> indice? probaste un check table? >> >> Hice CHECK table ... y todas están bien.... :( >> >> todos los campos de relación de los LEFT JOIN están indexados. > > Estos son los índices de la tabla leads: > > KEY `idx_lead_acct_name_first` (`account_name`,`deleted`), > KEY `idx_lead_last_first` (`last_name`,`first_name`,`deleted`), > KEY `idx_lead_del_stat` (`last_name`,`status`,`deleted`,`first_name`), > KEY `idx_lead_opp_del` (`opportunity_id`,`deleted`), > KEY `idx_leads_acct_del` (`account_id`,`deleted`), > KEY `idx_del_user` (`deleted`,`assigned_user_id`), > KEY `idx_lead_assigned` (`assigned_user_id`), > KEY `idx_lead_contact` (`contact_id`), > > El problema es que no hay un índice correcto para esta consulta, si haces un > EXPLAIN del SELECT te dice que va a usar idx_del_user. > > Se puede agregar uno que si sirva: > > ALTER TABLE leads ADD INDEX idx_first_last_del > (first_name,last_name,deleted); >
eso crea un indice compuesto, no veo que se utilicen esos campos en la constula :S > Y además forzar que use ese índice si hiciera falta. > > SELECT * FROM leads USE INDEX (idx_first_last_del) WHERE deleted = 0 ORDER > BY first_name, last_name ASC LIMIT 0,51; > Crees que se indices? mmmh IMHO no es eso, debido a que con inner le tarda menos, podría pasar por otra cosa. Jose, el EXPLAIN nos dará la luz ;) -- Emanuel Calvo Franco http://www.emanuelcalvofranco.com.ar -- Para desuscribirte tenés que visitar la página https://listas.linux.org.ar/mailman/listinfo/lugar-gral/ Usuarios Software Libre Argentina (USLA)
