Discussion :

[Unkof]

Bonjour à tous,

J'ai un problème, à priori d'index ?... dans une table.

J'explique:

J'ai une table avec 63 rows, avec plusieurs champs, dont 4 indexés :

Id (Mediumint)
A (INT)
B (INT)
C (INT)

Lorsque je fais un

Code :

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

1
2
3
SELECT Id 
FROM table 
ORDER BY Id

La liste s'affiche dans l'ordre des Id, bien entendu, sans aucun problème.

Pareil pour les autres champs en faisant un ORDER BY A, ou C, mais j'ai une erreur quand je fais par B !?....

Lorsque je visualise le résultat je me retrouve avec un enregistrement doublé, en clair, j'ai toujours 63 rows, mais j'en ai un en double (Le même Id Apparait 2 fois!?)

J'ai fait le test sous PhpMyadmin, idem, malgré le fait que la table ne contient bien entendu pas 2 fois le même ID. Cette erreur apparait des fois sur d'autres Id, suivant le ORDER BY que j'utilise.

J'ai ce problème suite à un plantage de Mysql à cause d'un manque d'espace disque de /

J'ai essayé de réparer avec Phpmyadmin la table, il me dit que c'est Ok, j'optimise, il me dit que c'est ok, je fais un myisamchk (il m'a dit que la table devait être fixée), j'ai donc fait un myisamchk -r table, il a fixé les index, mais lorsque je redemande un ORDER BY, j'ai toujours la même erreur !?...

Help ! ... chuis à cours d'idées ... :s

[Macfurp]

Bonjour,

S'agit-il d'un index composé des 4 champs Id, a, b, c ou de 4 index distincts ?
Quel est le critère d'unicité sur la table ?

Sinon pour avoir le coeur net sur le contenu de la table, tu pourrais passer un :

Code :

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

SELECT Id, B FROM table ORDER BY B ;

[Unkof]

Pour répondre à tes questions, ce sont 4 index séparés, le champ Id est en auto-incrément.

Alors, après plein de tests, il semblerait que ce soit un probleme de requete ?...

Lorsque je fais :

SELECT Id FROM table ORDER BY B DESC

Je n'ai pas le même ordre d'affichage que lorsque je fais

SELECT Id FROM table ORDER BY B DESC LIMIT 0,30

Bien entendu, sur les 30 premiers. Le classement change d'une requete à l'autre lorsque B==0, sachant que le champ B est de type INT not null.

En gros:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Requete1         Requete2
Id - B           Id - B
6 - 1000         6 - 1000 
7 - 990          7 - 990
2 - 500          2 - 500
1 - 300          1 - 300
9 - 0            8 - 0
8 - 0            5 - 0
...              ...

Comment faire pour avoir exactement le même ordre d'affichage dans les 2 cas ?

Je ne sais pas si je suis très clair là dans mon explication .... lol.

[Unkof]

C'est bon, j'ai trouvé un moyen simple d'avoir toujours le même classement.

Je donne l'info pour ceux qui éventuellement seraient confrontés au même problème, il suffit d'utiliser en parallèle de la requête de tri un index d'unicité.

Merci Macfurp pour m'avoir mis sur la piste ..

Changer les requetes précédentes par:

SELECT Id,B FROM table ORDER BY B DESC,Id ASC

Et

SELECT Id,B FROM table ORDER BY B DESC,Id ASC LIMIT 0,30

Dans ce cas, y a toujours le même ordre.

Ca veut dire qu'en fait, suivant si il y a le LIMIT dans la requete ou pas, le parcours de la table ne se fait pas dans le même sens ??...

Quelqu'un pourrait m'éclairer sur ca, histoire que je me couche moins bête ce soir ?..

[Macfurp]

Bonjour,

je crois qu'il y a parfois un problème sur les tris effectués sur une colonne non sélectionnée dans la requète ce qui peut amener des incohérences de résultat.

Pour le problème sur l'ordre des données ramenées avec ou sans le LIMIT je pense qu'il faudrait comparer les chemins d'accès pour regarder dans chacun des cas l'index qui est utilisé et voir s'il y a une différence.

[Unkof]

je pense qu'il faudrait comparer les chemins d'accès pour regarder dans chacun des cas l'index qui est utilisé et voir s'il y a une différence.

Y a autre chose qu'un explain pour voir ca plus précisément ? ..