Mouais pas d'accord avec ça, la principale différence ici c'est très probablement une migration vers MySQL 5.1, qui change le comportement de MySQL lors d'une comparaison DATE vs DATETIME.
Avant la 5.1, dans le cas d'une comparaison DATE vs DATETIME MySQL castait le tout en DATE avant d'effectuer le test ; maintenant il caste en DATETIME.
En gros :
avant la 5.1 : '2012-04-20' = '2012-04-20 18:42:00'
après la 5.1 : '2012-04-20' = '2012-04-20 00:00:00' < '2012-04-20 18:42:00'
Une solution est le between, mais il suffit de faire un EXPLAIN pour voir que MySQL utilise parfaitement l'index dans tous les cas.
Par contre ce qu'on peut retrouver dans le bouquin en question ce sont des choses comme ça :
1) WHERE monChamp + 1 interval 1 month
2) WHERE monchamp
La première construction ne saura pas tirer parti d'un éventuel indexe, au contraire de la seconde.
[^] # Re: Le bug c'est la requete
Posté par Kioob (site web personnel) . En réponse au journal Aujourd'hui, petit bug d'un serveur MySql d'OVH. Évalué à 4. Dernière modification le 20 avril 2012 à 22:49.
Mouais pas d'accord avec ça, la principale différence ici c'est très probablement une migration vers MySQL 5.1, qui change le comportement de MySQL lors d'une comparaison DATE vs DATETIME.
Avant la 5.1, dans le cas d'une comparaison DATE vs DATETIME MySQL castait le tout en DATE avant d'effectuer le test ; maintenant il caste en DATETIME.
En gros :
avant la 5.1 : '2012-04-20' = '2012-04-20 18:42:00'
après la 5.1 : '2012-04-20' = '2012-04-20 00:00:00' < '2012-04-20 18:42:00'
Une solution est le between, mais il suffit de faire un EXPLAIN pour voir que MySQL utilise parfaitement l'index dans tous les cas.
Par contre ce qu'on peut retrouver dans le bouquin en question ce sont des choses comme ça :
1) WHERE monChamp + 1 interval 1 month 2) WHERE monchamp
La première construction ne saura pas tirer parti d'un éventuel indexe, au contraire de la seconde.
alf.life