[MySQL] INDEX sur une colonne qui peut être NULL

[dorian53]

Bonjour,

Lorsque que je crée un "index" sur une colonne qui a la possibilité d'être NULL, j'ai remarqué qu'il y avait autant d'index que d'enregistrement (et non pas autant que de valeurs différente).

Est-ce normal ?
Est-ce une erreur de conception ?

Merci

 

[jarreweb]

essaye peut-etre la commande OPTIMIZE TABLE pour voir ce que ca donne

 

[dorian53]

En effet j'avais pensé à ça et tout executé : vérifier, optimiser, réparer, etc... mais toujours pareil.

 

[dorian53]

Personne ?

 

[medium69]

J'ai contourné le problème en laissant un champ vide ou 0 en fonction du type.

Sachant cela, je peux faire les traitements qui s'impose sur le PHP.

Je trouve que c'était un peu trop contraignant

 

[dorian53]

Le NULL et le 0 sont pour moi des valeurs avec une fonction spécifique.

C'est donc normal qu'il y ait autant d'index que d'enregistrement ?

 

[dorian53]

Si j'ai les enregistrements suivants avec un index sur COLONNE_B (qui peut être NULL) :

COLONNE_A                  COLONNE_B
   valeur1                        NULL
   valeur2                        NULL
   valeur3                        1
   valeur4                        1
   valeur5                        2

Dans mon esprit, j'ai 3 index et il y en a réellement 3 si COLONNE_B ne peut pas être mise à NULL ("autant que de valeurs différentes").

Alors que lorsque NULL est autorisé comme dans cet exemple, j'obtiens 5 index (et non 3).


Est-ce normal ?
Ce n'a t-il rien à voir avec NULL ?


Edit: faute ortho

 

[rog]

null est une valeur (\0)

rog

 

[dorian53]

Hum, c'est à dire ? Ca devrait m'apporter la réponse ?

 

[rog]

il me semble qu'il n'y a aucune raison pour que mysql ne crée pas d'index sur des valeurs null dans un champs les acceptant puisque null est une valeur (\0)

rog

 

[dorian53]

(Abus de langage car je pense que NULL n'est pas une valeur, bref c'est pas le soucis je le dis aussi)


Oké, je ne dis pas le contraire mais pourquoi y a t-il deux comportements différents dans la façon de compter les index ?
Est-ce NULL qui influe ou modifie la manière de compter ?

 

[rog]

a mon avis c'est tout simplement parce que le champs n'acceptant pas la valeur null, le champs est considéré vide

obs : null est dangereux car il termine une variable char en C

rog

 

[dorian53]

Là oui c'est logique, mais pourquoi il a t-il autant d'index que de valeurs différentes quand NULL est autorisé ?

 

[rog]

il me semble que la structure b-tree necessite que tous les elements soient représentés dans l'index

rog

 

[dorian53]

Okay je suis bien en b-tree, ca serait donc à cause de cela qu'il y a un tel comportement.

Est-ce sûr ?

L'index est-il utile et pris en compte ?

 

[rog]

wow

faut pas flipper comme ça dorian

un server solide
des tables bien conçues
des index sur les champs qui sont conditionnés dans les clauses
des requêtes securisées
une bonne synchro remote

et en voiture simone

rog

 

[dorian53]

Je flippe pas j'veux comprendre comment fonctionne ce principe d'index

 

[medium69]

[sans rapport avec le fil]Rog, j'aime pas ton avatar ; l'ancien était plus cool[/sans rapport avec le fil]

 

[rog]

yop j'ai changé

le principe des index est de créer une ressource qui regroupe les éléments par groupe

pour permettre d'economiser les acces de pointeur

sur 1000 000 d'elements et 100 000 groupes, le pointeur fera au maximum 100 000 access pour retourner les 10 elements du groupe

au lieu de 1000 000 sur un acces naturel

rog

 

[medium69]

yop j'ai changé

Au moins maintenant, on sait sur quoi il tirait ton premier avatar !

Il se faisait un troupeau de chat :wink:


Pour en revenir au index, je conçois ce que tu dis, mais je ne comprend pas trop non plus pourquoi deux champs NULL donnent droit à deux index.
C'est un peu illogique...

 

[rog]

lol

parce que dans le cas ou null est une valeur acceptée par le champs, la valeur null n'est pas vide (chr(0))

donc comme les elements dont la valeur pour ce champ est null doivent bien être indexés pour pouvoir amener le pointeur sur le groupe des éléments dont la valeur pour ce champs est null

et bien ils auront un index

en fait c'est juste le concept null n'est pas vide et n'est pas egal à rien qui doit choquer

rog

 

[dorian53]

lol

parce que dans le cas ou null est une valeur acceptée par le champs, la valeur null n'est pas vide (chr(0))

donc comme les elements dont la valeur pour ce champ est null doivent bien être indexés pour pouvoir amener le pointeur sur le groupe des éléments dont la valeur pour ce champs est null

et bien ils auront un index

en fait c'est juste le concept null n'est pas vide et n'est pas egal à rien qui doit choquer

rog

Oké d'accord NULL aurait donc lui aussi son index.
Mais ça aurait été trop simple comme explication car dans cet exemple...

COLONNE_A                  COLONNE_B
   valeur1                        NULL
   valeur2                        NULL
   valeur3                        1
   valeur4                        1
   valeur5                        2

Il y a réellement 5 index et non 4 (si on admettait un index pour chaque NULL) ?

1er  index NULL
2e   index NULL
3e   index 1
4e   index 2

Et pas 3 non plus (si on admettait un index pour tous les NULL) ?

1er  index NULL
2e   index 1
3e   index 2

NULL bouleverse toute logique...