Explication détaillée de l'optimisation de la base de données MySQL

Une architecture de base de données mature n'est pas conçue avec une haute disponibilité, une haute évolutivité et d'autres fonctionnalités dès le début. Elle est conçue avec l'augmentation du nombre. des utilisateurs. , l’infrastructure a été progressivement améliorée. Cet article de blog parle principalement des problèmes et des solutions d'optimisation rencontrés dans le cycle de développement de la base de données MySQL. En mettant de côté l'application frontale pour le moment, il est grossièrement divisé en cinq étapes :

1, Conception de la table de base de données

Une fois le projet approuvé, le service de développement développe le projet en fonction des besoins du service produit. Une partie du travail de l'ingénieur de développement. est de concevoir la structure de la table. Pour les bases de données, cela est très important s’il n’est pas conçu correctement, cela affectera directement la vitesse d’accès et l’expérience utilisateur. Il existe de nombreux facteurs d'influence, tels que des requêtes lentes, des instructions de requête inefficaces, une indexation incorrecte, une congestion de la base de données (blocage), etc. Bien sûr, il existe une équipe d’ingénieurs de test qui effectueront des tests de résistance et trouveront des bugs. Pour les équipes sans ingénieurs de test, la plupart des ingénieurs de développement ne se demanderont pas trop si la conception de la base de données est raisonnable au début, mais termineront la mise en œuvre et la livraison des fonctions dès que possible. Après un certain nombre de visites, le projet. des problèmes cachés seront révélés. Il ne sera pas si facile de le modifier à nouveau.

2. Déploiement de la base de données

L'ingénieur d'exploitation et de maintenance est apparu Le nombre de visites dans la phase initiale du projet ne sera pas. très important, donc un seul déploiement suffit pour y faire face. QPS (taux de requête par seconde) autour de 1500. Compte tenu de la haute disponibilité, la réplication maître-esclave MySQL Keepalived peut être utilisée pour la sauvegarde à chaud en double-clic. Les logiciels de cluster courants incluent Keepalived et Heartbeat.

Article de blog en veille chaude sur deux machines : http://www.php.cn/

Optimisation des performances de la base de données

Si MySQL est déployé de manière ordinaire Lorsqu'il y a des connexions simultanées, les performances de traitement de la base de données ralentiront et les ressources matérielles sont encore abondantes. À ce stade, il est temps de considérer les problèmes logiciels. Alors comment maximiser les performances de la base de données ? D'une part, plusieurs instances MySQL peuvent être exécutées sur un seul serveur pour maximiser les performances du serveur. D'autre part, la base de données est optimisée. Souvent, les configurations par défaut du système d'exploitation et de la base de données sont relativement conservatrices, ce qui présente certaines limitations. Les performances de la base de données peuvent être effectuées. Effectuez les ajustements appropriés pour gérer autant de connexions que possible.

L'optimisation spécifique comporte les trois niveaux suivants :

3.1 Optimisation de la configuration de la base de données

Il existe deux moteurs de stockage couramment utilisés dans MySQL, l'un est MyISAM , qui n'est pas pris en charge Traitement des transactions, performances de lecture rapides et verrouillage au niveau de la table. L'autre est InnoDB, qui prend en charge le traitement des transactions (ACID). L'objectif de conception est de maximiser les performances et les verrouillages au niveau des lignes pour le traitement de gros volumes de données.

• Verrouillage de table : faible surcharge, grande granularité de verrouillage, forte probabilité de blocage et concurrence relativement faible.

• Verrouillage de ligne : surcharge élevée, faible granularité de verrouillage, faible probabilité de blocage et concurrence relativement élevée.

Pourquoi les verrous de table et de ligne se produisent-ils ? Principalement pour garantir l'intégrité des données.Par exemple, si un utilisateur exploite une table et que d'autres utilisateurs souhaitent également exploiter la table, ils doivent attendre que le premier utilisateur termine l'opération avant que les autres utilisateurs puissent utiliser les verrous et les lignes de la table. c'est ce que font les serrures. Sinon, si plusieurs utilisateurs utilisent une table en même temps, des conflits de données ou des exceptions se produiront certainement.

Sur la base de ce qui précède, l'utilisation du moteur de stockage InnoDB est le meilleur choix, et c'est également le moteur de stockage par défaut dans MySQL 5.5 et les versions ultérieures. De nombreux paramètres sont associés à chaque moteur de stockage. Les paramètres qui affectent principalement les performances de la base de données sont répertoriés ci-dessous.

Valeur par défaut des paramètres publics :

