Método 1
Si está utilizando Percona Server o MariaDB (> = 5.2), simplemente puede configurar la variable userstat / userstat_running para habilitar un montón de nuevas tablas INFORMATION_SCHEMA que incluyen una llamada TABLE_STATISTICS que proporciona exactamente esta información.
Por ejemplo:
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 correspondería a lo más escrito en las tablas y ROWS_READ sería lo más leído. También debe consultar INDEX_STATISTICS para encontrar sus índices más y menos utilizados.
Consulte también la documentación de estadísticas de usuario de MariaDB .
Método 2
Si no está usando el servidor Percona, puede usar pt-query-digest para capturar una muestra de sus consultas y luego filtrar solo INSERT / UPDATE / DELETEs. Eso se vería así:
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;
Ahora tiene un archivo /tmp/allqueries.logque contiene todas las consultas ejecutadas en su servidor durante ~ 10 minutos.
A continuación, analícelo con pt-query-digest para obtener la escritura más frecuente en las tablas:
pt-query-digest /tmp/allqueries.log --group-by=distill --filter '$event->{arg} =~ m/^(update|delete|insert)/i' --limit 5 > /tmp/writes.txt
Si examina /tmp/writes.txt, verá una sección cerca de la parte superior que se ve así:
# 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
Aproximadamente, estos son los más escritos en tablas durante la muestra que eligió. Para obtener la mayor cantidad de lectura de las tablas (aproximadamente), puede cambiar el --filterparámetro a --filter '$event->{arg} =~ m/^select/i'y verá una salida similar.
Si solo le interesan las escrituras, puede pasar un registro binario pt-query-digesty obtener resultados similares:
mysqlbinlog mysql-bin.000511 | pt-query-digest --type=binlog --group-by=distill > /tmp/writes.txt
También puede obtener los mismos datos con tcpdump y pt-query-digest --type=tcpdump
Entonces, dicho esto, suponiendo que esté utilizando tablas InnoDB, dudo mucho que vea que se beneficiará mucho el rendimiento al hacer esto. Debido a la forma en que los datos se almacenan en el registro de InnoDB y luego se escriben en el disco, no esperaría mucho o ninguna ganancia de rendimiento al mover tablas individuales de esta manera. Es posible que vea algún beneficio al mover los archivos de registro de InnoDB a un disco separado y más rápido para separar las lecturas / escrituras del registro de las lecturas / escrituras del espacio de tabla, pero incluso eso es cuestionable. Invertir en arreglos RAID rápidos y de alta calidad con un caché respaldado por batería (o mejor aún, SSD) será un mejor uso de sus recursos.
