只是一些上下文：在我们的旧数据管道系统中，我们运行的是MySQL 5.6。亚马逊上的Aurora或Aurora。我们的旧数据管道的坏处是在数据库服务器上运行了大量繁重的计算，因为我们被设计的手铐：将事务数据库视为数据仓库，我们的后端API直接在我们的旧系统中“捕获”数据库。我们目前正在修补这个旧的数据管道，同时在SnowFlake中重新设计新的数据仓库。
在我们的旧数据管道系统中，数据管道计算是一系列连续的MySQL查询。随着我们的数据在旧数据管道中变得越来越大，现在的问题是计算可能会永远停留在，例如，第3步MySQL查询，而我们正在监控的Amazon CloudWatch / grafana中的所有指标（CPU，数据库）连接，可用内存，网络吞吐量，交换使用，读取延迟，可用存储，写入延迟等）看起来很正常。 MySQL慢查询日志在这里确实没有用，因为我们在数据管道中的每个查询都是非常慢的（因为旧数据管道在数据库服务器上运行了大量繁重的计算，所以运行查询可能需要数小时）。我们通常解决这些问题的方法是“盲目”升级MySQL / Aurora Amazon rds服务，并希望它能解决这个问题。我想知道
（1）MySQL 5.6中推荐的数据库指标是什么。我们应该监控实时监控，或者我们应该监控实时监控为什么查询会永远冻结？喜欢innodb_buffer_pool_size？
（2）是否有任何现有的工具和/或内部方法可以预测我们需要多少硬件资源才能自信地执行查询并知道它会成功？有人可以分享2美分吗？
一想法：由于亚马逊rds有时候有点黑盒子，一种可能的方法是在Amazon EC2实例上与我们的Amazon MySQL 5.6 / Aurora rds生产服务器并行托管我们自己的MySQL服务器，所以我们可以ssh到MySQL服务器并运行许多命令工具，如mytop（https://www.tecmint.com/mysql-performance-monitoring/），以收集更多实时MySQL指标，这可以帮助我们分类问题。从大师那里开2美分。谢谢！
答案 0 :(得分：3)
该链接中提到的任何工具都不需要在数据库服务器本身上运行，并且在这种情况下，如果它们不是＆＃39，则它们的行为应该没有区别。 ;吨。在任何Linux服务器上运行它们，提供相应的--host和--user和--password参数（以他们可能期望的任何形式）。甚至mysqladmin也能远程工作。大多数MySQL命令行工具都有（例如mysql cli，mysqldump，mysqlbinlog，甚至mysqlcheck）。
大多数管理实用程序可以通过在与MySQL服务器本身相同的服务器上运行来获得没有神奇的耦合 - 这是一种常见的误解，但事实上，即使在同一台机器上运行，它们仍然需要制作一个连接到服务器，就像任何其他客户端一样。它们可以在本地连接到unix套接字而不是使用TCP，但它仍然是普通的客户端连接，并且不提供额外的功能。
也可以在您自己的EC2实例上（或在您自己的数据中心中）运行RDS / MySQL或Aurora / MySQL服务器的外部副本。但是，这并不能告诉你很多你可以从RDS指标中学到的东西，特别是考虑到上述情况。 （另请注意，即使副本服务器也使用普通客户端连接获取其复制流，然后返回主服务器。）
避免调整服务器参数的诱惑。在RDS上，大多数默认值都非常清晰，除非您特别准确地知道为什么要调整参数......否则不要这样做。
对于慢查询最可能的解释是：编写的查询写得不好和/或索引设计不佳。
如果你不熟悉EXPLAIN SELECT，那么你需要学习它，活它，爱它。 SQL是声明性的，而不是程序性的。也就是说，SQL告诉服务器你想要什么 - 而不是具体如何获得它内部。例如：SELECT ... FROM x JOIN y告诉服务器将表x和y ON中的行与某个条件匹配，但不告诉服务器是否从x读取然后找到匹配的行在y ...或从y读取并在x中找到匹配的行。最终结果是相同的 - 服务器首先在内部检查哪个表并不重要 - 但是如果查询或索引不允许服务器正确地推断到最佳路径您已经要求的结果，它可以花费无数个小时来进行不必要的努力。
采用极端和过度简化的示例，一个包含数百万行的表和一行包含1行的表。首先阅读小表是有意义的，所以你知道你在大表中尝试加入的值是多少。通过读取大表中的每一行是没有意义的，然后检查小表以查找数百万行中的每一行的匹配。您加入表的顺序可能与实际加入的顺序不同。
EXPLAIN进来的地方。这使您可以检查查询计划 - 内部查询优化程序已达成的策略将以最少的努力得到你需要的答案。这是关系数据库系统神奇的核心 - 根据它对数据的了解，在最佳时间内找到正确的解决方案。 EXPLAIN向您显示访问表的顺序，它们如何连接，使用哪些索引以及每个表中的行数估计值 - 以及这些数字乘以一起，可以估算出解析查询时所涉及的排列数。两个小表，每个有50,000行，在没有适当索引的情况下连接，意味着必须评估两个表之间完全不合理的2,500,000,000个唯一组合;每行必须与每隔一行进行比较。简而言之，如果事实证明你是（不知不觉）要求服务器做的事情，那么你肯定做错了什么。在编写复杂查询时，检查查询计划应该是第二天性，以确保服务器使用合理的策略来解决它。
输出很神秘，但可以使用秘密解码器环。
https://dev.mysql.com/doc/refman/5.7/en/explain.html#explain-execution-plan