拆分大表是 MySQL 项目中常见的结构优化手段，核心目标是提升查询性能、降低锁竞争、加快备份恢复，并改善整体可维护性。关键不在于“要不要拆”，而在于“怎么拆更合理”——需结合业务读写特征、数据增长规律和关联关系综合判断。
按业务逻辑垂直拆分（字段级）
适用于宽表（字段数多、部分字段访问频次低或更新不频繁）。把大表中相对独立的业务属性分离成新表，通过主键关联。
例如：用户表users含基本信息（name、phone）、认证信息（password_hash、salt）、扩展资料（avatar_url、bio、settings_json），可将认证字段拆到
user_auth表，扩展资料拆到
user_profiles表 注意保持外键一致性（MySQL 8.0+ 支持外键约束，但高并发下建议应用层保障） 避免过度拆分——若 90% 查询都需 JOIN 3 张表，反而增加复杂度和延迟
按时间或范围水平拆分（行级）
适合数据量持续增长、历史数据访问少的场景（如订单、日志、消息记录）。常见策略有分区表（Partitioning）和分表（Sharding）两种实现路径。
分区表（推荐优先尝试）：单表物理拆分，SQL 无需改写。例如按月对order_logs做 RANGE 分区：
PARTITION BY RANGE (YEAR(created_at) * 100 + MONTH(created_at))分表（需应用配合）：如按年拆为
orders_2022、
orders_2023，查询时由中间件或 DAO 层路由；注意跨年统计需 UNION 或汇总视图 慎用哈希分表——虽负载均衡好，但范围查询和排序成本高，且扩容困难
冷热分离与归档策略
不是所有数据都需要留在主库在线表中。识别访问热度，把低频数据迁出，是性价比最高的“轻量级拆分”。
定义“冷数据”标准：如 6 个月未更新、90 天无查询的订单明细；或状态为closed且创建超 1 年的记录 迁移方式：用
INSERT INTO ... SELECT+
DELETE分批操作（避免长事务锁表），目标可为归档库、列存引擎（如 ClickHouse）或对象存储（配合应用层异步加载） 保留归档索引表（如
order_archive_index），记录哪些 ID 已归档，供查询兜底使用
拆分后必须同步做的几件事
结构变了，配套机制必须跟上，否则容易引入新问题。
补全关联查询的覆盖索引，尤其在 JOIN 字段、WHERE 条件和 ORDER BY 字段上 检查并重写依赖原表结构的 SQL：视图、存储过程、定时任务脚本、ORM 映射（如 MyBatis 的 resultMap） 更新监控项：关注新表的慢查率、IO 吞吐、复制延迟（分表后主从延迟可能更敏感） 建立数据一致性校验机制，比如定期比对分表总行数、关键字段 sum 值，或使用 pt-table-checksum 工具
