web-dev-qa-db-fra.com

MySQL - pourquoi ne pas indexer tous les champs?

Récemment, j'ai appris la merveille des index et les performances se sont considérablement améliorées. Cependant, avec tout ce que j'ai appris, je n'arrive pas à trouver la réponse à cette question.

Les index sont excellents, mais pourquoi quelqu'un ne pourrait-il pas indexer tous les champs pour rendre la table incroyablement rapide? Je suis sûr qu'il y a une bonne raison de ne pas le faire, mais que diriez-vous de trois champs dans une table de trente champs? 10 dans un domaine de 30? Où faut-il tracer la ligne et pourquoi?

79
Vael Victus

Les index prennent de la place en mémoire vive (RAM); Trop nombreux ou trop volumineux d’index et la base de données devra les échanger vers et depuis le disque. Ils augmentent également le temps d'insertion et de suppression (chaque index doit être mis à jour pour chaque donnée insérée/supprimée/mise à jour). 

Vous n'avez pas de mémoire infinie. Faire en sorte que tous les index tiennent dans RAM = bien.

Vous n'avez pas de temps infini. L'indexation des seules colonnes dont vous avez besoin minimise l'impact des performances d'insertion, de suppression et de mise à jour.

93
Brian Roach

N'oubliez pas que chaque index doit être mis à jour chaque fois qu'une ligne est mise à jour, insérée ou supprimée. Donc, plus vous avez d’index, moins vous aurez de performances pour les opérations d’écriture.

En outre, chaque index occupe davantage d'espace disque et de mémoire (lorsqu'il est appelé), de sorte qu'il peut également potentiellement ralentir les opérations de lecture (pour les grandes tables) . Voir ceci

19
AndyMac

Vous devez équilibrer les besoins CRUD. L'écriture sur les tables devient lente. Quant à savoir où tracer la ligne, cela dépend de la manière dont les données sont acquises (tri par filtrage, etc.).

9
Smandoli

L'indexation occupera plus d'espace alloué à la fois par le lecteur et par le ram, mais améliorera également considérablement les performances. Malheureusement, lorsqu'il atteint la limite de mémoire, le système cédera de l'espace sur le lecteur et compromettra les performances. Pratiquement, vous ne devriez pas indexer de champ que vous pourriez penser n'impliquant aucun type d'algorithme de parcours de données, ni insertion ni recherche (clause WHERE). Mais vous devriez sinon. Par défaut, vous devez indexer tous les champs. Les champs que vous devriez envisager de désindexer sont les suivants: les requêtes sont utilisées uniquement par le modérateur, sauf si elles ont également besoin de rapidité.

1
Lionel Jerinho

cette réponse est mon opinion personnelle basée je m utilise ma logique mathématique pour répondre

la deuxième question concernait la frontière où s’arrêter. Commençons par un calcul mathématique. Supposons que nous ayons N lignes avec L champs dans une table. Si nous indexons tous les champs, nous obtiendrons un L nouveaux tableaux d’index dans lesquels chaque tableau sera trié dans un tableau. les données du champ d’index ont un sens. En un coup d’œil, si votre table a un poids en W, elle deviendra W * 2 (1 tera deviendra 2 tera) si vous avez 100 grandes table (j’ai déjà travaillé dans le projet où le numéro de table était autour de 1800), vous perdrez 100 fois cet espace (100 tera), c’est loin d’être sage.

Si nous appliquons des index dans toutes les tables, nous devrons penser aux mises à jour des index lorsqu'un déclencheur de mise à jour déclenche tous les index, il s'agit d'une sélection de tous les équivalents non ordonnés dans le temps.

je conclus de cela que vous avez dans ce scénario que si vous perdez ce temps, il est préférable de le perdre dans une sélection ou une mise à jour, car si vous sélectionnez un champ non indexé, vous ne déclencherez pas une autre sélection sur tous les champs qui sont non indexé

quoi indexer?

foreign-keys: est un must basé sur

clé primaire: je ne suis pas encore sûr de ce que cela pourrait être si quelqu'un lisait ceci pourrait aider sur ce cas

autres champs: la première réponse naturelle est la moitié des réponses restantes. pourquoi: si vous devez indexer plus, vous n'êtes pas loin de la meilleure réponse si vous devez indexer moins, vous n'êtes pas aussi loin, car nous savons qu'aucun index n'est mauvais et tous indexés est aussi mauvais.

à partir de ces 3 points, je peux conclure que si nous avons L champs composés de clés K, la limite devrait être proche de ((L-K)/2)+K plus ou moins de L/10

cette réponse est basée sur ma logique et mes principes personnels

Ce n'est pas une bonne idée d'indexer toutes les colonnes d'une table. Bien que cela rende la table très rapide à lire, il devient également beaucoup plus lent d’écrire. Écrire dans une table dans laquelle chaque colonne est indexée impliquerait de placer le nouvel enregistrement dans cette table, puis les informations de chaque colonne dans sa propre table d'index.

0
Rachid Sakara