max_connections = 151
#同时处理最大连接数，推荐设置最大连接数是上限连接数的80%左右
sort_buffer_size = 2M
#查询排序时缓冲区大小，只对order by和group by起作用，可增大此值为16M
query_cache_limit = 1M
#查询缓存限制，只有1M以下查询结果才会被缓存，以免结果数据较大把缓存池覆盖
query_cache_size = 16M
#查看缓冲区大小，用于缓存SELECT查询结果，下一次有同样SELECT查询将直接从缓存池返回结果，可适当成倍增加此值
open_files_limit = 1024
#打开文件数限制，如果show global status like 'open_files'查看的值等于或者大于open_files_limit值时，程序会无法连接数据库或卡死

Valeur par défaut des paramètres MyISAM :

key_buffer_size = 16M
#索引缓存区大小，一般设置物理内存的30-40%
read_buffer_size = 128K
#读操作缓冲区大小，推荐设置16M或32M

Valeur par défaut des paramètres InnoDB :

innodb_buffer_pool_size = 128M
#索引和数据缓冲区大小，一般设置物理内存的60%-70%
innodb_buffer_pool_instances = 1
#缓冲池实例个数，推荐设置4个或8个
innodb_flush_log_at_trx_commit = 1
#关键参数，0代表大约每秒写入到日志并同步到磁盘，数据库故障会丢失1秒左右事务数据。1为每执行一条SQL后写入到日志并同步到磁盘，I/O开销大，执行完SQL要等待日志读写，效率低。2代表只把日志写入到系统缓存区，再每秒同步到磁盘，效率很高，如果服务器故障，才会丢失事务数据。对数据安全性要求不是很高的推荐设置2，性能高，修改后效果明显。
innodb_file_per_table = OFF
#默认是共享表空间，共享表空间idbdata文件不断增大，影响一定的I/O性能。推荐开启独立表空间模式，每个表的索引和数据都存在自己独立的表空间中，可以实现单表在不同数据库中移动。
innodb_log_buffer_size = 8M
#日志缓冲区大小，由于日志最长每秒钟刷新一次，所以一般不用超过16M

3.2 Optimisation du noyau système

La plupart de MySQL est déployé sur les systèmes Linux, donc certains paramètres du système d'exploitation affecteront également les performances de MySQL. Ce qui suit est une optimisation appropriée du noyau Linux.

net.ipv4.tcp_fin_timeout = 30
#TIME_WAIT超时时间，默认是60s
net.ipv4.tcp_tw_reuse = 1
#1表示开启复用，允许TIME_WAIT socket重新用于新的TCP连接，0表示关闭
net.ipv4.tcp_tw_recycle = 1
#1表示开启TIME_WAIT socket快速回收，0表示关闭
net.ipv4.tcp_max_tw_buckets = 4096
#系统保持TIME_WAIT socket最大数量，如果超出这个数，系统将随机清除一些TIME_WAIT并打印警告信息
net.ipv4.tcp_max_syn_backlog = 4096
#进入SYN队列最大长度，加大队列长度可容纳更多的等待连接

Dans le système Linux, si le nombre de descripteurs de fichiers ouverts par un processus dépasse la valeur par défaut du système de 1024, le message "trop ​​de fichiers ouverts" sera affiché, donc la limite de descripteurs de fichiers ouverts doit être ajusté.

# vi /etc/security/limits.conf #加入以下配置，*代表所有用户，也可以指定用户，重启系统生效
* soft nofile 65535
* hoft nofile 65535
# ulimit -SHn 65535 #立刻生效

3.3 Configuration matérielle

Augmentez la mémoire physique et améliorez les performances du système de fichiers. Le noyau Linux allouera des zones de cache (cache système et cache de données) de la mémoire pour stocker les données chaudes via le mécanisme d'écriture différée du système de fichiers, la synchronisation ne se produira que lorsque les conditions seront remplies (telles que la zone de cache atteignant un certain pourcentage ou la synchronisation). commande en cours d'exécution). En d’autres termes, plus la mémoire physique est grande, plus la zone de cache allouée est grande et plus les données mises en cache sont nombreuses. Bien entendu, une certaine quantité de données mises en cache sera perdue en cas de panne du serveur.

Le disque dur SSD remplace le disque dur SAS, et le niveau RAID est ajusté à RAID1 0, qui a de meilleures performances de lecture et d'écriture (IOPS) que RAID1 et RAID5. Après tout, la pression sur la base de données vient principalement de. E/S disque.

4. Expansion de l'architecture de base de données

