MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Comprendre les index dans MySQL :deuxième partie

Ce billet de blog est la deuxième partie de la série de blogs sur les index dans MySQL. Dans la première partie de la série d'articles de blog sur les index MySQL, nous avons couvert pas mal de choses, y compris ce qu'ils sont, ce qu'ils font, quels sont leurs types, comment choisir les types de données optimaux et les jeux de caractères MySQL pour les index que vous utilisez. . Nous avons passé en revue les avantages et les inconvénients de l'utilisation des index dans MySQL ; nous vous avons expliqué comment choisir le meilleur index à utiliser, comment améliorer les performances des requêtes et vous assurer que MySQL utilise vos index, combien d'index devriez-vous avoir. Nous avons également passé en revue certaines considérations liées aux moteurs de stockage. Ce billet de blog entrera plus en détail concernant certains des contenus dont nous avons discuté dans la première partie de la série. Nous allons commencer par la corrélation entre les index et les moteurs de stockage dans MySQL.

Index et moteurs de stockage dans MySQL

Comme nous l'avons déjà mentionné dans un article de blog précédent, il peut y avoir certaines sortes de limitations aux index et autres choses si vous utilisez certains moteurs de stockage dans MySQL. Voici quelques-uns d'entre eux - nous allons maintenant définir ce que certains d'entre eux sont (certains d'entre eux ont été couverts dans la première partie de la série de blogs, donc s'il nous manque quelque chose, c'est probablement là-dedans), puis couvrez-les avec une analyse plus approfondie analyse :

  • Conformément à la documentation MySQL, le nombre maximal d'index, la longueur maximale de la clé et la longueur maximale de l'index sont défini par moteur de stockage. Comme nous l'avons déjà mentionné dans un article de blog précédent, le nombre maximum d'index par tables MyISAM et InnoDB est de 64, le nombre maximum de colonnes par index dans les deux moteurs de stockage est de 16, la longueur de clé maximale pour InnoDB est de 3500 octets et le maximum la longueur de clé pour MyISAM est de 1000 octets.

  • Vous ne pouvez pas utiliser CREATE INDEX pour créer une PRIMARY KEY - utilisez ALTER TABLE à la place.

  • Les colonnes BLOB et TEXT ne peuvent être indexées que pour les tables exécutant les moteurs de stockage InnoDB, MyISAM et BLACKHOLE.

  • Si vous n'indexez qu'un préfixe de la colonne, gardez à l'esprit que la prise en charge des préfixes et leur longueur sont également dépend des moteurs de stockage. Un préfixe peut avoir jusqu'à 767 octets de long pour les tables InnoDB qui utilisent le format de ligne REDUNDANT ou COMPACT, mais pour les formats de ligne DYNAMIC ou COMPRESSED, la limite de longueur du préfixe est augmentée à 3072 octets. Pour les tables MyISAM, la limite de longueur de préfixe est de 1000 octets. Le moteur de stockage NDB ne prend pas du tout en charge les préfixes.

  • Si un mode SQL strict est activé et que le préfixe d'index dépasse la taille maximale du type de données de colonne, CREATE INDEX lance une erreur. Si un mode SQL strict n'est pas activé, CREATE INDEX produit un avertissement. Si un INDEX UNIQUE est créé, une erreur se produit.

  • En général, MySQL vous permet uniquement de créer jusqu'à 16 index sur une table donnée.

  • Si vous utilisez un index PRIMARY KEY, vous ne pouvez avoir qu'une seule clé primaire par table. FULLTEXT, UNIQUE INDEX et INDEX n'ont pas cette limitation.

  •  Si vous utilisez des index FULLTEXT, gardez à l'esprit qu'ils ne peuvent être utilisés que pour les moteurs de stockage InnoDB ou MyISAM et pour les colonnes CHAR, VARCHAR ou TEXT. Gardez également à l'esprit que MySQL n'utilise les index FULLTEXT que lorsque les clauses MATCH() AGAINST() sont utilisées et que vous pouvez en fait avoir un index et un index de texte intégral sur la même colonne en même temps si vous le souhaitez et que les index FULLTEXT ont leur propre ensemble de mots vides, chacun spécifique aux moteurs de stockage utilisés.

  • Les index B-Tree peuvent être utiles si vous utilisez des requêtes LIKE qui commencent par un caractère générique, mais uniquement dans certains cas. scénarios.

Connaître ces limitations d'index devrait s'avérer utile si vous essayez de comprendre le fonctionnement des index dans MySQL. Ce qui est encore plus important à comprendre, c'est le fait que vous devez vérifier que vos index sont réellement utilisés par MySQL. Nous en avons brièvement parlé dans la première partie de cette série (« Comment choisir le meilleur index à utiliser ? »), mais nous ne vous avons pas dit comment vérifier que vos index sont effectivement utilisés par MySQL. Pour ce faire, vérifiez leur utilisation en utilisant EXPLAIN - lorsque EXPLAIN est utilisé avec une instruction explicable, MySQL affiche les informations de l'optimiseur sur le plan d'exécution de l'instruction.

Considérations sur la CLÉ PRIMAIRE

Certaines des considérations de base relatives aux index PRIMARY KEY dans MySQL incluent le fait qu'ils sont principalement utilisés pour identifier de manière unique les enregistrements dans une table et sont fréquemment utilisés avec des valeurs AUTO_INCREMENT, ce qui signifie qu'ils peuvent être très utiles si vous créez, par exemple, des champs ID. Les champs PRIMARY KEY doivent contenir des valeurs uniques et ne peuvent pas contenir de valeurs NULL.

