数据库通常是业务系统里最先顶不住的地方。数据从几十万涨到几千万，原来很快的查询开始拖慢页面，运维同学半夜被告警叫醒的次数也多了起来。很多团队会把数据库交给云厂商托管。阿里云的 SQL 相关产品种类不少，从关系型数据库到分析型引擎都有。这篇文章结合一个实际迁移的案例，讲讲选型怎么想，以及日常怎么优化。
先想清楚业务形态，再挑产品
阿里云上和 SQL 相关的产品比较多，常见的有云数据库 RDS（支持 MySQL、PostgreSQL、SQL Server 等引擎）、云原生分布式数据库 PolarDB，还有面向大数据分析的 AnalyticDB 和 MaxCompute。选的时候可以先问自己三个问题：数据主要是事务性的读写，还是以统计分析为主；未来一两年数据量大概会涨到什么规模；团队在数据库内核和运维上能投入多少人力。
订单、库存、用户账户这类业务，一般选 RDS 或 PolarDB 就够用。报表和用户行为分析这类要扫大量数据的场景，放到 AnalyticDB 更合适。把分析和事务拆开，分析查询就不会抢线上的资源。
计费方面，包年包月和按量付费各有场景。流量稳定、用量可预估的库，包年包月更划算；测试环境或者波动大的任务，按量付费更灵活。不管选哪种，都该定期检查，把已经不用的实例和快照清掉，免得白白占着费用。
案例：一家零售团队的订单库迁移
某中型零售企业原来在自建机房跑 MySQL。订单表两年内涨到约六千万行，大促期间订单详情页的查询耗时从几十毫秒涨到两三秒，客服投诉也跟着多起来。团队决定迁到阿里云 RDS for MySQL，顺便把 SQL 层面的问题也梳理一遍。
迁移分三步走。第一步，用数据传输服务做全量加增量同步，挑业务低峰期割接，停机时间控制在十分钟以内。第二步，打开慢查询日志，再通过数据库自治服务 DAS 看 Top SQL。前三名的慢查询都出在订单列表页，共同点是按用户 ID 和下单时间筛选，却没有合适的联合索引。第三步，给这些查询补索引，同时把一部分只读统计查询转到只读实例上。
优化后的几个变化
- 订单列表查询加上 (user_id, created_at) 联合索引之后，单次查询扫描的行数从几万降到几十行。
- 统计类 SQL 挪到只读实例，主库的 CPU 峰值明显低了。
- 深分页改成游标方式，也就是拿上一页最后一条记录的主键继续往下查。OFFSET 翻得越深越慢，这个问题就能避开。
索引也不是越多越好。团队上线前用 EXPLAIN 把关键 SQL 的执行计划逐条过了一遍，最后删掉两个几乎没人用的冗余索引，写入表现稳定了不少。写多读少的表尤其要留意这一点，每多一个索引，写入时都要多维护一份。
日常运维的几件基础事
数据库上云后，很多工作交给平台自动化就行，但下面几件事还得团队自己盯着。
- 定期看慢查询报告，执行时间超过阈值的 SQL 直接拉进代码评审。
- 给核心业务配好备份策略，并且定期演练一次从备份恢复，确认备份真的能用。备份从没恢复过的团队不少，出事才发现文件不可用，就太晚了。
- 用参数模板管理数据库配置。改参数前先在测试实例上跑一遍，别直接在生产上试。
- 应用账号按最小权限分配，开发和生产的账号严格分开。
监控上，CPU、内存、连接数和磁盘空间都该设告警阈值。连接数最容易被忽略。应用端如果没用好连接池，高峰期很容易碰到连接数上限，表现为偶发超时。排查时大家往往先怀疑网络，绕一大圈才发现是连接池的问题。
团队内部最好统一一份 SQL 编写规范，比如禁止 SELECT *，查询条件要能命中索引，批量写入分批提交。把这些写进开发手册，比出了问题再救火省事得多。
写在最后
用阿里云的 SQL 产品，团队能把基础设施的活交给平台，把精力放回数据模型和查询本身。选型先看清业务形态，迁移留足验证时间，日常靠慢查询分析和规范约束慢慢改。上面这个案例不复杂，但每一步都对应一个具体问题，结果也能量化，优化数据库大致就是这样一步步做的。