À mesure que le volume d'activité augmente, les performances d'un seul serveur de base de données ne peuvent plus répondre aux besoins de l'entreprise. il est temps d'envisager d'ajouter une machine, et il est temps de créer un cluster~~~. L'idée principale est de décomposer la charge d'une seule base de données, d'améliorer les performances des E/S disque, de stocker les données chaudes dans le cache et de réduire la fréquence d'accès aux E/S disque.

4.1 Réplication maître-esclave et séparation lecture-écriture

Étant donné que la plupart des bases de données de l'environnement de production sont des opérations de lecture, nous déployons une architecture un maître-multi-esclave. La base de données principale est responsable des opérations d'écriture et du double-clic à chaud. la sauvegarde et plusieurs bases de données esclaves effectuent la balance de charge, responsables des opérations de lecture. Les équilibreurs de charge grand public incluent LVS, HAProxy et Nginx. Comment parvenir à la séparation de la lecture et de l'écriture ? La plupart des entreprises mettent en œuvre la séparation de la lecture et de l’écriture au niveau du code, ce qui est plus efficace. Une autre façon consiste à réaliser une séparation lecture-écriture via un programme proxy, qui est rarement utilisé dans les entreprises. Les programmes proxy courants incluent MySQL Proxy et Amoeba. Dans une telle architecture de cluster de bases de données, la capacité de concurrence élevée de la base de données est considérablement augmentée et le problème de goulot d'étranglement des performances d'une seule machine est résolu. Si une base de données esclave peut gérer 2 000 QPS, alors 5 bases de données esclaves peuvent gérer 10 000 QPS, et l'évolutivité horizontale de la base de données est également très simple.

Parfois, face à des applications comportant un grand nombre d'opérations d'écriture, les performances d'écriture d'une seule unité ne peuvent pas répondre aux exigences de l'entreprise. Si vous disposez de deux maîtres, vous rencontrerez des incohérences dans les données de la base de données. La raison en est que différents utilisateurs de l'application peuvent exploiter deux bases de données et que les opérations de mise à jour simultanées provoqueront des conflits ou des incohérences dans les données des deux bases de données. Lors de l'utilisation d'une seule base de données, MySQL utilise le mécanisme du moteur de stockage, les verrous de table et les verrous de ligne pour garantir l'intégrité des données. Comment résoudre ce problème lors de l'utilisation de plusieurs bases de données principales ? Il existe un ensemble d'outils de gestion de réplication maître-esclave développés sur la base du langage Perl, appelés MySQL-MMM (gestionnaire de réplication maître-maître pour Mysql, gestionnaire de réplication maître-maître Mysql. Le plus grand avantage de cet outil est qu'il ne fournit que). une opération d'écriture de base de données en même temps. Assurer efficacement la cohérence des données.

4.2 Ajouter un cache

Ajouter un système de cache à la base de données, mettre en cache les données chaudes en mémoire, S'il y a des données à demander dans le cache mémoire, les résultats ne seront plus renvoyés dans la base de données pour améliorer les performances de lecture. L'implémentation du cache inclut un cache local et un cache distribué qui met en cache les données dans la mémoire ou les fichiers du serveur local, ce qui est rapide. Distribué peut mettre en cache des données massives et est facile à étendre. Les systèmes de mise en cache distribués grand public incluent Memcached et Redis ont des performances stables Les données sont mises en cache en mémoire. être atteint. Si vous souhaitez la persistance des données, utilisez Redis, les performances ne sont pas inférieures à celles de Memcached.

Processus de travail :

4.3 Sous-bibliothèque

La sous-bibliothèque est basée sur différents entreprises. Les tables sont divisées en différentes bases de données, telles que les bibliothèques Web, bbs, blog et autres. Si le volume d'activité est important, la bibliothèque divisée peut également être utilisée comme architecture maître-esclave pour éviter davantage de pression excessive sur une seule bibliothèque.

4.4 Tables

La quantité de données augmente. Il y a des millions de données dans une certaine table de la base de données, ce qui rend la requête et l'insertion trop longues. est-ce possible ? Et si on résolvait la pression sur un seul compteur ? Vous devez envisager de diviser cette table en plusieurs petites tables pour réduire la pression sur une seule table et améliorer l'efficacité du traitement. Cette méthode est appelée fractionnement de table.

La technologie de fractionnement de tables est gênante. Vous devez modifier les instructions SQL dans le code du programme et créer manuellement d'autres tables. Vous pouvez également utiliser le moteur de stockage de fusion pour implémenter le fractionnement de tables, ce qui est relativement simple. Une fois la table divisée, le programme opère sur une table principale. Cette table principale ne stocke pas de données. Elle n'a que quelques relations entre les sous-tables et comment mettre à jour les données. La table principale répartira la pression sur différentes petites tables. basé sur différentes requêtes, améliorant ainsi la concurrence et les performances d'E/S disque.

