SQL表拆分分水平（按行）和垂直（按列）两种，旨在解决数据量大、查询慢、锁竞争高或业务耦合强等问题；水平拆分适用于数据持续增长的场景，如用户表、订单表，常用ID取模、时间范围或业务维度拆分；垂直拆分适用于宽表字段多、读写频率或安全等级差异大的场景，如将用户基础信息、敏感信息、统计字段分表；拆分前应优先通过索引优化、读写分离、缓存或分区表缓解问题，避免盲目拆分导致事务一致性难保障、跨库JOIN复杂、运维成本上升。
SQL表拆分主要分两种：水平拆分（按行拆）和垂直拆分（按列拆），目的都是为了解决单表数据量过大、查询慢、锁竞争高或业务耦合强的问题。选哪种，得看瓶颈在哪——是数据行太多？还是字段太杂、读写冲突多？
水平拆分：把一张表的行分散到多个结构相同的表里
适合场景：用户表、订单表、日志表等数据量持续增长、查询常带时间或ID范围条件的表。
- 按ID取模：比如 user_id % 4 = 0/1/2/3，拆成 user_0、user_1、user_2、user_3 四张表。简单易实现，但扩容时需重分布数据。
- 按时间范围：order_202401、order_202402……每张表存一个月订单。适合冷热分离，历史数据归档方便，但跨月查询要合并结果。
- 按业务维度：如按地区拆分（user_beijing、user_shanghai），前提是查询天然带地区条件，否则容易出现“全表扫描式路由”。
注意：拆完后主键可能重复，建议用全局唯一ID（如雪花ID）；应用层或中间件（如ShardingSphere、MyCat）需负责SQL路由和结果归并。
垂直拆分：把一张表的列按访问模式或业务归属拆到不同表中
适合场景：宽表字段多、读写频率差异大，比如用户表里既有基础信息（昵称、头像），又有敏感信息（身份证、银行卡）、还有统计字段（积分、等级）。
- 按读写频率拆：高频读写的字段（如 username、status）放 user_base 表；低频更新的字段（如 real_name、id_card）放 user_profile 表。
- 按安全等级拆：敏感字段单独建表并加强权限控制，避免普通查询意外暴露隐私。
- 按业务域拆：电商中把商品基本信息、库存、价格、评论分别拆表，便于团队分工维护和独立扩展。
拆完后通常保留一个公共主键（如 user_id）做关联，必要时用 JOIN 查询，但更推荐应用层分步查（减少跨表压力）。
别急着拆，先确认真需要
很多性能问题其实靠索引优化、读写分离、缓存或分区表（MySQL PARTITION）就能缓解。盲目拆分反而带来事务一致性难保障、跨库JOIN复杂、运维成本飙升等问题。
- 单表行数超千万且QPS高、慢查频发 → 可考虑水平拆分
- 单表字段超50个、常只查其中几列、部分字段更新频繁拖慢整体 → 垂直拆分更合适
- 先做压测和慢日志分析，明确瓶颈是IO、CPU、锁还是网络，再决定拆法
不复杂但容易忽略：拆分不是终点，后续得配套做数据同步、分页改写、分布式ID、监控告警，否则会埋下更大隐患。
