Phương pháp 1
Nếu bạn đang sử dụng Percona Server hoặc MariaDB (> = 5.2), bạn chỉ cần đặt biến userstat / userstat_rucky để kích hoạt một loạt các bảng Information_SCHema mới, bao gồm một bảng được gọi là TABLE_STATISTICS cung cấp chính xác thông tin này.
Ví dụ:
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 sẽ tương ứng với các bảng được ghi nhiều nhất và ROWS_READ sẽ được đọc nhiều nhất từ đó. Bạn cũng nên xem INDEX_STATISTICS để tìm các chỉ mục được sử dụng nhiều nhất và ít sử dụng nhất.
Xem thêm tài liệu thống kê người dùng MariaDB .
Cách 2
Nếu bạn không sử dụng Percona Server, bạn có thể sử dụng pt-query-digest để lấy một mẫu các truy vấn của mình và sau đó chỉ lọc ra CHERTN / CẬP NHẬT / XÓA. Điều đó sẽ trông giống như thế này:
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;
Bây giờ bạn có một tệp, /tmp/allqueries.log
chứa mọi truy vấn được thực hiện trên máy chủ của bạn trong ~ 10 phút.
Tiếp theo, phân tích nó với pt-query-digest để có được ghi thường xuyên nhất vào các bảng:
pt-query-digest /tmp/allqueries.log --group-by=distill --filter '$event->{arg} =~ m/^(update|delete|insert)/i' --limit 5 > /tmp/writes.txt
Nếu bạn kiểm tra /tmp/writes.txt
, bạn sẽ thấy một phần gần đầu trông như thế này:
# 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
Roughly, đây là hầu hết các bảng của bạn được viết vào bảng trong suốt thời gian của mẫu bạn đã chọn. Để có được nhiều lượt đọc nhất từ các bảng (đại khái), bạn có thể thay đổi --filter
tham số thành --filter '$event->{arg} =~ m/^select/i'
và bạn sẽ thấy đầu ra tương tự.
Nếu bạn chỉ quan tâm đến việc ghi, bạn có thể chuyển nhật ký nhị phân vào pt-query-digest
và nhận kết quả tương tự:
mysqlbinlog mysql-bin.000511 | pt-query-digest --type=binlog --group-by=distill > /tmp/writes.txt
Bạn cũng có thể nhận được cùng một dữ liệu với tcpdump và pt-query-digest --type=tcpdump
Vì vậy, điều này đang được nói, giả sử rằng bạn đang sử dụng các bảng InnoDB, tôi rất nghi ngờ rằng bạn sẽ thấy nhiều lợi ích hiệu suất từ việc này. Do cách dữ liệu được đệm vào nhật ký InnoDB và sau đó được ghi vào đĩa, tôi sẽ không mong đợi nhiều hoặc bất kỳ hiệu suất nào đạt được từ việc di chuyển các bảng riêng lẻ như thế này. Bạn có thể thấy một số lợi ích từ việc tự di chuyển các tệp nhật ký InnoDB sang đĩa riêng, nhanh hơn để tách / đọc / ghi nhật ký khỏi không gian bảng đọc / ghi, nhưng thậm chí đó là nghi vấn. Đầu tư vào mảng RAID nhanh, chất lượng cao với bộ nhớ cache được hỗ trợ bằng pin (hoặc tốt hơn là SSD) sẽ sử dụng tốt hơn các tài nguyên của bạn.