MySQL lit / écrit par table


8

J'optimise notre DB. Essentiellement, j'essaie de trouver les tableaux les plus écrits et les plus lus dans notre base de données. Après cela, je suivrai en liant ces tables en plusieurs disques séparés.

Existe-t-il un moyen de suivre l'activité de chaque table? Comme dans IOPS de suivi, écrit, lit par table?

Réponses:


10

Méthode 1

Si vous utilisez Percona Server ou MariaDB (> = 5.2), vous pouvez simplement définir la variable userstat / userstat_running pour activer un tas de nouvelles tables INFORMATION_SCHEMA, dont une appelée TABLE_STATISTICS qui fournit exactement ces informations.

Par exemple:

mysql> SELECT TABLE_NAME, ROWS_READ, ROWS_CHANGED, ROWS_CHANGED_X_INDEXES FROM TABLE_STATISTICS ORDER BY ROWS_CHANGED DESC LIMIT 5;
+-------------------+------------+--------------+------------------------+
| TABLE_NAME        | ROWS_READ  | ROWS_CHANGED | ROWS_CHANGED_X_INDEXES |
+-------------------+------------+--------------+------------------------+
| user              |   21122527 |      5989231 |               23956924 |
| audit             |       1208 |      5020929 |               20083716 |
| sometemp          |   13995426 |      3182150 |                9546450 |
| creditcards       |    3566482 |      2998976 |               11995904 |
| order             | 2147483647 |      2662606 |               53252120 |
+-------------------+------------+--------------+------------------------+

ROWS_CHANGED correspondrait au plus écrit dans les tables et ROWS_READ serait le plus lu. Vous devriez également consulter INDEX_STATISTICS pour trouver vos index les plus et les moins utilisés.

Voir aussi la documentation des statistiques utilisateur MariaDB .

Méthode 2

Si vous n'utilisez pas Percona Server, vous pouvez utiliser pt-query-digest pour capturer un échantillon de vos requêtes, puis filtrer uniquement INSERT / UPDATE / DELETEs. Cela ressemblerait à quelque chose comme ceci:

mysql> SELECT @@GLOBAL.slow_query_log_file;
+------------------------------------------+
| @@GLOBAL.slow_query_log_file             |
+------------------------------------------+
| /var/logs/mysql/slowquery.log            |
+------------------------------------------+
1 row in set (0.00 sec)
mysql> SET GLOBAL slow_query_log_file='/tmp/allqueries.log';
mysql> SELECT @@GLOBAL.long_query_time;
+--------------------------+
| @@GLOBAL.long_query_time |
+--------------------------+
|                 0.250000 |
+--------------------------+
1 row in set (0.00 sec)
mysql> SET GLOBAL long_query_time = 0;
mysql> FLUSH LOGS;
mysql> SLEEP 600; SET GLOBAL long_query_time = 0.25; SET GLOBAL slow_query_log_file='/var/logs/mysql/slowquery.log'; FLUSH LOGS;

Vous disposez maintenant d'un fichier /tmp/allqueries.logcontenant toutes les requêtes exécutées sur votre serveur pendant environ 10 minutes.

Ensuite, analysez-le avec pt-query-digest pour obtenir le plus souvent écrit dans les tables:

pt-query-digest /tmp/allqueries.log --group-by=distill --filter '$event->{arg} =~ m/^(update|delete|insert)/i' --limit 5 > /tmp/writes.txt

Si vous examinez /tmp/writes.txt, vous verrez une section près du haut qui ressemble à ceci:

# Profile
# Rank Query ID Response time Calls R/Call Apdx V/M   Item
# ==== ======== ============= ===== ====== ==== ===== ====================
#    1 0x        0.0558 26.8%   282 0.0002 1.00  0.00 INSERT UPDATE user
#    2 0x        0.0448 21.5%   246 0.0002 1.00  0.00 UPDATE audit
#    3 0x        0.0228 10.9%    11 0.0021 1.00  0.00 UPDATE sometemp
#    4 0x        0.0108  5.2%    16 0.0007 1.00  0.00 UPDATE creditcards
#    5 0x        0.0103  4.9%    43 0.0002 1.00  0.00 UPDATE order

En gros, ce sont vos tableaux les plus écrits pour la durée de l'échantillon que vous avez choisi. Pour tirer le meilleur parti des tableaux (à peu près), vous pouvez modifier le --filterparamètre en --filter '$event->{arg} =~ m/^select/i'et vous verrez une sortie similaire.

Si vous êtes uniquement intéressé par les écritures, vous pouvez passer un journal binaire dans pt-query-digestet obtenir des résultats similaires:

mysqlbinlog mysql-bin.000511 | pt-query-digest --type=binlog --group-by=distill > /tmp/writes.txt

Vous pouvez également obtenir les mêmes données avec tcpdump et pt-query-digest --type=tcpdump

Donc, cela étant dit, en supposant que vous utilisez des tables InnoDB, je doute fortement que vous constaterez de nombreux avantages en termes de performances. En raison de la façon dont les données sont mises en mémoire tampon dans le journal InnoDB puis écrites sur le disque, je ne m'attendrais pas à un gain de performances important ou nul en déplaçant des tables individuelles comme ceci. Vous pouvez voir un certain avantage à déplacer les fichiers journaux InnoDB eux-mêmes sur un disque séparé et plus rapide pour séparer les lectures / écritures du journal des tables lire / écrire, mais même cela est discutable. Investir dans des matrices RAID rapides et de haute qualité avec un cache alimenté par batterie (ou mieux encore, SSD) sera une meilleure utilisation de vos ressources.


cache soutenu par batterie - Pourriez-vous me donner un lien pour approfondir ceux-ci?
Katafalkas

en.wikipedia.org/wiki/RAID serait un bon point de départ. RAID10 est généralement supérieur à RAID5 ou 6 pour les bases de données.
Aaron Brown
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.