分库分表仅在单表超千万、缓存命中率骤降、Innodb_data_reads飙升且%util持续≥90%时有效；此前应优先优化SQL、加索引、换SSD、调大buffer pool。
Innodb_data_reads持续飙升且%util接近100%时才真正起效；在此之前，优先优化SQL、加索引、上SSD、调大innodb_buffer_pool_size。
怎么确认真是IO瓶颈，而不是SQL写错了？
别急着拆库，先看数据：用iostat -x 1盯%util，超过90%持续1分钟以上，再查MySQL：SHOW GLOBAL STATUS LIKE 'Innodb_data_reads'，如果每秒读数从几百跳到几千，同时慢查询里频繁出现Using filesort或Using temporary，基本就是IO扛不住了。
常见误判点：
- 把CPU高当成IO高：
top里看%iowait是否真高（>10%），而不是只看%cpu - 忽略缓存配置：
innodb_buffer_pool_size没设到物理内存的70%~80%，导致本该走内存的查询全落盘 - 误以为“查询慢=IO问题”：EXPLAIN显示
type=ALL或rows远大于实际返回行数，其实是缺索引
水平分表比水平分库更适合IO瓶颈场景
IO瓶颈本质是单个ibd文件太大、随机读放大、buffer pool装不下热数据。水平分表直接减小单个表的物理体积，提升缓存局部性，效果立竿见影；而水平分库虽然也分散IO，但引入网络开销和事务一致性成本，对纯IO压力改善不如分表直接。
实操建议：
- 按时间或用户ID做
RANGE或HASH分片，比如order_2025Q1、order_2025Q2，避免跨分片查询 - 分片键必须是高频查询条件，否则会触发全表扫描+合并，IO压力反而更大
- 单表控制在300万~500万行以内，配合
innodb_file_per_table=ON，让每个分表独立管理空间 - 不要用自增主键当分片键——会导致新数据全部写入最后一个分表，热点集中
分库分表后IO问题可能换了个地方爆发
拆完发现从库IO又爆了？常见原因：
- 主从复制用的是
STATEMENT格式，一条UPDATE在从库重放时扫描全表，产生巨量IO - 没关
innodb_flush_log_at_trx_commit=1，高并发写导致redo log刷盘太频繁 - 分片后查询变多，但应用层没配连接池，大量短连接反复建连/销毁，加重IO负担
- 中间件如ShardingSphere默认不路由
SELECT COUNT(*)，直接广播到所有分片，IO翻N倍
关键动作：把复制格式切到ROW，sync_binlog=1和innodb_flush_log_at_trx_commit=1至少保留一个，监控Seconds_Behind_Master突增时立刻查从库iostat。
硬件和配置不升级，分库分表只是把问题摊薄
你把1个库拆成4个，但每台机器还是机械盘、buffer pool只设2G，IO瓶颈只是从“一台机器挂”变成“四台轮流挂”。真正要动的配置包括：
-
innodb_buffer_pool_size：必须占可用内存70%以上，不能还按老习惯设1G - 磁盘：必须SSD，RAID10优于RAID5，NVMe比SATA SSD延迟低5倍
- OS层面：
vm.swappiness=1，禁用swap；read_ahead关掉，避免预读浪费IO带宽 - MySQL 8.0+启用
innodb_dedicated_server=ON，自动适配硬件资源
最容易被忽略的一点：分库分表后，每个分片的innodb_log_file_size也要按比例调大，否则redo log频繁checkpoint，反而加剧IO。
