Mysql, consulta registro sin integridad referencial

[Rodrigo Fuentealba]

El día 1 de octubre de 2008 20:41, Juan Manuel Doren <jm.doren en ok.cl> escribió:
>> El día 1 de octubre de 2008 19:51, Lorenzo Ponce <lekronne en yahoo.com> escribió:
>>>
>>>>http://dev.mysql.com/doc/refman/5.0/en/rewriting-subqueries.html
>>>
>>>>Haz un query rewrite como el que sigue:
>>>
>>>>SELECT tabla1.*
>>>> FROM tabla1 LEFT JOIN tabla2 ON tabla1.id=tabla2.id
>>>> WHERE tabla2.id IS NULL;
>>>
>>>>Con eso deberías tener un improvement.
>>>
>>> De todas formas es lento, no sé si existe una forma de hacer lo que
>>> necesito con consultas sql dado lo que ya está hecho por un tercero.
>>
>> A eso me refería con que el optimizador de consultas en MySQL era malo. See?
>
> ¿como sabes que es el optimizador el que pone la consulta lenta? sin
> son mogollones de filas en las tablas se va a demorar cualquier cosa,
> la M de mySQL no es por Magic

Ya me he encontrado con aquello. Internamente existe un "algo"
(llamémosle procedimiento) que traduce el SQL a un lenguaje más
relacionado con el motor de bases de datos. Éste permite sacar los
datos precisos de la base descartando los datos que no concuerdan. En
MySQL por alguna razón que desconozco, y que en realidad nunca he
querido conocer, estas operaciones se dan la vuelta del perro y
terminan siendo poco eficientes con una cantidad de datos razonable.

En una consulta anterior, que debe estar en los anales de la lista,
debía hacer un LEFT JOIN pero con tres tablas, cada una de unos 60000
datos. MySQL se caía (segmentation fault) después de 40 minutos sin
ton ni son (todo al día esa vez, y probando con distintas versiones
era lo mismo). Y aumentando la memoria disponible para operar,
conseguí que se cayera a los 50, no a los 40 minutos. Esa misma
consulta en PostgreSQL demoró poquísimo (en el orden de segundos, si
mal no recuerdo).

> obviamente en esa consulta deben existir indices por los ids, si no
> los hay, en vez de repetir BD1, yo lo mandaria a repetir desde octavo
> basico.....

No sólo de índices primarios/únicos viven los developers. Para
consultas complejas puedes crear un index especial en ese caso que
involucre no sólo tu ID, sino otros campos más.

Hay estrategias para crear índices eficientes, que varían de base de
datos en base de datos. Por ejemplo, en SQL Server 7.0 debes crear un
índice que contenga cada uno de los campos de tu tabla más grande en
una cláusula WHERE, y tanto en SQL Server 2005 como en Oracle bastaría
con crear un índice para cada campo que ingresas manualmente (es
decir, no considerar las referencias del tipo WHERE tabla1.campo1 =
tabla2.campo2, sólo las referencias a tabla1.campo1 = "?"). Aunque no
sabría decirte cuál es cuál en PostgreSQL (existe más de un tipo de
índices, yo hago ensayo y error), y a MySQL ni lo he mirado en ese
aspecto.

Saludos,

-- 
Rodrigo Fuentealba