大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
单表数据过了千万级，查询开始变慢。你说"该分库分表了"。老板问你能搞定吗，你说能。然后花了一个月搞完，上线后发现——跨分片查询慢得要命，有些查询根本没法写。
分库分表从来不是"拆了就快了"，拆之前想清楚三件事：怎么拆、怎么查、怎么扩。
第一招：怎么拆？三种分片策略各有坑
水平拆分：按行拆分
一张orders表拆成orders_0、orders_1、orders_2……各存一部分订单行。
最常用的分片键是user_id或order_id。拆分方式有三种：
Hash分片： 对分片键做hash，均匀分布到各个节点。优点是数据分布均匀，缺点是范围查询要跨所有分片。
范围分片： 按user_id区间划分，1-10000在节点A，10001-20000在节点B。优点是范围查询友好，缺点是新用户全堆在最新节点上（热点问题）。
列表分片： 按枚举值划分，比如按省份。广东的数据在节点A，北京在节点B。业务语义明确，但分布很难均匀。
核心坑：分片键选错，一切都白拆。 选分片键的标准——你80%的查询能不能只落在单个分片上？能，拆得对。不能，重新想。
垂直拆分：按列拆分
把一张宽表的冷热字段拆开。比如用户表经常查的是id、name、avatar，不太查的是address、id_card，那就拆成user_base和user_detail两张表。
好处是主表更瘦、热点数据缓存效率更高。坑是如果突然要连表查冷数据，多一次join。
第二招：怎么查？带了分片键和没带的差距
带了分片键的查询（精准路由）
SELECT * FROM orders WHERE user_id = 12345;
中间件直接算hash，定位到orders_3那张表，只查一个分片。性能无损。
没带分片键的查询（全分片广播）
SELECT * FROM orders WHERE status = 'PAID' AND create_time > '2025-01-01';
中间件不知道数据在哪个分片里，只能把这个查询广播到所有分片，每个分片各查一遍，再聚合结果。分片越多越慢。
核心原则：所有高频查询必须带分片键。不带分片键的查询，能少就少。
跨分片的关联查询
分库分表之后，跨分片的JOIN是噩梦。解决思路只有两条：要么把关联的数据冗余到同一个分片里（反范式设计），要么在应用层做二次聚合。
第三招：怎么扩？扩容不是加台机器那么简单
分库分表之后最怕的不是拆不动，是扩不动。
Hash分片扩容的经典问题
4个节点各存25%数据，Hash(user_id) % 4做路由。现在要扩到8个节点——所有数据的路由结果都变了，50%的数据要迁移。停服时间长、风险巨大。
解决思路：要么一开始就用一致性Hash，扩缩容影响小。要么用ShardingSphere等中间件的扩缩容方案，在线迁移。
动态扩容和缩容
业务高峰过后，流量下降。多余节点释放还是留着？释放需要数据迁移，留着浪费资源。需要在设计阶段就考虑弹性。
ShardingSphere实战要点
Apache ShardingSphere是目前最主流的分库分表中间件。三个关键配置：
# 1. 分片键和算法
sharding:
tables:
orders:
actualDataNodes: ds0.orders_$->{
0..3}
databaseStrategy:
standard:
shardingColumn: user_id
shardingAlgorithmName: database-inline
# 2. 广播表：每个分片都存一份全量（适合配置表、字典表）
broadcastTables: t_config, t_dict
# 3. 绑定表：关联表用同样的分片键分片，避免跨分片JOIN
bindingTables: orders, order_items
分库分表的三个灵魂拷问
在动手之前先问自己：
真的到单机上限了吗？ 索引优化做了吗？读写分离做了吗？缓存做了吗？很多时候不是数据量太大，是没优化好。
能不能先做垂直拆分？ 把冷热数据分开，比直接上水平拆分简单得多。
团队能维护分库分表吗？ 运维复杂度提升一个量级——备份、恢复、迁移、数据一致性校验，每条路都变难了。
分库分表是好工具，但不是第一选择。先优化、先缓存、先读写分离，实在扛不住了再拆。拆之前先想好分片键，比拆完再改分片键简单一万倍。
小耶在手，SQL不愁。
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
