Discussion :

[RunCodePhp]

Salut

Je vous fais part d'un phénomène qui me parais plutôt étrange sur une banale petite requête où le ORDER BY serait entre autre l'acteur principal.

La requête à l'origine : (c'est un système de ticket interne)

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
SELECT COUNT(*) AS total
FROM ticket t
JOIN ticket_history th ON t.ticket_id = th.ticket_id
JOIN ticket_status ts ON t.status_id = ts.status_id
WHERE t.users_id = 100
AND th.publier = 1
AND t.status_id = 1
GROUP BY t.ticket_id
ORDER BY t.date_created DESC
LIMIT 1

Cette requête retourne 2 pour "total", MySQL trouve donc 2 lignes.
Or, je sais qu'il y en a 3.
-> 1 ligne ticket_id pour le user_id 100 dans la table ticket
-> 3 lignes ticket_id dans la table ticket_history (3 réponses).


Je supprime dans la requête le ORDER BY (ORDER BY t.date_created DESC), et hop, cette fois MySQL trouve bien les 3 lignes.
Depuis quand un ORDER BY agirait sur le nombre de ligne à retourner ?


Personnellement je le trouve un peu fort l'café, même ici le ORDER BY n'était pas utile.


Selon vous, c'est normal ou pas ?
Une explication serait le bienvenu.

[Fladnag]

Bonjour,

moi ce qui me perturbe c'est le LIMIT 1 a la fin.
Si tu lui dit que tu veux un seul resultat, pourquoi il t'en retourne 2 (ou 3) ?

peut etre que mysql tri la table en interne pour réaliser le group by et que ton order by "perturbe" ce tri.

Essaye un order by par la meme colonne que la colonne de group by pour voir ?

[RunCodePhp]

moi ce qui me perturbe c'est le LIMIT 1 a la fin.
Si tu lui dit que tu veux un seul resultat, pourquoi il t'en retourne 2 (ou 3) ?

Je ne souhaite pas que ça retourne les lignes, je veux juste connaitre le nombre de lignes de ticket_history, le nombre de réponses en faite.
D'où le COUNT(*), et d'où le LIMIT 1.

Mais effectivement, j'avais déjà fait cet essai de supprimer le LIMIT 1, ça n'a rien changé au résultat du total, du COUNT(*).

Essaye un order by par la meme colonne que la colonne de group by pour voir ?

C'est exactement ça qui perturbe la requête.
En faite, faut pas que ça soit la même colonne que le Group by, du moins apparemment.

Si je met un tri sur la table ticket_history, ça compte bien 3 (c'est bon).
Mais dès que c'est un champ de la table ticket, ça compte 2.


C'est terrible ça.
Alors là, c'est la 1ère fois que je remarque ça.

Mais franchement, c'est normal ou pas ?
Bug ou pas bug ?

[Fladnag]

ok pour le limit, en effet ^^ mais il ne sert a rien lui non plus je pense.

normal ? A priori je dirais non
bug ? a priori je dirais oui

Mais bon, les parseurs de SGBD sont super compliqués donc l'explication est peut etre a trouver dans le cas d'une requete super compliquée pour laquelle on a besoin de ce truc.

Essaye de faire un POC (Proof Of Concept) avec des tables, des champs et des données simples et remonte le a Mysql ;o)

Sinon il n'y a pas de champs NULL dans tes tables ?

[RunCodePhp]

Sinon il n'y a pas de champs NULL dans tes tables ?

Il se trouve que non, tout est obligatoire, de plus que du classique coté type de données, et visuellement ça à l'air correcte.

Mais ce qui devient de plus en plus étrange, voir même plus inquiétant, c'est que je ne parviens pas à reproduire l'erreur.
Vite fait comme ça, j'ai créer une autre Bdd, tables ... et fait quelques essais des plus basiques avec les fonctions mysql_*.
Et là, avec ou sans ORDER BY, ou de LIMIT, tout est cohérent.

Vu que dans le projet en question j'utilise PDO, abstraction et tunti quanti ... qui commence à devenir un peu usine à gaz, peut être que ...


Donc je veux bien faire un PROC (jamais fais ça d'ailleurs).
Mais je me dis qu'avant d'ameuter tout l'quartier, j'aimerais bien reproduire cette erreur dans un autre contexte (en gros).

Une affaire à suivre, mais il doit avoir une explication, en espérant que c'est pas l'arbre qui cache la foret.

[Fladnag]

Si tu n'arrives pas a reproduire le problème en repartant de zero, il faut faire l'inverse : partir du problème et simplifier tout au maximum petit a petit, en vérifiant a chaque suppression que le problème est toujours là.

Commence a faire une copie de ta base et de ton code pour ne pas casser tout ce que tu as fait, puis :
* Fait une page avec uniquement la requete qui pose probleme
* Supprime toutes les tables, champs et autres qui ne sont pas dans la requete
* Supprime tout ce qui est inutile dans le code PHP en gardant la meme architecture (POO)
* Supprime la couche d'abstraction PDO (c'est peut etre un bug de la couche aussi, va savoir ^^)
* etc...

Evidemment, ca prend du temps et ce n'est peut être pas ta priorité, mais si tu veux fouiller pour comprendre pourquoi, y a que ca a faire je crois ^^