实时跟踪数据库

Question

为了减少停机时间并及早检测数据库速度，我们每秒钟查询一次处理器列表表，如果发现查询速度减慢，我们就会关闭优先级较低的查询并执行其他措施。

SELECT avg(time) FROM INFORMATION_SCHEMA.PROCESSLIST 
WHERE db = 'mydb'
    AND user = 'app_user'
    AND state != ''
    AND info NOT LIKE '%ALTER TABLE%'
    AND info NOT LIKE '%CREATE INDEX%'
    AND info NOT LIKE '%CREATE UNIQUE INDEX%'
    AND info NOT LIKE '%performance_summary%'
    AND info NOT LIKE '%certain_table%'
    AND info NOT LIKE '%certain_other_table%';

然而，我们意识到查询处理列表表本身是相当昂贵的，并且正在寻找替代方案。我们已经尝试过performance_schema.threads，但发现它所报告的数字并不准确，而且它显示的数字很低，即使我们有明显的数据库问题。

SELECT AVG(PROCESSLIST_TIME) FROM performance_schema.threads

另一种选择是让我们的应用程序跟踪平均时间，但不知道是否可能有另一种特定于数据库的解决方案。

编辑:为了澄清，上面的查询是实时运行的，不需要人工干预。如果应用程序检测到性能下降，它会立即关闭其他查询，以尝试恢复整体性能。一切都是自动化的。

授予进程列表包含许多空闲查询，但是这个系统已经为我们工作了好几个月了，我们只是尝试实现一个“磁盘上没有临时表”的解决方案。

Answer 1

不确定性原理你所描述的监控很可能会使事情变得更糟。我建议不要那样做。

PROCESSLIST通常显示

• 很多睡眠任务，这些都可以忽略
• 一些‘系统’任务；忽略
• 也许有一项任务在Time中有几秒钟的时间，请考虑查看它
• 大量的“相似”(相同的查询和不同的常量)；查看该类型
• “‘nothing”--这是一些锁挂东西的地方，以至于无法显示Processlist --这里没有什么可做的

注意，但是，每秒钟获取处理列表没有好处。每隔10秒就可以了。(减少侵略性。)想一想你需要多长时间来分析输出并对其做出反应。可能更像是60秒。那么，为什么SHOW比这更频繁呢？

我最喜欢的工具是慢速日志。它将确定哪些查询“类型”是系统上最大的负担--无论查询是不频繁但运行时间较长的查询，还是经常运行的快速查询。这是缓慢日志的一大好处。

它并不是很有侵略性；我一直把它打开，甚至是在生产系统上。(不过，我对使用long_query_time = 0持谨慎态度，因为这将记录所有查询。1或0.5的值是一个合理的折衷方案。)

直到查询完成后，才会将Slowlog条目添加到文件(或表)。这是相对于SHOW PROCESSLIST的一个缺点。

使用pt-query-digest或mysqldumpslow -s t按“系统负担”的顺序转储慢速日志。通常，前1项占系统负载的一半。有时负载来自每天的转储。

大多数工具(Processlist的“时间”；慢速日志的“查询时间”)衡量的是“经过的”时间，而不是"CPU“或"I/O”。虽然这似乎是一个缺陷，但它并不是真的坏。

• 用户看到“延迟”，这是“经过”。
• CPU很少被重载；当它重载时，一个更好的(可能是复合的)索引通常是一种治愈方法。
• 长CPU或I/O会导致长时间的消耗。因此，“经过”是一个很好的追赶。

另一个可能的提示-- MariaDB

• max_statement_time
• LIMIT ROWS EXAMINED (a la LIMIT)
• 和更多的好东西：https://mariadb.com/kb/en/query-limits-and-timeouts/

Answer 2

有些产品正是这样做的。JetProfiler (即使是免费版本也会有帮助)，Percona，可能还有其他工具。

完全披露:我现在在维护JetProfiler的公司工作。但在此之前，我曾多年使用JetProfiler作为工具，在作为顾问工作时清除写得不好的db代码，因此我个人认为它是一个很好的工具。

(在此之前，我工作了很多年-主要是做节目PROCESSLIST和描述--直到我终于真正开始使用真正的分析工具，这真是天壤之别)。