Mysql est une base que l’on trouve souvent derrière de nombreux outils web (par exemple wordpress…). Elle s’est généralisée avec la montée en puissance de WAMP ou LAMP. Mais souvent les moteurs et les bases installés sont installés avec des valeurs par défaut sans optimisation. C’est pourquoi, de temps en temps, il est nécessaire de faire des optimisations (défragmentation de base…).
Dans ce genre de travail d’optimisation de bases, on cherche des outils qui permettront de faire une partie du travail à notre place. Et c’est là que vous trouverez votre bonheur avec le binaire intitulé mysqltuner.
Il est facile à installer et comme vous le verez ci-dessous son rapport est plutôt bien fichu. tout cela en perl donc on aime bien.
Pour l’installer rien de plus simple :
sudo apt-get install mysqltuner
Et après on le lance simplement :
└─ $ ▶ mysqltuner
>> MySQLTuner 1.3.0 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: ------
Please enter your MySQL administrative password:
[OK] Currently running supported MySQL version 5.5.60-0+deb8u1
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 714M (Tables: 400)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 496K (Tables: 4)
[--] Data in InnoDB tables: 55M (Tables: 14)
[!!] Total fragmented tables: 28
-------- Security Recommendations -------------------------------------------
[!!] User 'rundeck@%' has no password set.
-------- Performance Metrics -------------------------------------------------
[--] Up for: 18d 0h 10m 24s (136M q [87.417 qps], 261K conn, TX: 113B, RX: 23B)
[--] Reads / Writes: 80% / 20%
[--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 597.8M (15% of installed RAM)
[OK] Slow queries: 0% (81/136M)
[OK] Highest usage of available connections: 19% (29/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/266.3M
[OK] Key buffer hit rate: 99.5% (362M cached / 1M reads)
[OK] Query cache efficiency: 94.4% (123M cached / 131M selects)
[!!] Query cache prunes per day: 258354
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 508K sorts)
[!!] Temporary tables created on disk: 35% (1M on disk / 3M total)
[OK] Thread cache hit rate: 99% (1K created / 261K connections)
[!!] Table cache hit rate: 0% (400 open / 393K opened)
[OK] Open file limit used: 73% (756/1K)
[OK] Table locks acquired immediately: 99% (9M immediate / 9M locks)
[OK] InnoDB buffer pool / data size: 128.0M/55.5M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
Variables to adjust:
query_cache_size (> 16M)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
table_open_cache (> 400)
Vous avez donc une liste de recommandations qui vous permettront d’atteindre votre but pour optimiser votre moteur et votre base :
- faire un OPTIMIZE TABLE
- activé le slow query
- ajuster des variables de configuration : tmp_table_size…
- réduire les volume de “SELECT DISTINCT” en utilisant la clause “LIMIT”
- …
Les choses sont donc relativement bien formulées. Je pense que nous aurons l’occasion de revenir en détail sur certaines de ces actions et de leurs effets.
De votre côté utilisez vous ce genre d’outils ?