Correspondance d'un préfixe de colonne

Les index peuvent également correspondre à un préfixe de colonne. Cette approche des index peut être utile si vos colonnes sont des colonnes de chaîne et que vous pensez que l'ajout d'un index sur l'ensemble de la colonne consommerait potentiellement beaucoup d'espace disque. Vos index peuvent correspondre à un préfixe de colonne comme ceci :

ALTER TABLE demo_table ADD INDEX index_name(column_name(length));

La requête ci-dessus ajouterait un index index_name sur une colonne nommée column_name uniquement pour un préfixe de colonne défini. Pour choisir une bonne longueur à indexer, assurez-vous que votre utilisation du préfixe maximise l'unicité des valeurs dans la colonne :recherchez le nombre de lignes dans la table et évaluez différentes longueurs de préfixe jusqu'à ce que vous obteniez l'unicité des lignes souhaitée.

Index FULLTEXT dans MySQL

Les index FULLTEXT dans MySQL sont une toute autre bête. Ils ont de nombreuses limitations qui leur sont propres (par exemple, InnoDB a une liste de mots vides composée de 36 mots tandis que la liste de mots vides MyISAM est composée de 143 mots), ils ont également des modes de recherche uniques. Certains d'entre eux incluent un mode de langage naturel (pour activer un tel mode de recherche, exécutez une requête de recherche FULLTEXT sans modificateurs), vous pouvez également étendre votre recherche (pour cela, utilisez le modificateur WITH QUERY EXPANSION - un tel mode de recherche effectue la recherche deux fois, mais lorsque la recherche s'exécute pour la deuxième fois, elle inclut quelques enregistrements les plus pertinents de la première recherche - fréquemment utilisés lorsqu'un utilisateur a une connaissance implicite de quelque chose), pour rechercher avec des opérateurs booléens, utilisez le modificateur IN BOOLEAN MODE. Les index FULLTEXT ne seront également utilisés que si la requête de recherche se compose d'un minimum de trois caractères pour InnoDB et d'un minimum de quatre caractères pour MyISAM.

Utilisation des index B-Tree avec des caractères génériques

Les index sont également fréquemment utilisés si vous construisez quelque chose de similaire aux moteurs de recherche. Pour cela, vous souhaitez souvent rechercher uniquement une partie d'une valeur et renvoyer les résultats - c'est là que les caractères génériques interviennent. Une requête simple utilisant un caractère générique utilise une requête LIKE et le signe % pour signifier "n'importe quoi" après le texte. Par exemple, une requête comme celle-ci rechercherait des résultats commençant par le mot « recherche » et ayant n'importe quoi après :

SELECT * FROM … WHERE demo_column LIKE ‘search%’;

Une requête comme celle-ci rechercherait des résultats commençant par n'importe quoi, ayant le mot "recherche" et ayant n'importe quoi après :

SELECT * FROM … WHERE demo_column LIKE ‘%search%’;

Mais voici un hic :la requête ci-dessus n'utilisera pas d'index. Pourquoi? Parce qu'il a un caractère générique au début de lui-même et que MySQL ne peut pas déterminer ce dont la colonne a besoin pour commencer. C'est pourquoi nous avons dit que les index génériques ont leur place, mais uniquement dans des scénarios spécifiques, c'est-à-dire des scénarios où vous n'avez pas de caractère générique au début de votre requête de recherche.

Utiliser ClusterControl pour surveiller les performances des requêtes

En plus d'utiliser EXPLAIN, vous pouvez également utiliser ClusterControl pour surveiller les performances de vos requêtes :ClusterControl fournit un ensemble de fonctionnalités avancées de surveillance et de création de rapports qui vous permettent de suivre les performances de vos instances de base de données et de vos requêtes. . Par exemple, cliquez sur un cluster et vous verrez un onglet "Moniteur de requête". Cliquez dessus et ClusterControl vous permettra d'observer l'état de vos requêtes dans vos instances de base de données :

Cette partie de ClusterControl vous permet d'afficher une liste des principaux fichiers lents et longs. exécuter des requêtes tout en vous permettant de les filtrer. Par exemple, si vous savez qu'il n'y a pas longtemps, vous avez exécuté une requête composée de @@log_bin, vous pouvez simplement rechercher le terme et ClusterControl renverra une liste de résultats :

Comme vous l'avez probablement remarqué, vous pouvez également filtrer les requêtes par les hôtes que vous utilisez ou par occurrences, vous pouvez également choisir de voir un ensemble de lignes, par exemple, 20, 100 ou 200. ClusterControl vous indiquera également quand la requête a été vue pour la dernière fois, quel était son temps d'exécution total, combien de lignes elle avait renvoyées, combien de lignes a-t-il examiné et ainsi de suite. ClusterControl peut s'avérer utile si vous souhaitez observer comment vos index sont réellement utilisés par les instances MySQL, MariaDB, MongoDB, PostgreSQL ou TimescaleDB.

Résumé

Dans cet article de blog, nous avons passé en revue certaines limitations et avantages concernant les index dans MySQL et nous avons également expliqué comment ClusterControl peut vous aider à atteindre vos objectifs de performances de base de données. Nous aurons également une troisième partie sur les index dans MySQL qui les approfondira davantage, mais pour conclure ce que nous avons couvert jusqu'à présent, gardez à l'esprit que les index dans MySQL ont certainement leur propre place - pour en tirer le meilleur parti, sachez comment ils interagissent avec les moteurs de stockage, leurs avantages et leurs limites, comment et quand utiliser certains types d'index et choisir judicieusement.