Der folgende Editor bringt Ihnen einen Artikel über die Wertmethode innodb_flush_method (Erklärung mit Beispielen). Der Herausgeber findet es ziemlich gut, deshalb werde ich es jetzt mit Ihnen teilen und es allen als Referenz geben. Folgen wir dem Editor, um einen Blick darauf zu werfen
Mehrere typische Werte von 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.
So erhalten Sie den Wert, MySQLDas offizielle Dokument empfiehlt dies
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
Das Der spezifische Wert hängt von der Hardwarekonfiguration und der Arbeitslast ab. Um dies zu ermitteln, führen Sie am besten einen Stresstest durch. Aber im Allgemeinen ist o_direct in einer Linux-Umgebung mit Raid Controller und Write-Back-Write-Strategie die bessere Wahl, wenn das Speichermedium SAN ist, dann ist es möglicherweise besser, den Standard-fsync oder osync zu verwenden.
Im Allgemeinen scheinen die meisten Leute den Wert o_direct festzulegen, es gibt eine Raid-Karte auf der unteren Ebene und die Lese- und Schreibrichtlinie ist auf Zurückschreiben eingestellt. Bei der Verwendung von sysbench zum Stresstest des oltp-Typs habe ich festgestellt, dass die Leistung von o_direct tatsächlich für die meisten Szenarien geeignet ist. Allerdings bin ich kürzlich auf ein solches SQL gestoßen, und das Feedback der Kunden war sehr langsam Bei gleichem Speicher war die Leistung des von mir selbst erstellten Cloud-Hosts viel schneller. Später stellte ich fest, dass der Hauptgrund der große Leistungsunterschied war, der durch die unterschiedlichen Einstellungswerte von innodb_flush_method verursacht wurde.
Testszenario 1
innodb_flush_method ist der Standardwert, nämlich fsync, Cache Pool 512M, Tabellendatenvolumen 1,2G, ohne die Auswirkungen des Cache-Pools, stabile Ergebnisse
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)
Testszenario 2
innodb_flush_method Wechsel zu o_direct, Ausschluss der Auswirkungen des Cache-Pools, stabile Ergebnisse
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)
Ergebnisvergleich:
Die Ausführungspläne der beiden sind genau gleich, aber die Leistung ist sehr unterschiedlich. In der Datenbank sind die Ergebnisse der Abfrage beim ersten Start ebenfalls sehr unterschiedlich, und auch o_direct ist sehr unterschiedlich (Test Ergebnisse weggelassen). Ich verstehe nicht ganz, warum in diesem Fall mit einer zusätzlichen Schicht des Betriebssystems die Leseeffizienz viel höher ist. Die Einstellungen der Produktionsumgebung müssen auf dem Stresstest basieren Tatsächlich wird die Wirkung überwiegen und man kann nicht blind auf den Erfahrungswert vertrauen.
Verbesserungsmaßnahmen:
Ohne Änderung der innodb_flush_method kann dieses SQL tatsächlich weiter optimiert werden, indem ein kombinierter Index hinzugefügt wird account_id,outcome,income), sodass die Abdeckung des Index-Scans die Antwortzeit erheblich verkürzen kann
[Verwandte Empfehlungen]
1. Kostenloses MySQL-Video-Tutorial
2. Detaillierte Beispiele zum Hinzufügen neuer Benutzerberechtigungen in MySQL
3 Detaillierte Beispiele zum Ändern von Passwörtern und Zugriffsbeschränkungen in MySQL
5. Detaillierte Erläuterung von Beispielen für die PHP-Speicherung von Bildern in MySQL
Das obige ist der detaillierte Inhalt vonDetailliertes Beispiel der Methode innodb_flush_method in MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
