Quand un site ralentit, la base de données est le premier endroit à regarder et le plus difficile à consulter rapidement. Cette page affiche l’uptime, les connexions courantes et maximales, le nombre de requêtes lentes, le comportement du cache et la taille de chaque base — de quoi savoir en quelques secondes si le problème vit ici.
Le rapport entre connexions et maximum configuré est le chiffre qui explique la plupart des pannes. Un serveur qui a atteint sa limite refuse les nouvelles connexions, et l’application signale une erreur de base qui ne dit rien de la cause réelle. Les requêtes lentes sont l’autre extrémité : quelques-unes sont normales, un compteur qui grimpe régulièrement signifie en général qu’une requête a perdu son index lors d’un changement de schéma.
Les tailles figurent ici parce qu’une croissance se traite plus facilement tôt. Une table qui grossit sans limite — sessions, table de journal, file d’attente que personne ne consomme — est un problème lent tant qu’il reste de la place, et un problème urgent à trois heures du matin quand il n’y en a plus. La page disque de ce panneau en montre l’autre face.
Il vaut la peine de savoir ce que cette page voit et ce qu'elle ne voit pas. Elle lit l'état de MySQL de l'intérieur — connexions, requêtes, tailles — mais ne dit rien de ce sur quoi la base repose. Un service arrêté, c'est Monit qui le remarque, et un disque qui commence à lâcher, c'est SMART qui prévient, généralement bien avant que le ralentissement n'apparaisse dans les requêtes. La cause d'une base lente se trouve souvent en dessous de la base elle-même.