我试图提高服务器的性能，很显然MySQL是这个问题的主要贡献者。 但是，排除故障非常困难。 我正在使用慢查询日志来定位特定types的查询，但真正的问题在于Java进程，PHP进程和cron作业（通常也是PHP进程，但通过命令行运行Apache ）
通常当服务器变慢的时候，我会运行一些像“ps”或“top”这样的命令来试图find罪魁祸首，但是即使我知道MySQL是怪罪，我也不知道这三个“领域”中的哪一个上述可能实际上是造成放缓。 换句话说，我希望以某种方式将其分解，例如，当时对MySQL的要求中有80％是来自PHP的查询，而只有20％来自Java。 由于我有两个“领域”触发的自动化任务和周期性事件，所以很难通过反复试验来隔离它们的影响。
一切都驻留在一台服务器上，所以所有的MySQL查询都来自本地主机。 我是否也可能“标记”查询，向他们添加注释，或者添加某种元数据，以便稍后分析这些标记以获取相对负载？
我怀疑有一种方法可以像这样获得信息，但是如果任何人都可以帮助提供一种方式来进一步细分MySQL负载，以帮助识别这些查询的来源（进程ID也可以工作），这将非常有帮助。 谢谢！
我build议使用MySQL代理 。 使用MySQL代理，您可以拦截并logging每个进入服务器的查询。
更简单的方法是运行mysqlbinlog来分析由MySQL生成的二进制日志文件（参见man mysqlbinlog ）。
无论如何，如果你还没有这样做，最好是运行mysqltuner来查看是否有任何明显的问题或瓶颈（例如，不寻常的数量的查询执行没有索引的JOIN）。
您是否尝试login到MySQL服务并发出一个SHOW FULL PROCESSLIST或使用mytop查看哪些查询正在运行？
SHOW FULL PROCESSLIST提供了MySQL正在执行的所有查询和任务的列表。 它需要在数据库中以“PROCESS”或“SUPER”的优先级运行。 mysqladmin也有一个processlist参数。
mytop非常适合显示服务器正在进行的工作。 把它看成是MySQL的顶端。
这两个命令都会告诉你哪些命令正在运行，它们来自哪里以及MySQL到目前为止试图维护多长时间。
一旦你掌握了这些信息，你就可以决定做什么。 如果系统是写入绑定的，则可能需要对数据进行分区。 如果你是阅读的，有些东西可以帮助你。 在许多情况下，正确索引表可以显着提升读取性能。 如果你有很多相同的查询，添加一个caching可能会有所帮助。 添加读取从属也可以提高性能。 caching和添加从站将会提高性能，但会为networking和应用程序增加一些额外的复杂性。
一种可能是确保不同的进程使用不同的凭证连接到MySQL。 我很确定mysql会在查询日志中logging执行查询的用户名。
是的你可以，但是不使用基于客户端的分析器进行分析需要你通过可以捕获它们的东西传递请求 – 在这种情况下，这将是MySql-Proxy 。 在他们的网站上有关于如何将其设置为阻碍和configuration文件查询的说明，然后您可以运行说明和其他操作，似乎花费很长时间。
另一种不那么复杂，但可能工作的方法是将慢查询超时设置为一个非常低的值，然后确保您打开慢查询日志。 这样你会看到任何需要超过几秒钟的东西。 如果开发人员（或他们的ORM）做了一堆基本的查询，然后总结应用程序中的数据，这不会对您有所帮助。
显示完整的进程列表;
这向您展示了stream程和运行时间。 为了区分来源，您可以为每个“领域”使用不同的login名，或者在所有查询中预先设置领域。 例如，这是一个有效的查询：
/ * php * / SELECT * FROM items;
原因如下：
/ * java * / SELECT * FROM items;
等等
但是您仍然无法看到由查询造成的系统负载。 无论如何，这可能会有所帮助，而且您可能会破解您的监视工具来绘制数据图表，以查找与您的性能之间的相关性。
Maatkit的mk-query-digest脚本不会按来源进行分类，但它会让你很清楚哪些查询是占用资源最多的。
我们用注释来标记查询，就像上面提到的那样。 然后，我们定期将FULL PROCESSLIST输出写入文件。 当我们遇到性能问题时，我们将这些文件导入到数据库中并查找数据以查看长查询。 至less对我们来说，这些负担最重。
我会小心在生产系统上运行MySQL代理。 我发现它偶尔会locking。 另外，您还需要进一步监视基础设施。
你有没有考虑使用mysql分析？
http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html
mysql>set profiling=1; <run your queries with profiling enabled> mysql>show profiles;
这个输出将是一个QueryID，查询持续时间和查询string的表。 与此类似：
mysql> show profiles; +----------+------------+-----------------------------------------------+ | Query_ID | Duration | Query | +----------+------------+-----------------------------------------------+ | 0 | 0.00007300 | set profiling=1 | | 1 | 0.00044700 | select count(*) from client where broker_id=2 | +----------+------------+-----------------------------------------------+
从这里，你可以进一步打破这个查询
mysql>show profile for query <QueryID>;
这会给你一个查询花费在每个执行阶段多less时间的细分。 您可以进一步深入了解在查询上花费了多lessCPU时间的具体细节：
mysql> show profile cpu for query 4; +----------------------+------------+------------+------------+ | Status | Duration | CPU_user | CPU_system | +----------------------+------------+------------+------------+ | (initialization) | 0.00002900 | 0.00000000 | 0.00000000 | | checking permissions | 0.00000800 | 0.00000000 | 0.00000000 | | init | 0.00004000 | 0.00000000 | 0.00000000 | | Opening table | 0.00009400 | 0.00100000 | 0.00000000 | | System lock | 0.00000500 | 0.00000000 | 0.00000000 | | Table lock | 0.00000700 | 0.00000000 | 0.00000000 | | setup | 0.00004200 | 0.00000000 | 0.00000000 | | creating table | 0.00195800 | 0.00000000 | 0.00100000 | | After create | 0.00010900 | 0.00000000 | 0.00000000 | | copy to tmp table | 0.52264500 | 0.55591600 | 0.04199300 | | rename result table | 0.11289400 | 0.00199900 | 0.00000000 | | end | 0.00004600 | 0.00000000 | 0.00000000 | | query end | 0.00000700 | 0.00000000 | 0.00000000 | | freeing items | 0.00001300 | 0.00000000 | 0.00000000 | +----------------------+------------+------------+------------+
我build议阅读信息页面，找出你想要的信息，因为这个工具相当详细，但是这应该可以帮助你findmysql守护进程中的瓶颈。
第一步是不要让你的所有进程使用同一个用户。 特别是如果他们都通过“本地主机”来。 即使对于来自相同工具的查询（如在php中），让cron中的用户使用通过apache运行的独立用户。
一旦完成，你可以使用mysqlbinlog来parsing慢日志（它有一些很好的字段来sorting查询/标准化查询），甚至可以使用更高级的分析器来查找较慢的查询