从mysqldumpslow理解慢速查询

Question

我正在维护一个系统，它偶尔(没有确切的时间)，但只在夜间导致整个服务器崩溃几秒钟，用户看到“错误连接拒绝”，直到系统恢复自己。

应用服务器正在使用Nginx运行PHP和PHP。

我在数据库服务器上启用了缓慢日志，mysqldumpslow给了我以下输出。

Count: 302  Time=44.50s (13439s)  Lock=0.00s (0s)  Rows=0.0 (0), 4users@2hosts
  #

Count: 44  Time=64.65s (2844s)  Lock=0.00s (0s)  Rows=0.0 (0), 3users@2hosts
  COMMIT

Count: 19  Time=82.44s (1566s)  Lock=0.00s (0s)  Rows=295151.3 (5607875), site-admin[site-admin]@7hosts
  SELECT /*!40001 SQL_NO_CACHE */ * FROM `audits`

关于这个输出，我有几个问题，如果有人能解释这些查询是否会导致应用程序和数据库服务器完全锁定几秒钟，我会很感激。

1. 这些查询是因为查询本身写得不好而运行缓慢，还是在等待另一个查询完成？
2. 似乎正在运行的COMMIT、#和SELECT /*!40001 SQL_NO_CACHE */ * FROM 'audits'查询是什么？
3. 关于最后一个查询，我看到它来自服务器上运行的mysqldump命令。这会不会导致数据库和应用服务器的崩溃呢？

Answer 1

SELECT /*!40001 SQL_NO_CACHE */ * FROM `audits

看起来像是来自mysqldump的查询。增加全局超时--这样它就不会崩溃。

同时，在过去的几个月里，你可能没有任何完整的垃圾场。惊慌！

COMMIT

我很烦人。它说(由于某种原因)事务的完成速度很慢。除了盯着代码看，你做不了什么。寻找其他干扰的交易。

但是..。还要检查那些SELECTs和COMMITs的特定时间。如果它们同时发生，那么备份就会干扰正常的交通。

有几种替代mysqldump的方法，但这不是介绍转储教程的问题。

这是你最后一个问题：

1. mysqldump锁定audits的时间足够长，足以读取和转储整个表。
2. 某个应用程序试图更新该表；它挂起等待访问。
3. 其他应用程序(或同一应用程序的其他副本)也出现了，并陷入了交通堵塞。
4. 最终达到了一些限制(max_connections，the服务器的子进程数量或其他什么)，并且决定通过重新启动来修复自己。

如果表是ENGINE = MyISAM，则切换到InnoDB，这对表访问更加宽容。