老师你的这个案例是因为 keys 查询阻塞了 redis，导致请求积压，等 redis 恢复正常后，积压的请求 reids 能处理过来，但 mysql 处理不过来，从而被打满。不知道我理解的对不对。我去做 redis key 删除时，都是用 scan 不断遍历来模糊匹配，避免 keys 这种重操作。 另外，开发一般都有接口超时时间的吧，通常 redis 查询非常快，高于某个阈值不返回，就应该中断请求。 比较喜欢用阿里云的全量 SQL 功能，当告警时，无法确定是慢 SQL 日志中哪个 SQL 造成的时候，我就开启全量 SQL，让它跑着，再次出现问题时，去分析报警这个时间段内哪些 SQL 的 CPU 和 IO 占用较高，很多时候，从慢 SQL 日志中并不能确定引起告警的查询，即使慢日志中的 SQL 是真的慢，而且看起来真的有问题。 思考题 1、从扫描行和返回行以及执行时间来区分，如果扫描行数很多，返回行数无论是多还是少（可能是聚合查询），都说明不了什么问题，但扫描和返回行数都少的情况下，执行时间却很长的语句，更大的可能是被别的线程所影响 2、我们公司用的是阿里云的 RDS MySQL 和 Polardb MySQL，通过阿里云提供的接口，定期将云上的慢 SQL 采集到自己的平台，这样在自己的平台就可以查看一个 sql 在一段时间范围内的耗时时间，如果耗时突然增高，那么一般认为是被影响的 3、实在确定不了，我还是用阿里云的全量 SQL，就分析告警前后那段时间范围内的 CPU 占用和 IO 占用，它还有会话快照，可以用来做参考，目前用起来很爽，查找问题也很方便。