Le fractionnement de la table est divisé en fractionnement vertical et fractionnement horizontal :

Fractionnement vertical : divisez la table d'origine avec de nombreux champs en plusieurs tables pour résoudre le problème de largeur de table. Vous pouvez placer les champs rarement utilisés dans une table distincte, vous pouvez placer les champs volumineux dans une table distincte ou vous pouvez placer les champs étroitement liés dans une table.

Partage horizontal : divisez la table d'origine en plusieurs tables. Chaque table a la même structure pour résoudre le problème du grand volume de données dans une seule table.

4.5 Partition

Le partitionnement consiste à diviser les données d'une table en plusieurs blocs. Ces blocs peuvent être sur un disque ou sur des disques différents, après partitionnement. est toujours une table en surface, mais les données sont hachées à plusieurs emplacements. De cette manière, plusieurs disques durs peuvent gérer différentes requêtes en même temps, améliorant ainsi les performances de lecture et d'écriture des E/S disque, et la mise en œuvre est relativement simple. .

Remarque : L'ajout de cache, de sous-bibliothèque, de sous-table et de partition est principalement implémenté par les programmeurs.

5. Maintenance des bases de données

La maintenance des bases de données est le travail principal des ingénieurs d'exploitation et de maintenance ou des administrateurs de base de données, y compris la surveillance des performances, l'analyse des performances, les performances. réglage, sauvegarde et récupération de la base de données, etc.

5.1 Indicateurs clés de l'état de performance

QPS, requêtes par seconde : le nombre de requêtes par seconde, le nombre de requêtes qu'une base de données peut traiter par seconde

TPS, Transactions par seconde : nombre de transactions traitées par seconde

Vérifiez l'état d'exécution via l'affichage de l'état. Il y aura plus de 300 enregistrements d'informations sur l'état. Plusieurs valeurs peuvent vous aider. nous calculons le QPS et le TPS, comme suit :

Uptime : le nombre réel de fois où le serveur a été exécuté, en secondes

Questions : le nombre de requêtes qui ont été envoyées à la base de données

Com_select : Le nombre de requêtes, le nombre réel d'opérations de base de données

Com_insert : Nombre d'insertions

Com_delete : Nombre de suppressions

Com_update : Nombre de mises à jour

Com_commit : Nombre de transactions

Com_rollback : Nombre de rollbacks

Ensuite, voici la méthode de calcul, calculez le QPS en fonction des questions :

mysql> show global status like 'Questions';
mysql> show global status like 'Uptime';

QPS = Questions / Uptime

基于Com_commit和Com_rollback计算出TPS：

mysql> show global status like 'Com_commit';
mysql> show global status like 'Com_rollback';
mysql> show global status like 'Uptime';
TPS = (Com_commit + Com_rollback) / Uptime

另一计算方式：基于Com_select、Com_insert、Com_delete、Com_update计算出QPS

mysql> show global status where Variable_name in('com_select','com_insert','com_delete','com_update');

等待1秒再执行，获取间隔差值，第二次每个变量值减去第一次对应的变量值，就是QPS

TPS计算方法：

mysql> show global status where Variable_name in('com_insert','com_delete','com_update');

计算TPS，就不算查询操作了，计算出插入、删除、更新四个值即可。

经网友对这两个计算方式的测试得出，当数据库中myisam表比较多时，使用Questions计算比较准确。当数据库中innodb表比较多时，则以Com_*计算比较准确。

5.2 开启慢查询日志

MySQL开启慢查询日志，分析出哪条SQL语句比较慢，使用set设置变量，重启服务失效，可以在my.cnf添加参数永久生效。

mysql> set global slow-query-log=on #开启慢查询功能
mysql> set global slow_query_log_file='/var/log/mysql/mysql-slow.log'; #指定慢查询日志文件位置
mysql> set global log_queries_not_using_indexes=on; #记录没有使用索引的查询
mysql> set global long_query_time=1; #只记录处理时间1s以上的慢查询

分析慢查询日志，可以使用MySQL自带的mysqldumpslow工具，分析的日志较为简单。

# mysqldumpslow -t 3 /var/log/mysql/mysql-slow.log #查看最慢的前三个查询

也可以使用percona公司的pt-query-digest工具，日志分析功能全面，可分析slow log、binlog、general log。

分析慢查询日志：pt-query-digest /var/log/mysql/mysql-slow.log

分析binlog日志：mysqlbinlog mysql-bin.000001 >mysql-bin.000001.sql

pt-query-digest –type=binlog mysql-bin.000001.sql

分析普通日志：pt-query-digest –type=genlog localhost.log

