Y a-t-il un gain de performance dans l’indexation d’un champ booléen?

Pas vraiment. Vous devriez y penser comme un livre. S’il n’y avait que 3 types de mots dans un livre et que vous les indexiez tous, vous auriez le même nombre de pages d’index que les pages normales.

Il y aurait un gain de performance s’il y a relativement peu d’enregistrements d’une valeur. Par exemple, si vous avez 1000 enregistrements et que 10 d’entre eux sont TRUE, alors il serait utile de chercher avec isok = 1

Comme Michael Durrant l’a mentionné, cela ralentit également les écritures.

EDIT: duplication possible: indexation des champs booléens

Ici, cela explique que même si vous avez un index, si vous avez trop d’enregistrements, il n’utilise de toute façon pas l’index. MySQL n’utilise pas d’index lors de la vérification = 1, mais avec = 0

Juste pour mettre un point plus précis sur plusieurs autres réponses ici, puisque dans mon expérience, ceux qui regardent des questions comme celle-ci se trouvent dans le même bateau que nous, nous avons tous entendu dire que l’indexation des champs booléens est inutile.

Nous avons une table avec environ 4 millions de lignes, seulement environ 1000 à la fois auront un commutateur booléen et c’est ce que nous recherchons. L’ajout d’un index sur notre champ booléen a accéléré les requêtes par ordre de grandeur, passant d’environ 9 secondes à une fraction de seconde.

Cela dépend des requêtes réelles et de la sélectivité de la combinaison index / requête.

Cas A : condition WHERE isok = 1 et rien d’autre ici:

 SELECT * FROM tableX WHERE isok = 1 

• Si l’index est suffisamment sélectif (disons que vous avez 1M de lignes et que seulement 1k ont isok = 1 ), le moteur SQL utilisera probablement l’index et sera plus rapide que sans lui.

• Si l’index n’est pas suffisamment sélectif (disons que vous avez 1M de lignes et que plus de 100k ont isok = 1 ), le moteur SQL n’utilisera probablement pas l’index et effectuera une parsing de table.

Cas B : condition WHERE isok = 1 et plus:

 SELECT * FROM tableX WHERE isok = 1 AND another_column = 17 

Ensuite, cela dépend des autres index que vous avez. Un index sur another_column serait probablement plus sélectif que l’index sur isok qui n’a que deux valeurs possibles. Un index sur (another_column, isok) ou (isok, another_column) serait encore mieux.

Non, généralement pas.

Vous indexez généralement les champs pour la recherche lorsqu’ils ont une sélectivité / cardinalité élevée. La cardinalité d’un champ booléen est très faible dans la plupart des tableaux. Cela rendrait également vos écritures plus lentes.

Oui, un index améliorera les performances, vérifiez la sortie de EXPLAIN avec et sans l’index.

De la documentation:

Les index permettent de trouver rapidement des lignes avec des valeurs de colonne spécifiques. Sans index, MySQL doit commencer par la première ligne, puis parcourir toute la table pour trouver les lignes appropriées. Plus la table est grande, plus cela coûte cher. Si la table a un index pour les colonnes en question, MySQL peut rapidement déterminer la position à rechercher au milieu du fichier de données sans avoir à examiner toutes les données.

Je pense qu’il est également prudent de dire qu’un index ne DIMINUERA PAS les performances dans ce cas, vous n’avez donc qu’à en tirer profit.

Cela dépend de la dissortingbution des données.

Imaginez que j’avais un livre avec 1000 pages bien typescriptes et que les seuls mots de mon livre étaient «oui» et «non» répétés et dissortingbués de manière aléatoire. Si on me demandait d’encercler toutes les instances de «oui», un index au dos du livre serait-il utile? Ça dépend.

S’il y avait une dissortingbution aléatoire à moitié et demi de oui et de non, alors chercher dans l’index ne serait pas utile. L’index rendrait le livre plus volumineux, et de toute façon je serais plus rapide que de commencer par le début et de parcourir chaque page en cherchant tous les exemples de «oui» et en les encerclant, plutôt que de rechercher chaque élément dans l’index puis en prenant la référence de l’entrée d’index à la page à laquelle il se réfère.

Mais s’il y avait, par exemple, seulement dix «oui» dans mon livre de mille pages et que tout le rest ne contenait que des millions, alors un index me permettrait de trouver ces dix cas de «oui» et de les encercler. .

C’est la même chose dans les bases de données. Si c’est une dissortingbution 50:50, alors un index ne va pas aider – le moteur de firebase database est mieux placé que de parcourir les données du début à la fin (parsing de table complète), et l’index ne ferait que grossir la firebase database. plus lent à écrire et à mettre à jour. Mais si c’est quelque chose comme une dissortingbution 4000: 1 (comme dans ce fil), alors une recherche d’index peut l’accélérer énormément, si c’est le 1 sur 4000 que vous recherchez.

En fait, cela dépend des requêtes que vous exécutez. Mais, généralement oui, ainsi que l’indexation d’un champ de tout autre type.