Résumé des opérations d'optimisation de la base de données MySQL

Cet article vous présente principalement les opérations d'optimisation courantes de la base de données mysql. L'article résume mon expérience quotidienne dans le développement et l'utilisation d'une base de données mysql, y compris l'index d'index, l'utilisation de moins de SELECT*, EXPLAIN SELECT et l'activation du cache de requêtes, je le crois. aura une certaine valeur de référence pour tous les amis qui en ont besoin peuvent jeter un œil ci-dessous.

Avant-propos

Pour une application centrée sur les données, la qualité de la base de données affecte directement les performances du programme, les performances de la base de données sont donc cruciales important. Par conséquent, tout le monde doit comprendre les opérations d'optimisation de la base de données MySQL. Cet article résume principalement les opérations d'optimisation courantes dans la base de données MySQL. Je n'entrerai pas dans plus de détails ci-dessous, jetons un œil à l'introduction détaillée.

1. Index

Mettez l'index en premier. Inutile de dire que nous avons utilisé cette méthode d'optimisation en silence, alors c'est la clé primaire. indice. Parfois, nous ne nous en soucions pas. Si un index approprié est défini, les performances (vitesse) des requêtes de base de données seront améliorées plusieurs fois, voire des dizaines de fois.

L'index normal

est utilisé pour améliorer la vitesse des requêtes.

Créer une table, créer un index

CREATE TABLE tbl_name(
字段名称 字段类型 [完整性约束条件],
~
index [索引名] (column_name)
);

Créer un index

CREATE INDEX index_name ON tab_name (column_name)

Supprimer l'index

DROP INDEX index_name FROM tab_name

Afficher l'index

SHOW index FROM tab_name

Index de clé primaire

Le rôle est d'accélérer les requêtes et les contraintes uniques

Créer des tables et créer des index

CREATE TABLE tbl_name(
字段名称 字段类型 [完整性约束条件],
~
PRIMARY KEY(column_name)
);

Créer des index

ALTER TABLE tab_name ADD PRIMARY KEY(column_name)

Supprimer l'index

ALTER TABLE tab_name DROP PRIMAY KEY(column_name)

Index unique

La fonction est d'accélérer les requêtes et les contraintes uniques

Créez des tables et créez des index

CREATE TABLE tbl_name(
字段名称 字段类型 [完整性约束条件],
~
unique [索引名] (column_name)
);

Créer un index

CREATE UNIQUE INDEX index_name ON tab_name (column_name)

Supprimer l'index

DROP UNIQUE INDEX index_name FROM tab_name

Utiliser moins SELECT*

Certaines personnes peuvent sélectionner ce qu'elles souhaitent interroger lors de l'interrogation de la base de données. Il s'agit d'un comportement inapproprié. Nous devrions obtenir les données que nous voulons utiliser, pas toutes, car lorsque nous les sélectionnons, cela augmentera la charge sur le serveur Web, augmentera la charge sur la transmission réseau et la vitesse des requêtes diminuera naturellement.

3. EXPLAIN SELECT

On estime que de nombreuses personnes n'ont jamais vu cette fonction, mais il est fortement recommandé de l'utiliser. expliquer montre comment MySQL utilise les index pour gérer les instructions de sélection et les tables de jointure. Peut aider à choisir de meilleurs index et à écrire des instructions de requête plus optimisées. L'utilisation principale est d'ajouter une explication avant de sélectionner.

EXPLAIN SELECT [查找字段名] FROM tab_name ...

4. Activer le cache de requêtes

La plupart des serveurs MySQL ont le cache de requêtes activé. C'est l'un des moyens les plus efficaces d'améliorer les performances, et il est géré par le moteur de base de données MySQL. Lorsque plusieurs requêtes identiques sont exécutées plusieurs fois, les résultats de la requête seront placés dans un cache, de sorte que les requêtes identiques suivantes accéderont directement aux résultats mis en cache sans utiliser la table.

La première étape consiste à définir query_cache_type sur ON, puis à vérifier si la variable système have_query_cache est disponible :

show variables like 'have_query_cache'

Après cela, allouez la taille de la mémoire au cache de requêtes et contrôler la taille maximale des résultats de requête mis en cache. Les opérations pertinentes sont modifiées dans le fichier de configuration.

5. Utilisez NOT NULL

De nombreuses tables contiennent des colonnes qui peuvent être NULL (valeur nulle), même si l'application n'en a pas besoin. enregistrez-les La même chose est vraie pour NULL, car être NULLable est la propriété par défaut d'une colonne. Il est généralement préférable de spécifier les colonnes comme NOT NULL, sauf si vous avez vraiment besoin de stocker des valeurs NULL.

Les requêtes contenant des colonnes NULLable sont plus difficiles à optimiser pour MySQL car les colonnes NULLable rendent les index, les statistiques d'index et les comparaisons de valeurs plus complexes. Les colonnes qui peuvent être NULL utilisent plus d'espace de stockage et nécessitent un traitement spécial dans MySQL. Lorsque les colonnes NULLable sont indexées, chaque enregistrement d'index nécessite un octet supplémentaire, ce qui, dans MyISAM, peut même faire qu'un index de taille fixe (comme un index avec une seule colonne entière) devienne un index de taille variable.

Habituellement, changer la colonne qui peut être NULL en NOT NULL n'apporte que peu d'amélioration des performances, donc (lors du réglage), il n'est pas nécessaire de rechercher et de modifier d'abord cette situation dans le schéma existant, sauf si vous en êtes sûr. cela posera un problème. Cependant, si vous envisagez de créer un index sur une colonne, vous devez éviter de concevoir la colonne comme étant NULL. Bien sûr, il existe des exceptions. Par exemple, il convient de mentionner qu'InnoDB utilise un bit séparé pour stocker les valeurs NULL, ce qui lui confère une bonne efficacité spatiale pour les données clairsemées. Mais cela ne s'applique pas à MyISAM.

6. Sélection du moteur de stockage

Concernant la façon de choisir MyISAM et InnoDB, si vous avez besoin d'un traitement de transaction ou de clés étrangères, alors InnoDB peut est une meilleure façon. Si vous avez besoin d'une indexation en texte intégral, MyISAM est généralement un bon choix car il est intégré au système. Cependant, nous ne testons pas très souvent 2 millions de lignes d'enregistrements. Ainsi, même si c'est un peu plus lent, nous pouvons obtenir un index en texte intégral depuis InnoDB en utilisant Sphinx.

数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要

几个小时甚至几天来干这些事，InnoDB只需要几分钟。

您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM表中会非常快，而在InnoDB表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts语句在MyISAM下会快一些，但是updates在InnoDB 下会更快一些——尤其在并发量大的时候。

所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM也许会更适合。当然，在大型的环境下使用MyISAM也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方式。但需要记住InnoDB的表需要更多的内存和存储，转换100GB的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。

七、避免在 where 子句中使用 or 来连接

如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or Name = 'admin'

可以这样查询：

select id from t where num = 10
union all
select id from t where Name = 'admin'

八、多使用varchar/nvarchar

使用varchar/nvarchar代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

九、避免大数据量返回

这里要考虑使用limit，来限制返回的数据量，如果每次返回大量自己不需要的数据，也会降低查询速度。

十、where子句优化

where 子句中使用参数，会导致全表扫描,因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。

应尽量避免在 where 子句中对字段进行表达式操作，避免在where子句中对字段进行函数操作这将导致引擎放弃使用索引而进行全表扫描。不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!