5.3 数据库备份

备份数据库是最基本的工作，也是最重要的，否则后果很严重，你懂得！但由于数据库比较大，上百G，往往备份都很耗费时间，所以就该选择一个效率高的备份策略，对于数据量大的数据库，一般都采用增量备份。常用的备份工具有mysqldump、mysqlhotcopy、xtrabackup等，mysqldump比较适用于小的数据库，因为是逻辑备份，所以备份和恢复耗时都比较长。mysqlhotcopy和xtrabackup是物理备份，备份和恢复速度快，不影响数据库服务情况下进行热拷贝，建议使用xtrabackup，支持增量备份。

Xtrabackup备份工具使用博文：http://www.php.cn/

5.4 数据库修复

有时候MySQL服务器突然断电、异常关闭，会导致表损坏，无法读取表数据。这时就可以用到MySQL自带的两个工具进行修复，myisamchk和mysqlcheck。

myisamchk : ne peut réparer que la table myisam, la base de données doit être arrêtée

Paramètres communs :

-f – forcer la réparation, écraser les anciens fichiers temporaires, ne pas utiliser généralement

-r –récupérer le mode de récupération

-q –récupération rapide rapide

-a –analyser la table d'analyse

-o –récupérer en toute sécurité l'ancien mode de récupération si-r ne peut pas être réparé, vous pouvez essayer ce paramètre

-F –fast vérifie uniquement les tables qui ne sont pas fermées normalement

Réparez rapidement la base de données Weibo :

# cd /var/lib /mysql/weibo

# myisamchk -r -q *.MYI

mysqlcheck : les tables myisam et innodb peuvent être utilisées. Il n'est pas nécessaire d'arrêter la base de données. Si vous souhaitez réparer une seule table, vous pouvez l'ajouter après le nom de la base de données, séparé par des espaces

Paramètres communs :

-a –all-databases Vérifiez toutes les bibliothèques

-r –réparer la table de réparation

- c –vérifier la table de vérification, option par défaut

-a –analyser la table d'analyse

-o –optimiser la table d'optimisation

-q – quik vérifie ou répare la table la plus rapidement

-F – vérifie rapidement uniquement les tables qui n'ont pas été fermées normalement

Réparez rapidement la base de données Weibo :

mysqlcheck -r -q -uroot -p123 weibo

5.5 De ​​plus, vérifiez la méthode de performances du processeur et des E/S

# Vérifiez les performances du processeur

#Le paramètre -P sert à afficher le nombre de CPU, TOUS Pour tous, vous pouvez également afficher uniquement les premiers

#Afficher les performances des E/S

#Paramètre -m Il est affiché en unités M, la valeur par défaut est K

#%util : Lorsqu'il atteint 100%, cela signifie que les E/S sont très occupées.

#await : Le temps d'attente de la requête dans la file d'attente affecte directement le temps de lecture.

Limite E/S : IOPS (r/s w/s), généralement autour de 1200. (IOPS, le nombre d'opérations de lecture et d'écriture (E/S) par seconde)

Bande passante d'E/S : en mode de lecture et d'écriture séquentielle, la valeur théorique du disque dur SAS est d'environ 300 M/s, et la valeur théorique du disque dur SSD est d'environ 600 M/s.

Ci-dessus sont quelques-unes des principales solutions d'optimisation que j'ai résumées après avoir utilisé MySQL pendant trois ans. Les capacités sont limitées et certaines ne sont pas complètes, mais elles peuvent essentiellement répondre aux besoins en bases de données des petites et moyennes entreprises. . En raison des limites de la conception originale des bases de données relationnelles, certaines sociétés BAT ont placé des quantités massives de données dans des bases de données relationnelles et ont été incapables d'obtenir de meilleures performances en termes d'interrogation et d'analyse de données massives. Par conséquent, NoSQL est devenu populaire. Les bases de données non relationnelles ont de gros volumes de données et des performances élevées. Elles compensent également certaines lacunes des bases de données relationnelles. Peu à peu, la plupart des entreprises ont stocké certaines bases de données commerciales en NoSQL, telles que MongoDB, HBase, etc. Les systèmes de fichiers distribués sont utilisés pour le stockage de données, tels que HDFS, GFS, etc. Le calcul et l'analyse de données massives utilisent Hadoop, Spark, Storm, etc. Ce sont des technologies de pointe liées à l'exploitation et à la maintenance, et ce sont aussi les principaux objets d'apprentissage en matière de stockage Allez les amis ! Si un blogueur a un meilleur plan d’optimisation, partagez-le.

Ce qui précède est une explication détaillée de l'optimisation de la base de données MySQL. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !