优先考虑垂直拆分，将高频访问字段保留在主表，宽文本等低频字段抽至扩展表（如users_ext），通过user_id关联，以降低i/o与内存压力。
表体积过大但查询只用到部分字段，优先考虑垂直拆分
当 SELECT COUNT(*) FROM table_name 返回数千万以上，而日常查询（如用户中心页）只取 user_id、nickname、avatar_url 等少数字段，且该表存在大量宽文本字段（如 profile_json、bio_long_text、settings_blob），说明 I/O 和内存压力主要来自冗余列读取。
垂直拆分不是“按业务想当然切”，而是看实际访问模式：
- 用
SELECT * FROM information_schema.COLUMNS WHERE TABLE_NAME = 'users' ORDER BY COLUMN_LENGTH DESC查出最宽的 3–5 列 - 结合慢日志或
performance_schema.events_statements_summary_by_digest，确认这些宽字段是否几乎从不被WHERE、JOIN或SELECT引用 - 如果
EXPLAIN FORMAT=JSON显示rows_examined远大于rows_sent（比如 10 万 vs 100），大概率是“读多写少 + 列宽失衡”
拆法很简单：把高频访问字段保留在主表，其余字段抽成新表（如 users_ext），用 user_id 主键关联。注意外键约束在 MySQL 中会拖慢大批量写入，生产环境建议用应用层保证一致性，而非强依赖 FOREIGN KEY。
单表行数超 2000 万且写入/查询明显变慢，检查水平拆分必要性
2000 万不是魔法数字，关键看 innodb_buffer_pool_size 是否能缓存热点数据。如果 SHOW ENGINE INNODB STATUS 里频繁出现 Buffer pool hit rate 低于 95%，同时 SELECT 延迟毛刺集中在 1s+，且 ORDER BY created_at LIMIT 20 这类查询执行计划中出现 Using filesort 或扫描行数远超 LIMIT，就该怀疑单表已成瓶颈。
水平拆分前必须验证是否真由数据量导致：
- 先确认没 missing 索引：用
pt-duplicate-key-checker或sys.schema_unused_indexes扫描无效索引 - 检查
innodb_log_file_size是否过小（常见于写入突增后log sequence number追不上），这会导致刷脏页阻塞 - 运行
SELECT table_name, round(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES WHERE table_schema = 'your_db' ORDER BY size_mb DESC LIMIT 5，确认是不是这张表真的占了 80%+ 存储和 70%+ QPS
若确认是规模问题，再选拆分键。别用 UUID 或 MD5——它们导致写入完全随机，InnoDB B+ 树分裂严重；优先选有业务意义、单调递增、查询高频过滤的字段，比如 tenant_id（SaaS 多租户）、shop_id（电商）、user_id % 16（用户级服务）。
联合使用垂直+水平拆分时，务必避免跨分片 JOIN
一旦做了水平拆分，MySQL 原生不支持跨分片 JOIN。如果垂直拆出的 users_ext 表也被水平拆了（比如按 user_id % 8 分 8 张表），而业务代码还写着 SELECT u.name, ue.bio FROM users u JOIN users_ext ue ON u.id = ue.user_id WHERE u.status = 1，那要么报错，要么变成全量拉取再内存 Join，性能雪崩。
应对方式只有两种：
- 应用层双查：先查
users得到一批user_id，再根据分片规则计算每个 ID 对应的users_ext_{n}表名，批量查过去，最后 merge 结果 - 冗余必要字段：把
users_ext中被高频 JOIN 的字段（如bio_short、level）反向冗余回users主表，用触发器或应用层双写保证一致（适合变更不频繁的场景）
别指望中间件（如 MyCat、ShardingSphere）自动处理复杂 JOIN——它们对子查询、GROUP BY、ORDER BY 的下推能力有限，线上出过太多“语法通过、结果错乱、排查三天”的案例。
ALTER TABLE 已经卡住半天？说明拆分窗口期正在快速关闭
当你发现 ALTER TABLE users ADD COLUMN last_login_ip VARCHAR(45) 需要 2 小时以上，或者 OPTIMIZE TABLE 直接被 kill，基本意味着这张表已不适合在线 DDL。Percona Toolkit 的 pt-online-schema-change 在单表超千万行时也容易因复制延迟失败；MySQL 8.0 的 ALGORITHM=INSTANT 只支持加列、改列名等极少数操作，不支持加索引或修改列类型。
此时垂直拆分仍是最快止损手段——因为只需 CREATE TABLE users_light AS SELECT id, name, email FROM users（带 WHERE 条件可限流），再用 INSERT INTO ... SELECT 分批迁移，全程不影响主表读写。水平拆分则必须停写或切读写分离流量，代价更高。
真正容易被忽略的是统计信息同步：拆分后，旧表的 ANALYZE TABLE 结果不会自动更新到新表，优化器可能继续走错执行计划。每次迁移完一批数据，记得手动跑一次 ANALYZE TABLE users_light，别等上线后才发现 EXPLAIN 显示走了全表扫。
