Exemple détaillé de la méthode innodb_flush_method dans MySQL

L'éditeur suivant vous apportera un article sur la méthode value innodb_flush_method (explication avec exemples). L'éditeur pense que c'est plutôt bien, alors je vais le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur pour jeter un oeil

Plusieurs valeurs typiques de innodb_flush_method

fsync: InnoDB uses the fsync() system call to flush both the data and log files. fsync is the default setting.

O_DSYNC: InnoDB uses O_SYNC to open and flush the log files, and fsync() to flush the data files. InnoDB does not use O_DSYNC directly because there have been problems with it on many varieties of Unix.

O_DIRECT: InnoDB uses O_DIRECT (or directio() on Solaris) to open the data files, and uses fsync() to flush both the data and log files. This option is available on some GNU/Linux versions,FreeBSD, and Solaris.

Comment obtenir la valeur, mysqlLe document officiel recommande ceci

How each settings affects performance depends on hardware configuration and workload. Benchmark
your particular configuration to decide which setting to use, or whether to keep the default setting.
Examine the Innodb_data_fsyncs status variable to see the overall number of fsync() calls for
each setting. The mix of read and write operations in your workload can affect how a setting performs.
For example, on a system with a hardware RAID controller and battery-backed write cache, O_DIRECT
can help to avoid double buffering between the InnoDB buffer pool and the operating system's file
system cache. On some systems where InnoDB data and log files are located on a SAN, the default
value or O_DSYNC might be faster for a read-heavy workload with mostly SELECT statements. Always
test this parameter with hardware and workload that reflect your production environment

Cela is La valeur spécifique est liée à la configuration matérielle et à la charge de travail. Il est préférable d'effectuer un test de résistance pour déterminer. Mais d'une manière générale, dans un environnement Linux avec un contrôleur raid et une stratégie d'écriture par écriture différée, o_direct est un meilleur choix ; si le support de stockage est SAN, il peut être préférable d'utiliser le fsync ou l'osync par défaut.

De manière générale, il semble que la plupart des gens définissent la valeur o_direct, qu'il y a une carte raid sur la couche inférieure et que la politique de lecture et d'écriture est définie sur la réécriture. Lors de l'utilisation de sysbench pour tester le type oltp, j'ai trouvé que o_direct est en effet meilleur que fsync en termes de performances. Cependant, j'ai récemment rencontré un tel SQL et les commentaires des clients ont été très lents. de la même mémoire, l'hôte cloud que j'ai construit fonctionnait beaucoup plus rapidement. Plus tard, j'ai découvert que la raison principale était l'énorme différence de performances causée par les différentes valeurs de réglage de innodb_flush_method.

Scénario de test 1

innodb_flush_method est la valeur par défaut, qui est fsync, cache pool 512M, volume de données de la table 1.2G, hors impact du pool de cache, les résultats stables

mysql> show variables like '%innodb_flush_me%';
+---------------------+-------+
| Variable_name    | Value |
+---------------------+-------+
| innodb_flush_method |    |
+---------------------+-------+
1 row in set (0.00 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (1.22 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (1.22 sec)
mysql> explain SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| id | select_type | table  | type | possible_keys | key    | key_len | ref  | rows  | Extra         |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| 1 | SIMPLE   | journal | ref | account_id  | account_id | 62   | const | 161638 | Using index condition |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
1 row in set (0.03 sec)

Scénario de test 2

innodb_flush_method Passer à o_direct, exclure l'impact du pool de cache, les résultats stables

mysql> show variables like '%innodb_flush_me%';
+---------------------+----------+
| Variable_name    | Value  |
+---------------------+----------+
| innodb_flush_method | O_DIRECT |
+---------------------+----------+
1 row in set (0.00 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (3.22 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (3.02 sec)


mysql> explain SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| id | select_type | table  | type | possible_keys | key    | key_len | ref  | rows  | Extra         |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| 1 | SIMPLE   | journal | ref | account_id  | account_id | 62   | const | 161638 | Using index condition |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
1 row in set (0.00 sec)

Comparaison des résultats :

Les plans d'exécution des deux sont exactement les mêmes, mais la performance est très différente. Dans la base de données les résultats de la requête lors de son premier démarrage sont également très différents, et o_direct est également très différent (Test résultats omis). Je ne comprends pas très bien pourquoi dans ce cas, avec une couche supplémentaire de cache du système d'exploitation , l'efficacité de lecture est beaucoup plus élevée. Les paramètres de l'environnement de production doivent être basés sur le test de stress. Résultats En réalité, l'effet prévaudra et la valeur de l'expérience ne peut pas être aveuglément fiable.

Mesures d'amélioration :

Sans changer innodb_flush_method, ce SQL peut en fait être optimisé davantage en ajoutant un index ( account_id,outcome, Income), de sorte que l'analyse de l'index puisse réduire considérablement le temps de réponse

[Recommandations associées]

1 Tutoriel vidéo gratuit MySQL

Exemples détaillés d'ajout de nouvelles autorisations utilisateur dans MySQL

Exemples détaillés de modification des mots de passe et des restrictions d'accès dans MySQL

Détails des exemples d'utilisation d'expressions régulières pour remplacer le contenu de la base de données Solution

Explication détaillée d'exemples de stockage d'images php dans MySQL

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!