MySQL本身不支持自动扩容，所有“自动伸缩”均依赖云平台在MySQL上层封装的运维自动化逻辑，仅存储空间可自动扩容，CPU/内存/连接数等需人工干预或自建监控+API组合实现。
MySQL 本身不支持自动扩容，所有“自动伸缩”都依赖外部编排
MySQL 是单机（或主从/集群）架构的数据库，mysqld 进程自身没有容量感知、节点增删、数据重分片能力。所谓“自动扩容”，实际是云平台（如 AWS RDS、阿里云 PolarDB、腾讯云 CDB）在 MySQL 上层封装的运维自动化逻辑——它不改 MySQL，而是替你做扩容决策 + 执行迁移 + 切换路由。
如果你用的是自建 MySQL（哪怕跑在云服务器上），ALTER TABLE 或 mysqldump 都不会触发“自动扩容”。必须自己写脚本监听磁盘/连接数/慢查询率等指标，再调用云 API 创建新实例、迁移数据、更新 DNS 或代理配置。
- 常见错误现象：
ERROR 1040 (HY000): Too many connections或磁盘使用率告警后手动扩容，误以为“开了自动伸缩就不用管了” - 真实使用场景：RDS 实例设置“存储空间自动扩容”，仅对
innodb_data_file_path对应的共享表空间或独立.ibd文件所在磁盘生效，不涉及 CPU/内存/连接数提升 - 关键参数差异：
max_connections、innodb_buffer_pool_size等内存相关配置不会随磁盘扩容自动调整，必须手动同步修改并重启（或在线动态调，取决于版本）
云厂商 RDS 的“自动扩容”只管磁盘，不管计算资源
以阿里云 RDS MySQL 为例，“自动扩容”开关只控制 StorageAutoScale 行为，底层是监控 /rdsdbdata 分区使用率，到达阈值后调用云盘扩容接口（如 ModifyDiskAttribute），再通知 MySQL 重新识别空间（ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME 不需要，因为 InnoDB 自动扩展 ibdata1 或新增 ibd 文件）。
但 CPU 使用率持续 95% 超过 5 分钟？RDS 不会自动升配到 8 核；连接数打满？也不会自动加 max_connections。这些属于“垂直伸缩”，需人工触发或通过云监控 + 函数计算 + OpenAPI 组合实现。
- 容易踩的坑：开启“存储自动扩容”后，误以为慢查询也会变快——其实 IOPS 可能卡在原磁盘规格（如普通云盘默认 300 IOPS），扩容只是增大容量，不提升性能
- 兼容性影响：MySQL 5.7 开启
innodb_file_per_table=ON后，单表.ibd文件可被单独监控和迁移；但系统表仍挤在ibdata1，该文件无法收缩，长期运行后即使删库磁盘也不释放 - 实操建议：在创建 RDS 时选“通用型”而非“独享型”，前者支持按需升降配；若已用独享型，扩容 CPU/内存必须停机 3–5 分钟
真要实现连接数/吞吐量自动伸缩，得绕开 MySQL 做代理层调度
MySQL 协议层无负载感知机制，所以自动伸缩必须发生在客户端与数据库之间：用 ProxySQL 或 MySQL Router 做连接池 + 权重路由，配合 Prometheus + Alertmanager 监控 Threads_connected、Queries 每秒速率，再用脚本调云 API 扩容只读副本（CreateDBInstance）、加入集群、更新 ProxySQL 的 mysql_servers 表。
这不是 MySQL 的功能，是运维链路的拼装。一旦中间任何一环失败（比如副本创建成功但复制延迟超 60 秒），流量切过去就会读到旧数据。
- 常见错误现象：ProxySQL 将请求轮询到新拉起的只读实例，但
Seconds_Behind_Master为NULL或极大值，导致查询结果不一致 - 使用场景：读多写少、允许秒级延迟的报表类业务；强一致性事务不能走自动扩出的只读节点
- 性能影响：每次新增只读实例，主库 binlog dump 线程压力增加，可能拖慢主库写入；建议限制最大副本数（如不超过 5 个），并开启
binlog_row_image=MINIMAL
自建环境想模拟“自动扩容”，核心是监控 + API + 幂等操作
别信一键脚本。真正可用的方案必须解决三个问题：指标采集可靠（不是每分钟查一次 df -h）、扩容动作幂等（重复触发不新建两个实例）、回滚路径明确（扩容失败时能快速切回旧实例）。
推荐用 mysqld_exporter 暴露 mysql_global_status_threads_connected 和 mysql_info_schema_innodb_buffer_pool_pages_total，配 Prometheus rule 触发 webhook，调用云厂商 SDK 执行扩容。所有操作日志必须落盘，且关键步骤（如修改 my.cnf、重启 mysqld）加锁文件防并发。
- 容易忽略的点：扩容后
wait_timeout和interactive_timeout仍沿用旧值，长连接堆积可能掩盖真实连接数增长；务必在扩容流程末尾执行SET GLOBAL wait_timeout = 300 - 路径注意：
/etc/my.cnf修改后需确认mysqld --print-defaults输出是否包含新配置，某些 Docker 镜像会覆盖挂载的配置文件 - 错误信息示例：
ERROR 1236 (HY000): Could not find first log file name in binary log index file—— 这常发生在副本扩容时没校验主库 binlog 是否被清理，需提前设好expire_logs_days
自动扩容不是开关一开就完事，它把复杂度从“手忙脚乱半夜救火”转移到“设计健壮的判断边界和失败兜底”。最麻烦的永远不是扩容动作本身，而是怎么定义“该扩容了”、以及“扩完发现更慢了”时怎么无声降级。
