前言: 在广州这座城市下着小雨的晚上，我正在厨房洗着碗，突然手机有来电，脱下手套，一看是来自阿里云的告警电话。打开飞书查看告警内容，发现某个业务的RDS只读实例CPU飚到100%，下意识觉得是不是有慢查询导致，想着不会有啥问题，上去kill慢查就好了，结果发现是大问题....
一、发现问题

  2024年3月10号 21:22分左右，手机响起来自阿里云的告警通知，确定了是阿里云RDS报警,MySQL有一波连接数进来，数据库CPU瞬间100%，MySQL连接数也触发告警，10分钟不到有35000多条慢日志，同时阿里云只读库进行了实例主备切换（故障切换）
问题影响了线上用户登录和充值，当时工作群运营反馈问题，技术这边也关注起来。

二、分析造成原因

业务运行的RDS是1主4只读的架构，然后开启数据库代理，读写分离。
一开始以为是管理后台有人在查数据，全表扫描或者查看日期时间范围很长导致只读库有慢查，因为之前出现过这种情况，结果看到控制台几万条慢查询。影响我判断的告警来了，只读实例出现故障进行主备切换，以为是实例出现问题，我立马去找阿里云客服问实例是否有问题，为什么会主备切换了。结果技术客服回答，是因为有一波连接数进来，慢查里面执行SQL有扫描行数很大的可以看看。然后就发现了下面这个关键语句,执行1127次，每次扫描3789828行导致CPU涨到100%，

SELECT *
FROM `table_info`
WHERE user_name = '　　      　              　'
        AND game_xxxx = '123abc'
        AND platform = 'xxxpay'
LIMIT 1 

于是立马反馈给该业务的开发，复制粘贴到群里，开发说user_name是空的，开发也很快修改代码发布到线上，本以为就要结束了，结果还是有这样的SQL进来，这就神奇了....然后怀疑user_name不是空的，会不会是空格，结果我复制出来到文本编辑器，因为开了符号显示，发现user_name的值是空+空格，真想大白了，太可恶了。

 三、解决办法

开发同事修改代码，正则匹配过滤，业务恢复

四、个人反思

1、遇到类似问题，细心按照流程思路找问题，不要急
2、第一时间先把阿里云告警临时关闭，不然一直打电话影响排错
3、查看告警的只读活跃会话，如果有执行特别长时间的SQL，立马kill别影响业务。
4、如果慢查特别多，先对扫描行字段进行排序，找出扫描行特别多的SQL再分析
5、事后总结，做好记录，处理事故同时也得到积累和进步