业务跑到云上以后，数据库基本是最不能出岔子的那一层。订单、用户、库存，哪一笔数据有问题，用户很快就能感觉到。阿里云的数据库产品线（RDS、PolarDB、Redis 等）用的人多，文档和社区资料也多，但用的人多，碰到问题的机会也跟着多。这篇文章按实际排障的顺序，讲阿里云数据库出问题时先看什么，以及平时怎么少踩坑。
先别急着怪云厂商
数据库报错时，很多人的第一反应是实例是不是坏了。从常见的排查经验看，多数问题落在三类地方：连接配置、慢查询与资源瓶颈，以及备份或变更操作。先把问题归到其中一类，后面的动作会清楚很多。
连不上的时候，先看这几项
“连不上”听起来笼统，其实可以按顺序一项项过：
- 地址和端口对不对。应用和数据库在同一个 VPC 里，应该用内网地址；只有从外部网络访问时才需要公网地址。两者混用是很常见的低级错误。
- 白名单有没有放行。实例的 IP 访问控制里如果没有应用服务器的地址，连接会直接被拒绝。扩容新增实例后，这一步最容易漏。
- 账号和权限是否正确。账号、密码、所属数据库和授权范围都要核对，切换环境时尤其要注意。
- 连接数是否已满。如果报错是 Too many connections，说明连接已经被占满，需要看控制台里的当前连接数和实例上限。
- 实例状态是否正常。实例是否在变更或重启，磁盘空间是否告急，控制台的状态和监控一般会直接给出答案。
按这个顺序看，大部分“连不上”的问题前两三步就能找到原因。如果一上来就改应用代码或者反复重启服务，反而容易把线索冲掉。
案例一：扩容之后连接数被打满
某电商团队在大促前，线上接口突然大面积报 “Too many connections”。排查下来，应用端用了连接池，但单个实例的最大连接数配得偏大。大促前临时把实例扩到二十多台，总连接数一下子超过了 RDS 的上限。
当时的处理是先在控制台确认当前连接数和上限，然后临时调低单实例连接池的上限，重启服务让连接数回落。长期做法是按“实例数乘以单实例连接数”反推总量，给上限留出余量，再评估实例规格够不够用。
这类问题和扩缩容策略绑在一起。扩容时连接数会跟着成倍上去，这一点很容易被忽略。上线前做一次简单的容量估算，能挡住大部分类似的事故。
案例二：一条新查询拖慢整个实例
另一个例子来自一家内容平台。某次版本上线后，列表页响应从几十毫秒涨到几秒，数据库 CPU 长时间居高不下。团队通过阿里云的性能洞察功能，定位到一条新增的多表关联查询，过滤和排序字段没有合适的索引，每次都要扫描大量数据。
修复分三步：用 EXPLAIN 看执行计划，确认全表扫描发生在哪里；给过滤和排序字段补充联合索引，并验证索引确实被命中；对实时性要求不高的统计类查询，挪到只读实例或独立的分析库上跑。
慢查询的麻烦在于，它往往要等上线后才暴露。测试库的数据量通常远小于生产，同样的 SQL 在测试里跑得很快，到了线上就不行了。预发布环境尽量导入接近真实规模的数据再做压测，能提前发现不少问题。
案例三：一条没带条件的 UPDATE
误操作出现的频率不高，但后果往往最重。有团队执行 UPDATE 时漏掉了 WHERE 条件，整张表的状态字段被改掉。发现后，他们用备份恢复功能回滚到事故发生前的时间点，再通过 binlog 对比找出受影响的记录，把损失控制在可以接受的范围内。
这件事留下两条实在的经验。第一，生产库的写操作要走审核，不要让人直接在客户端手动执行高风险语句。第二，备份不能只看“有没有”，要定期验证能不能按时间点恢复。不少团队是在事故发生后才发现备份用不了。
排查的基本顺序
遇到问题时，先确认影响范围，是单个实例、某个业务，还是全局异常。接着看监控，找出最先出现异常的指标。然后翻一遍最近的变更，包括应用发布、参数修改、规格调整和 DDL，很多线索就藏在这里。之后再结合慢日志和执行计划分析具体语句。修复方案先在测试环境验证，再灰度上线。最后把原因和处理过程记下来，下次遇到类似情况能直接用。
日常怎么少踩坑
与其等问题出现再补救，不如把几件小事做成习惯：
- 关键业务的监控告警要配上，阈值留出余量，并确认告警真能通知到值班的人。
- 定期看一次慢日志，把慢查询当成代码质量问题来处理，而不是出事了才去查。
- 参数变更和规格调整先灰度，同时准备好回滚方案，别一次性全量切换。
- 数据库版本尽量留在厂商仍在支持的范围内，关注安全公告，避免长期停在老版本。
- 给开发同学讲讲连接池、索引和事务的基本原理，不少线上问题都和这些概念的误解有关。
数据库稳不稳，很大程度上取决于怎么用、怎么维护。遇到问题先按顺序排查，别凭感觉改配置，大部分故障都能较快定位。
