从查询使用情况和查询类型频率测量MySQL“负载”
作者：互联网
我有很多表的mysql数据库.该数据库为网站提供了越来越多的流量.
我已经设计了数据库和查询,以有意避免会造成性能瓶颈的联接,以便在特定表负载过多的情况下,可以根据需要将表拆分到单独的服务器上(以后,我可以将单个表分片如所须).
我的问题是：给定我拥有的表数量,有没有一种简单的方法来检测哪个表和查询接收的“负载”最多：我特别想知道具有高读写使用率的表.
除了查看我的代码和日志外,我还想通过某种方法来确定应将哪些表移至其他服务器以分发请求和管理资源.我通常使用“负载”一词,这也许是我不正确的？
解决方法:
这正是Percona Toolkit所针对的(在许多其他事情中).具体来说,pt-query-digest(Link)-您可以将其用于大量实用程序,从慢速查询到检测SQL注入.
在这种情况下,可以将pt-query-digest与通过设置long_query_time = 0将long_query_time设置为将所有查询记录到slow_query_log文件的一般策略一起使用.现在,所有查询都记录到慢速查询文件中(请确保将时间重置为上一个值).
mysql> SELECT @@GLOBAL.slow_query_log_file;
+------------------------------------------+
| @@GLOBAL.slow_query_log_file |
+------------------------------------------+
| /var/lib/ubuntu/mysql/slowquery.log |
+------------------------------------------+
1 row in set (0.00 sec)
mysql> SET GLOBAL slow_query_log_file='/tmp/sniffed_queries.log';
mysql> SET GLOBAL long_query_time = 0;
mysql> FLUSH LOGS; #Clear the logs
因此,现在您可以方便地在服务器上运行所有查询的日志,而不会打乱您的常规日志或其他表,可以使用pt-query-digest进行分析：
pt-query-digest /tmp/sniffed_queries.log
对于初学者来说,将会产生非常有用的巨大输出：
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18岁
19
20
21
22
23
24
# Profile
# Rank Query ID Response time Calls R/Call Apdx V/M Item
# ==== ================== ============= ===== ====== ==== ===== ==========
# 1 0x92F3B1B361FB0E5B 4.0522 50.0% 312 0.0130 1.00 0.00 SELECT wp_options
# 2 0xE71D28F50D128F0F 0.8312 10.3% 6412 0.0001 1.00 0.00 SELECT poller_output poller_item
# 3 0x211901BF2E1C351E 0.6811 8.4% 6416 0.0001 1.00 0.00 SELECT poller_time
# 4 0xA766EE8F7AB39063 0.2805 3.5% 149 0.0019 1.00 0.00 SELECT wp_terms wp_term_taxonomy wp_term_relationships
# 5 0xA3EEB63EFBA42E9B 0.1999 2.5% 51 0.0039 1.00 0.00 SELECT UNION wp_pp_daily_summary wp_pp_hourly_summary wp_pp_hits wp_posts
# 6 0x94350EA2AB8AAC34 0.1956 2.4% 89 0.0022 1.00 0.01 UPDATE wp_options
# 7 0x7AEDF19FDD3A33F1 0.1381 1.7% 909 0.0002 1.00 0.00 SELECT wp_options
# 8 0x4C16888631FD8EDB 0.1160 1.4% 5 0.0232 1.00 0.00 SELECT film
# 9 0xCFC0642B5BBD9AC7 0.0987 1.2% 50 0.0020 1.00 0.01 SELECT UNION wp_pp_daily_summary wp_pp_hourly_summary wp_pp_hits
# 10 0x88BA308B9C0EB583 0.0905 1.1% 4 0.0226 1.00 0.01 SELECT poller_item
# 11 0xD0A520C9DB2D6AC7 0.0850 1.0% 125 0.0007 1.00 0.00 SELECT wp_links wp_term_relationships wp_term_taxonomy
# 12 0x30DA85C940E0D491 0.0835 1.0% 542 0.0002 1.00 0.00 SELECT wp_posts
# 13 0x8A52FE35D340A347 0.0767 0.9% 4 0.0192 1.00 0.00 TRUNCATE TABLE poller_time
# 14 0x3E84BF7C0C2A3005 0.0624 0.8% 272 0.0002 1.00 0.00 SELECT wp_postmeta
# 15 0xA01053DA94ED829E 0.0567 0.7% 213 0.0003 1.00 0.00 SELECT data_template_rrd data_input_fields
# 16 0xBE797E1DD5E4222F 0.0524 0.6% 79 0.0007 1.00 0.00 SELECT wp_posts
# 17 0xF8EC4434E0061E89 0.0475 0.6% 62 0.0008 1.00 0.00 SELECT wp_terms wp_term_taxonomy
# 18 0xCDFFAD848B0C1D52 0.0465 0.6% 9 0.0052 1.00 0.01 SELECT wp_posts wp_term_relationships
# 19 0x5DE709416871BF99 0.0454 0.6% 260 0.0002 1.00 0.00 DELETE poller_output
# 20 0x428A588445FE580B 0.0449 0.6% 260 0.0002 1.00 0.00 INSERT poller_output
# MISC 0xMISC 0.8137 10.0% 3853 0.0002 NS 0.0
<147 ITEMS>
从此示例中,您可以看到SELECT … FROM wp_options调用的R / Call造成了最大的负担.还有大量其他信息.我强烈建议您尽早使用percona-toolkit,而且如果您要坚持使用mysql,通常会经常使用-我将它们推迟了很长时间,但由于他们本来可以避免的头痛,我仍然踢自己.
Percona在这方面有一篇很棒的文章,这是针对他们的Percona Server MySQL构建的,虽然很棒,但仍应适用：Identifying the load with the help of pt-query-digest and Percona Server
标签：database-performance,mysql,database 来源： https://codeday.me/bug/20191123/2064294.html