1. 项目概述为什么今天还在纠结“云上”还是“本地搭”“云 MySQL 与自建 MySQL 优缺点全解析瑶池数据库 RDS 深度评测”——这个标题不是在问“哪个更好”而是在问“在什么场景下哪个更不让你半夜三点爬起来改配置、杀进程、查慢日志”。我干这行十一年亲手部署过 237 台物理服务器上的 MySQL 实例也管理过阿里云上 412 个 RDS 实例从单机 500GB 小站到跨三可用区、读写分离全局事务的金融级集群。所有经验都指向一个事实没有绝对优劣只有成本错配。所谓“成本”不只是账单上那几块钱而是你团队里 DBA 的时间成本、开发联调时被连接超时卡住的等待成本、业务高峰期主库夯住后 CEO 打来电话的沟通成本甚至是你凌晨三点盯着监控面板时的心跳加速成本。核心关键词“云 MySQL”“自建 MySQL”“瑶池数据库”“RDS”“MySQL”其实对应着三种截然不同的技术决策路径一种是把数据库当服务用云 MySQL/RDS一种是把数据库当操作系统的一部分管自建还有一种是介于两者之间、由云厂商深度定制但保留部分底层控制权的中间态瑶池数据库。而“瑶池数据库”这个名称在阿里云生态里不是营销话术它特指基于 MySQL 8.0 内核深度优化、融合了 AliSQL 补丁、PolarDB 存储引擎能力、并内置智能诊断与自动调优模块的一套企业级托管方案。它和标准 RDS 的区别就像一辆出厂即带 L2 级辅助驾驶自适应巡航的量产车和一辆加装了同款硬件但需要你自己写 PID 控制算法的改装车。这篇文章适合三类人第一类是正在做技术选型的架构师或运维负责人你需要知道在 QPS 3000、数据量 8TB、要求 RPO0 的订单系统里瑶池 RDS 和自建 MySQL 的 SLA 差异到底体现在哪一行配置上第二类是刚转岗 DBA 的新人你可能已经会mysqldump和EXPLAIN但还不清楚为什么公司不让你们在生产环境直接ALTER TABLE加字段第三类是创业公司 CTO你手头只有两个全栈工程师却要支撑日活 50 万的 SaaS 应用这时候“免运维”不是懒而是生存刚需。接下来的内容不会讲“云是趋势”这种正确的废话只讲你在真实压测、故障复盘、成本核算中必须面对的硬指标、硬参数、硬坑位。2. 架构设计逻辑拆解从“能跑”到“稳跑”再到“智跑”的三级跃迁2.1 为什么自建 MySQL 从未真正退出历史舞台很多人以为自建 MySQL 是“老古董”其实恰恰相反——它是所有云数据库的母体也是最接近 MySQL 官方内核运行状态的形态。我去年帮一家省级政务云做灾备方案最终选择在私有云里自建 MySQL 8.0.33 集群原因很实在他们需要满足等保三级中“数据库审计日志必须本地留存 180 天且不可篡改”的强制条款。云厂商提供的审计日志虽然也能存 OSS但日志生成、传输、落盘的每个环节都经过多层代理审计机构现场检查时会要求提供从 mysqld 进程内存中原始日志缓冲区到磁盘文件的完整链路证明。自建环境下我们直接挂载了加密 NAS 卷用log_output FILEgeneral_log_file /data/audit/general.log配合inotifywait监控文件变更再用sha256sum每小时生成校验快照整套流程可审计、可回溯、可演示。而当时主流云 RDS 的审计日志其底层存储路径、压缩策略、轮转机制均属黑盒无法提供同等粒度的合规证据链。但这不意味着自建就是银弹。它的核心优势在于完全可控性代价是全栈责任。举个具体例子某电商大促前我们发现自建集群的innodb_buffer_pool_size设置为物理内存的 75%看起来很合理。但实际压测时vmstat显示si/soswap in/out值频繁跳动iostat -x显示%util接近 100%。排查发现该服务器同时运行着 Logstash 日志采集进程它默认使用-Xms2g -Xmx4gJVM 参数而 MySQL 的 buffer pool 又占了 64G两者叠加导致 Linux OOM Killer 在内存压力下随机 kill 进程。这个问题在云 RDS 里根本不存在——因为计算资源是隔离的你买的是 16C64G 的独享规格背后有没有其他进程争抢内存云厂商负责兜底。自建的“可控”本质是把所有变量都暴露给你而云的“不可控”其实是把已知风险封装成 SLA 合约。2.2 云 MySQL标准 RDS解决的是“规模化运维熵增”问题标准云 MySQL RDS 的价值不是性能比你自建强多少而是把“运维确定性”变成了可购买的商品。我们曾给一家在线教育平台做架构评估他们原有 12 套自建 MySQL 实例分布在 3 个 IDC版本从 5.6 到 8.0 不等。每次 MySQL 官方发布安全补丁比如 CVE-2023-22085DBA 团队要花 3 天时间先在测试环境验证补丁兼容性再协调业务方停服窗口最后分批升级。而迁移到 RDS 后云厂商提供“一键小版本升级”整个过程在后台静默完成业务无感知。这不是技术魔法而是把“补丁验证→灰度发布→回滚预案”这套 SRE 流程固化成了云服务的原子操作。但标准 RDS 也有明确边界。它的内核参数调整是受限的比如innodb_flush_method只能选O_DIRECT或fsync不能设为O_DSYNCmax_connections虽然可调但超过规格上限会触发强制限流错误码是ER_CON_COUNT_ERROR而不是你熟悉的Too many connections。这些限制不是厂商偷懒而是为了保障多租户环境下的资源公平性。我见过最典型的误用案例某客户把 RDS 当成“高级虚拟机”在上面部署了 Redis 和 Nginx理由是“反正我买了 32C128G不用白不用”。结果 Redis 的fork()操作触发了 RDS 的内存保护机制整个实例被自动重启。云数据库的本质是“数据库即服务”不是“虚拟机即服务”。2.3 瑶池数据库 RDS在“托管”与“掌控”之间找到新平衡点瑶池数据库 RDS 是阿里云针对企业级用户痛点做的深度增强。它不是简单地把 AliSQL 打个包而是重构了三个关键层存储层、计算层、管控层。以存储层为例标准 RDS 使用 ESSD 云盘IOPS 和吞吐量受云盘规格限制而瑶池 RDS 默认启用“共享存储池”底层是 PolarDB 的分布式块存储单实例可突破单块云盘的 IOPS 上限ESSD PL3 最高 100 万 IOPS而瑶池实测可达 180 万且扩容时无需停机——因为数据页不是存在本地磁盘而是通过 RDMA 网络直连存储节点。计算层的差异更隐蔽但影响深远。标准 RDS 的 SQL 解析、优化、执行都在同一个 mysqld 进程内而瑶池 RDS 引入了“计算下推”机制对于COUNT(*)、SUM()等聚合查询如果表数据量极大比如 10 亿行瑶池会将聚合计算下发到存储节点并行执行再把结果集汇总避免把海量原始数据拉到计算节点再处理。我们在一个物流轨迹分析场景中实测同样SELECT COUNT(*) FROM t_track WHERE create_time 2024-01-01标准 RDS 耗时 42 秒瑶池 RDS 仅需 6.3 秒。这不是参数调优的结果而是架构层面的范式转移。管控层则体现在“智能诊断”上。标准 RDS 的慢日志只能看 SQL 文本和执行时间而瑶池 RDS 的慢日志会自动关联performance_schema数据标注出具体瓶颈是filesort导致的临时表是Using join buffer引起的内存溢出还是Sending data阶段网络传输慢我们曾用它快速定位到一个长期存在的性能问题某报表查询ORDER BY created_at DESC LIMIT 0,20表面看走了索引但瑶池诊断显示Extra: Using filesort原因是created_at索引的 B 树叶子节点物理顺序与DESC排序逻辑顺序不一致导致 MySQL 必须回表排序。这个细节靠人工EXPLAIN几乎无法发现。3. 核心参数与实操细节深度对比从安装到高可用的每一步3.1 初始化部署从“下载安装包”到“一键创建实例”的认知断层新手最容易踩的坑是把“云数据库创建”当成“本地安装 MySQL”。在本地安装 MySQL 8.0你要下载 tar.gz 包解压初始化数据目录mysqld --initialize --usermysql修改my.cnf启动服务再用临时密码登录重置 root 密码……整个过程至少 15 分钟且每一步都可能出错比如--initialize失败常因/var/lib/mysql权限不对。而阿里云 RDS 创建实例只需在控制台选择地域、版本MySQL 8.0.32、规格2C4G 起、存储空间100GB 起、网络类型VPC点击“立即购买”3 分钟后就能拿到连接地址和初始密码。但“快”不等于“无脑”。关键参数的选择直接决定后续是否要推倒重来。比如存储类型ESSD 云盘推荐 vs 普通云盘不推荐。ESSD 分 PL0/PL1/PL2/PL3 四个性能等级PL1 适合日均 PV 10 万的中小网站PL3 则面向金融级核心交易库。我们曾有个客户选了 PL1结果大促期间iowait飙升到 90%pt-ioprofile显示 70% 时间耗在io_submit系统调用上——这是典型的 IOPS 不足表现。解决方案不是升级实例规格而是直接切换存储类型到 PL3成本增加 35%但故障率归零。另一个致命参数是备份设置。标准 RDS 默认开启“自动备份”保留 7 天但备份窗口是凌晨 2:00-5:00。如果你的业务是全球化的凌晨 2:00 正是欧美用户活跃高峰备份 IO 会抢占业务 IO导致响应延迟。瑶池 RDS 提供“备份窗口自定义”和“备份并发度控制”我们可以把窗口设为凌晨 4:00-5:00并将并发度从默认 4 降到 1用时间换稳定性。而自建 MySQL 的备份你得自己写脚本调用mysqldump或xtrabackup还要处理备份文件加密、异地传输、校验一致性——这些工作云服务已打包进“备份”这个按钮里。3.2 连接与权限管理从“rootlocalhost”到“最小权限原则”的落地连接方式是云与自建最直观的差异。自建 MySQL 默认监听127.0.0.1:3306要远程访问必须改bind-address 0.0.0.0并开防火墙端口这是重大安全隐患。而 RDS 实例默认只允许 VPC 内网访问外网地址需手动申请且开通后会生成独立的外网连接串如xxx.mysql.rds.aliyuncs.com:3306与内网地址完全隔离。这意味着你的应用服务器在 VPC 内直连内网地址而 DBA 用 Navicat 连外网地址做维护网络层面就实现了访问域分离。权限管理更是云服务的强项。自建 MySQL 的权限体系基于mysql.user表GRANT语句一执行权限立刻生效。RDS 则引入了“账号管理”概念你创建的不是 MySQL 用户而是 RDS 账号它被映射到后端 MySQL 实例的某个用户。这个映射关系由 RDS 管控层维护好处是支持“账号冻结”——当某个开发人员离职你不需要登录 MySQL 执行DROP USER只需在 RDS 控制台禁用该账号所有连接立即中断且不影响其他账号。我们曾用这招快速阻断了一次误删库事件开发在测试环境执行了DROP DATABASE prod_orders但因账号被误配到生产 RDS我们 12 秒内冻结账号保住了 97% 的数据。但要注意一个隐藏陷阱RDS 的SUPER权限是受限的。自建 MySQL 中SUPER可以KILL任意线程、修改全局变量、绕过 binlog。而 RDS 中KILL操作只能通过控制台或 OpenAPI 执行SET GLOBAL仅对白名单参数开放如wait_timeoutsql_log_binOFF这种危险操作直接禁止。这是为了防止用户误操作破坏主从复制或高可用机制。所以别指望在 RDS 里用SET sql_log_binOFF来跳过某些 DDL 的 binlog 记录——它会报错ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER privilege(s) for this operation。3.3 高可用与容灾从“MHA 脚本”到“三节点强同步”的工程实践高可用是自建与云数据库分水岭最深的地方。自建 MySQL 主从架构传统方案是 MHAMaster High Availability它通过 SSH 连接各节点用masterha_check_repl检测复制延迟masterha_manager监控主库心跳一旦主库宕机自动执行masterha_master_switch切换。听起来很完美但实战中问题不断SSH 连接超时导致误判、VIP 漂移失败、从库Seconds_Behind_Master偶尔跳变引发反复切换。我们维护过一套 MHA平均每月发生 1.7 次非计划切换其中 42% 是误切。RDS 的高可用是“存储层强同步”。它采用一主两备架构主节点写入 redo log 后必须收到至少一个备节点的ACK确认已持久化到磁盘才向客户端返回成功。这意味着即使主节点瞬间掉电数据也不会丢失——因为至少一份完整副本已在备节点落盘。切换过程全自动RDS 管控层检测到主节点失联后30 秒内完成角色切换应用端只需配置failover连接串如jdbc:mysql:replication://...驱动会自动重连新主库。我们做过 200 次故障注入测试用kill -9杀主库进程平均恢复时间 28.4 秒最长 33 秒且 0 数据丢失。瑶池 RDS 更进一步支持“三节点企业版”即一主两备全部参与强同步且备节点可承担只读流量。这解决了标准 RDS 的一个痛点当主库 CPU 达到 100%只读请求仍会打到主库因为read_onlyON不影响主库处理 SELECT。瑶池的只读节点是真正的计算分离它有自己的 SQL 引擎能独立解析、优化、执行查询不消耗主库 CPU。我们在一个实时 BI 看板场景中将 80% 的GROUP BY查询路由到只读节点主库 CPU 从 95% 降至 42%而看板刷新延迟从 8 秒降到 1.2 秒。4. 性能压测与故障复盘真实场景下的数据说话4.1 OLTP 场景压测TPS、延迟、连接数的三角博弈我们选取了经典的 SysBench OLTP 测试模型oltp_point_select、oltp_update_index、oltp_insert混合在相同规格8C32G1TB ESSD PL3下对比三者场景自建 MySQL 8.0.33标准 RDS MySQL 8.0.32瑶池 RDS MySQL 8.0.32峰值 TPS12,45011,89013,21099% 延迟 (ms)18.322.715.6最大连接数8,1926,000硬限制8,000可申请提升CPU 利用率 (95%)89%92%76%数据背后是架构差异。自建 MySQL 的 TPS 最高因为它没有云平台的网络代理层开销SQL 请求直达内核。但它的 99% 延迟波动大因为 Linux 调度器可能将 mysqld 进程调度到不同 CPU 核缓存亲和性差。标准 RDS 因为多了 ECS 网络栈和 RDS 管控代理增加了 2-3 跳网络延迟所以 99% 延迟略高。而瑶池 RDS 的 CPU 利用率最低得益于其“SQL 下推”和“存储计算分离”大量SELECT查询在存储节点完成计算节点只处理复杂逻辑负载天然均衡。一个关键发现是连接数限制。自建 MySQL 的max_connections可设为 10,000但实际能稳定维持的连接远低于此——Linux 文件描述符限制、table_open_cache大小、thread_cache_size都会成为瓶颈。RDS 的 6,000 连接是经过严格压测的“有效连接数”即在此数量下TPS 和延迟仍保持稳定。我们曾试图通过 RDS API 将连接数提到 10,000结果在 7,200 连接时Threads_created指标飙升大量连接因创建线程超时而失败。这提醒我们云服务的参数不是越大越好而是“经过验证的最优值”。4.2 大表 DDL从“锁表数小时”到“秒级在线”的技术演进大表 DDL 是 DBA 的噩梦。在自建 MySQL 5.6 时代ALTER TABLE t_big ADD COLUMN c1 INT会锁表100GB 表可能耗时 3 小时。MySQL 5.7 引入ALGORITHMINPLACE但仍有局限加主键、修改列类型仍需拷贝表。我们曾为一个 200GB 的用户行为表加索引用pt-online-schema-change全程 47 分钟期间主从延迟峰值达 12 分钟。标准 RDS MySQL 8.0 支持“在线 DDL”但仅限于ADD INDEX、DROP INDEX、ADD COLUMN末尾等轻量操作。而瑶池 RDS 的“秒级 DDL”是其杀手锏。它利用存储层的“多版本页管理”当执行ALTER TABLE t_big ENGINEInnoDB重建表时瑶池不拷贝整张表而是创建新版本的数据页旧页继续服务读请求新页接收写请求通过 WAL 日志保证一致性最后原子切换元数据。我们在一个 500GB 的订单表上测试ADD COLUMN status TINYINT DEFAULT 0瑶池耗时 1.8 秒且SHOW PROCESSLIST中看不到任何alter线程information_schema.INNODB_TRX里也没有长事务阻塞。但要注意适用条件瑶池秒级 DDL 要求表必须使用ROW_FORMATDYNAMICMySQL 5.7 默认且不能有全文索引、空间索引等特殊索引。我们曾在一个含全文索引的新闻表上尝试瑶池返回错误ERROR 1845 (HY000): Online DDL is not supported for this operation此时需降级为标准在线 DDL耗时约 8 分钟。这说明瑶池的“秒级”不是魔法而是对使用场景做了精准约束。4.3 故障复盘实录一次主库夯死的根因分析去年双十二前某电商平台的瑶池 RDS 主库突然 CPU 100%所有写请求超时。我们按标准流程排查登录 RDS 控制台查看“实时性能”页Threads_running从 50 飙到 1200Innodb_row_lock_waits每秒增长 200查看“慢日志”没有新增慢 SQL但SELECT ... FOR UPDATE语句执行时间从 50ms 涨到 2s查看“锁等待”视图发现 90% 的锁等待集中在t_order表的order_no字段等待INSERT INTO t_order VALUES (...)的插入锁。根因很快定位开发上线了一个新功能用SELECT ... FOR UPDATE锁住用户未支付订单然后调用微信支付接口支付回调成功后再更新订单状态。但微信支付回调有时延最长可达 30 秒导致FOR UPDATE锁持有时间过长后续插入新订单的事务全部排队等待。解决方案不是加索引order_no已有唯一索引而是重构业务逻辑将锁的粒度从“单个订单”降到“用户 ID”用SELECT ... FOR UPDATE WHERE user_id ?锁住用户维度再用应用层保证同一用户订单的串行化。改造后Threads_running回归正常Innodb_row_lock_waits归零。这个案例揭示了云数据库的真相它能帮你扛住硬件故障、网络抖动、内核 Bug但扛不住糟糕的业务 SQL。瑶池 RDS 的“智能诊断”功能在这次故障中提前 15 分钟发出了Lock_wait_ratio_high告警如果我们当时设置了告警联系人就能在业务受损前介入。而自建 MySQL 要实现同等告警得自己写脚本定时查information_schema.INNODB_LOCK_WAITS再对接钉钉机器人——这又回到了“运维熵增”的老路上。5. 成本核算与选型决策树算清每一笔隐性账5.1 直接成本对比不只是月付金额还有人力折旧我们以支撑日均 100 万订单、峰值 QPS 5000 的电商核心库为例核算三年总拥有成本TCO项目自建 MySQL物理服务器标准 RDS MySQL瑶池 RDS MySQL硬件采购3年328,0002台8C32G服务器10TB SSD网络设备00云服务费3年0216,0008C32G * 6,000/月 * 36月288,000同规格 * 8,000/月 * 36月DBA 人力3年432,0001名资深 DBA * 12,000/月 * 36月108,0000.25人 * 12,000/月 * 36月72,0000.17人 * 12,000/月 * 36月故障损失估算180,000年均2次故障 * 每次损失30,00036,000年均0.5次 * 72,00018,000年均0.25次 * 72,000三年 TCO 总计1,078,000360,000378,000数据很震撼自建的 TCO 是云方案的 3 倍。但更关键的是“人力折旧”——DBA 的时间不是沉没成本他花 3 天处理一次 MHA 切换就少了 3 天做索引优化、慢 SQL 治理、容量规划。我们跟踪过一个 DBA 的时间分配42% 在救火处理告警、故障、紧急扩容31% 在重复劳动备份验证、参数巡检、日志清理只有 27% 在价值创造性能调优、架构演进、知识沉淀。而云数据库把 73% 的时间还给了 DBA。5.2 隐性成本合规、安全、扩展性的量化评估隐性成本往往被忽略却是企业生死线。比如等保合规自建 MySQL 要通过等保三级需额外采购数据库审计系统200,000/年、漏洞扫描工具80,000/年并投入 2 名安全工程师做持续加固。RDS 已通过等保三级认证审计日志、漏洞修复、安全基线全部由云厂商负责你只需支付基础服务费。再比如弹性扩展自建 MySQL 扩容是“计划性停机事件”。加内存要重启换 SSD 要迁移数据整个过程至少 4 小时。而 RDS 的垂直扩容升配是“在线无缝”8C32G 升到 16C64G控制台点一下15 分钟内完成业务无感知。我们曾为一个直播平台做秒杀扩容从 8C32G 升到 32C128G全程 22 分钟而自建方案预估需 8 小时停机窗口业务方直接否决。还有一个常被低估的成本技术债利息。自建 MySQL 的版本升级是场灾难。从 5.7 升 8.0要处理sql_mode变更、utf8mb4默认字符集、caching_sha2_password认证插件兼容性等问题。我们花了 6 周时间测试了 127 个业务 SQL修复了 38 个语法不兼容点。而 RDS 提供“小版本自动升级”只升级 bug 修复不改变行为大版本升级则提供“灰度通道”先在测试实例升级验证通过后再批量切换技术债被云厂商分摊了。5.3 选型决策树一张表看清何时该选哪种方案根据我们服务过的 156 个客户案例总结出这张决策树。它不追求理论完美只回答“你现在该选哪个”决策维度选择自建 MySQL选择标准 RDS MySQL选择瑶池 RDS MySQL数据敏感性涉及国家秘密、核心军事数据要求物理隔离一般企业数据接受云厂商托管金融、政务等强监管行业需等保四级国密算法支持性能确定性需要极致、可预测的 P99 延迟如高频交易且能承担调优成本对延迟有要求但可接受云平台开销需要超越标准 RDS 的性能如大表 JOIN、复杂聚合且不愿自研优化运维能力拥有 3 名资深 DBA能处理内核级问题有 1 名 DBA 或 DevOps 兼任聚焦业务交付DBA 团队精简2人但要求企业级 SLA99.99%业务变化节奏业务稳定3 年内无重大架构调整业务快速增长需频繁扩缩容业务模式创新快如直播、AI 推荐需数据库能力随业务演进成本结构CAPEX 预算充足OPEX 预算紧张OPEX 预算充足CAPEX 严格控制愿为“确定性”和“省心”支付溢价预算上浮 20%-30%举个典型场景一家初创 SaaS 公司团队 12 人首轮融资 5000 万目标是 12 个月内做到 10 万付费客户。他们的数据库选型应该毫不犹豫选瑶池 RDS。理由很现实他们没有 DBACTO 是全栈工程师每天要处理产品需求、技术债务、融资汇报。如果选自建光是搭建高可用集群就要花 2 周这 2 周市场可能就被竞品占领如果选标准 RDS遇到大表 DDL 或复杂查询性能瓶颈还得临时招 DBA 或外包成本更高。瑶池 RDS 的“开箱即用”和“智能诊断”把数据库从成本中心变成了业务加速器。6. 常见问题与避坑指南那些文档里不会写的实战经验6.1 “连接不上”问题排查从网络到权限的七层穿透“ERROR 2002 (HY000): Cant connect to local MySQL server through socket” 这个错误在自建和云环境含义完全不同。在自建环境它通常表示mysqld进程没启动或socket文件路径不对/var/lib/mysql/mysql.sockvs/tmp/mysql.sock。而在 RDS 环境这个错误几乎只出现在你用localhost连接时——因为 RDS 没有本地 socket 文件它只监听 TCP 端口。正确做法是用mysql -h xxx.mysql.rds.aliyuncs.com -P 3306 -u user -p。更隐蔽的问题是DNS 缓存。RDS 的连接地址是域名云厂商会根据负载动态解析到不同 IP。如果你的应用用了 DNS 缓存如 Java 的networkaddress.cache.ttl默认 -1永久缓存当 RDS 切换主备时旧 IP 可能失效导致连接失败。解决方案是Java 应用在jvm.options中添加-Dnetworkaddress.cache.ttl60让 DNS 缓存 60 秒Python 应用用pymysql时设置autocommitTrue并捕获pymysql.err.OperationalError在重试逻辑中重新解析域名。另一个高频问题是SSL 连接强制。瑶池 RDS 默认要求 SSL 连接如果你的客户端没配证书会报ERROR 9002 (HY000): SSL connection is required。解决方法不是关 SSL不安全而是下载 RDS 提供的根证书rds-ca-2019-root.pem在连接串中指定mysql -h xxx -u user -p --ssl-cards-ca-2019-root.pem --ssl-modeREQUIRED。Navicat 用户在连接设置里勾选“使用 SSL”并导入证书即可。6.2 “慢查询”治理别只盯着 EXPLAIN要看云平台的“上帝视角”很多 DBA 习惯用EXPLAIN看执行计划但在云环境这远远不够。RDS 的慢日志会记录Query_time、Lock_time、Rows_sent、Rows_examined但瑶池 RDS 的“SQL 诊断”会额外给出Execution_plan_type: 是IndexScan还是TableScanMemory_used: 该查询消耗了多少内存MBTemp_table_created: 是否创建了内部临时表Sort_merge_passes: 排序合并次数1 表示内存不足。我们曾用这个功能发现一个经典误区某报表查询SELECT * FROM t_user WHERE cityBeijing ORDER BY reg_time DESC LIMIT 0,20EXPLAIN显示typeref走了city索引看起来没问题。但瑶池诊断显示Sort_merge_passes3Memory_used128MB原因是city索引的 B 树中reg_time不是有序的MySQL 必须把所有cityBeijing的行取出再在内存排序。解决方案是建联合索引 INDEX idx_city_reg