mysql - Amazon RDS MySQL/Aurora查询有时会永远挂起。我们可以对指标和方法进行分类并防止其发生的任何2美分？

Question

只是一些上下文：在旧的数据管道系统中，我们运行的是mysql 5.6。或者亚马逊rds上的极光。旧数据管道的坏处是在数据库服务器上运行大量繁重的计算，因为我们被设计的东西束缚住了：将事务数据库视为数据仓库，我们的后端api直接“钓鱼”旧系统中的数据库。我们目前正在修补这个旧的数据管道，同时在雪花中重新设计新的数据仓库。
在我们的旧数据管道系统中，数据管道计算是一系列连续的mysql查询。随着旧数据管道中的数据越来越大，现在的问题是计算可能永远挂在第3步mysql查询上，而我们正在监视amazon cloudwatch/grafana中的所有指标（cpu、数据库连接、可用内存、网络吞吐量、交换使用、读取延迟、可用存储、写入等待时间等）看起来很正常。mysql慢速查询日志在这里并不是很有用，因为数据管道中的每个查询实际上都很慢（运行查询可能需要几个小时，因为旧数据管道在数据库服务器上运行大量繁重的计算）。我们通常解决这些问题的方法是“盲目”升级mysql/aurora amazon rds服务，希望它能解决问题。我想知道
（1）mysql 5.6推荐的数据库指标是什么？或者在amazon rds上使用aurora，我们应该实时监控以帮助我们确定为什么查询永远冻结？比如innodb_buffer_pool_size？
（2）有任何现有的工具和/或内部的方法，我们可以预测我们需要多少硬件资源，然后我们可以自信地执行一个查询，并知道它会成功吗？有人能分享2美分吗？
一种想法：由于amazon rds有时有点黑，一种可能的方法是在amazon ec2实例上托管我们自己的mysql服务器，与我们的amazon mysql 5.6/aurora rds生产服务器并行，因此，我们可以ssh到mysql服务器并运行许多命令工具，比如mytop（https://www.tecmint.com/mysql-performance-monitoring/）来收集更多的实时mysql度量，这可以帮助我们解决问题。向任何2美分的古鲁开放。谢谢您！

Answer 1

该链接中提到的任何工具都不需要在数据库服务器本身上运行，如果不是这样，那么它们的行为应该没有区别。在任何Linux服务器上运行它们，并给出适当的--host和--user参数和--password参数（无论它们期望的是什么形式）。即使mysqladmin也可以远程工作。大多数mysql命令行工具都会这样做（例如mysqlcli、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中找到匹配的行。无论哪种方式，最终的结果都是一样的——服务器首先在内部检查哪一个表并不重要——但是如果查询或索引不允许服务器正确地推断到您所请求的结果的最佳路径，那么它可能会花费无数个小时来完成不必要的工作。
以一个极端而过度简化的例子为例，一个有数百万行的表和一个有一行的表。首先读取小表是有意义的，这样您就知道要将哪个1值加入到大表中。读取大表中的每一行，然后检查小表中数百万行的每一行是否匹配是没有意义的。联接表的顺序可以不同于实际联接的顺序。
这就是x的来源。这允许您检查查询计划——内部查询优化器得出的策略将以最少的工作量获得您需要的答案。这是关系数据库系统魔力的核心——根据对数据的了解，在最佳时间内找到正确的解决方案。EXPLAIN向您显示访问表的顺序、如何联接表、使用哪些索引以及每个表中所涉及的行数的估计值，这些数字相乘起来，可以估计解析查询时所涉及的排列数。两个小表，每个表有50000行，在没有适当索引的情况下连接，意味着必须计算的两个表之间完全不合理的2500000000个唯一组合；每一行必须与每一行进行比较。简而言之，如果这是您（不知不觉）要求服务器做的事情，那么您肯定是做错了什么。在编写复杂查询时，检查查询计划应该是第二种性质，以确保服务器使用合理的策略来解决它。
输出是神秘的，但秘密解码器环是可用的。
https://dev.mysql.com/doc/refman/5.7/en/explain.html#explain-execution-plan