我使用MySQL（Percona ExtraDB 5.1准确）作为我选择的数据库。总体而言，表现令人印象深刻。使用它的应用程序非常大。如何追踪有问题的MySQL查询？
我们相信，一个查询有时会造成线程的备份数据库无论出于何种原因（即，内存/缓存）上。服务器已经无数次的调整，以防止这种情况，所以它现在是1％的问题，但仍然非常烦人。除非您全天候监视数据库服务器，否则您不可能看到备份的原因。
有任何建议（除了通过慢查询日志会），任何人都可以提出来跟踪问题的查询（即通过申请报告）？
带有XtraDB的Percona服务器实际上记录了微秒分辨率的时间戳和执行时间，因此您可以精确地开始和结束查询。但是，日志分析可能是错误的方法。您可能需要使用Aspersa的stem + collect工具。
正如你在你的问题指出，你最好的选择将是慢查询日志：
http://dev.mysql.com/doc/refman/5.5/en/slow-query-log.html
您可能还需要在应用程序级别记录本：
在开始的时候的脚本，记下你要做什么以及什么时候开始。在结束时，如果处理请求的时间高于某个阈值，则记录此信息。
这样一来，你就能够识别查询的问题的序列，而不是单个查询。 （顺便说一句，可能会发现没有个人查询速度慢，但某些请求可能会触发小规模查询的gazillions。）
感谢您的回答。这是我正在考虑的事情。如果缓慢的查询日志实际上让您能够记录查询执行的开始和结束时间，那么您可以更好地了解时间表。 – David 2011-05-27 08:36:15
看一看this script它允许你提取导致问题的查询的一个更抽象的表示。
我通常频率和运行时的产品列表进行排序，以获得导致问题最多的查询。
NB记录查询的实际开始和结束无关测量查询实际上造成锁 - 从手动“以获得初始表锁定的时间不算作执行时间”
你只需要修复缓慢的东西。
你可以显示查询吗？ – 2011-05-27 08:27:42
你是如何调整服务器的？最近我有一个Web应用程序出现性能问题，MySQL Performance Tuning Primer Script（http://www.day32.com/MySQL/）帮助我们很好地解决了瓶颈所在。通过日志记录（你现在在做什么）和优化慢速查询至少可以解决它。 – 2011-05-27 08:34:06