我们一直使用的是阿里云 RDS，不仅拥有完备的监控机制、备份机制，还能随时扩容、添加只读节点等。
就在昨天晚上，我收到了数据库连接数超过 80% 的报警信息，因为接近下班时间，没有过多理睬。到晚上八九点钟的时候突然收到更多的报警短信，主要是来源于子项目的负载均衡健康检查报警，马上想起是否是数据库引起的问题，但是通过阿里云网页端已经没法登录了（因为数据库已经是 too many connections），我想阿里云应该提供一种应急机制，平时保留一条网页登录的连接通道，能够让用户在紧急情况下登录检查数据库的情况，否则看不到是哪个项目引起的，无从下手。
还好，想到了一个办法，暂停了部分服务的部分节点（我们的每个服务都是通过负载均衡提供服务，所以暂停部分节点也不会引起问题），这样腾出了数据库空间，让网页端能够及时登录查看具体问题。登录上去之后，通过命令了解到是某个底层系统的用户的连接数已经达到整个系统的 30% 了（因为使用的是PHP，没有像 Java 那样控制整个项目的连接数量），再查看一下具体的执行语句，发现都在执行一个更新命令，心里明白这里肯定有问题。
刚好阿里云提供了慢查询的日志报告，查看之后就明白了，是这个底层系统的更新语句没有建立完整的索引，导致更新数据时阻塞了数据库。请示领导之后，得到的回复是，现在大量语句等待执行，强行建立索引的话，可能会引起更加严重的问题，只有等凌晨高峰期过后再处理。
等凌晨两三点过后，连接数开始回落，这个时候方能建立索引。 今天晚上看下效果，期望不要再出现这种问题了。
总结的问题，
- 没有及时关注数据库的报警短信，毕竟这是整个系统的核心组件，关乎所有项目的健康状况，以后的话会对这类短信保持警惕。
- 平时没有注意阿里云给出的一些慢日志建议，抱着一颗能不动就不能的心态，当问题真正出现的时候，解决起来就非常棘手了，以后多注意阿里云提供的一些性能报告、建议。