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.
