ThinkPHP分库分表需自定义Connection类重写getTableName()实现路由，而非仅用Db::connect()切换配置；须结合中间件绑定分片键、动态选库，并规避跨分片事务、count/join/group等不支持操作。
ThinkPHP 连接多个数据库时，Db::connect() 不会自动分表
直接调用 Db::connect('config_name') 只能切换配置，不能按业务规则把一张逻辑表（如 order）路由到不同物理库或不同后缀的表（如 order_01、order_02）。它只是“换连接”，不是“分片路由”。
常见错误现象：
– 写了多个数据库配置，但所有 order 查询都落到同一个库；
– 手动拼表名（如 "order_". $shard_id）后传给 table()，结果模型关联、自动时间戳、软删除等功能全部失效。
- 真正需要的是在 SQL 构建前拦截并重写表名 + 切换连接，而不是事后拼字符串
- ThinkPHP 6+ 的
think\db\Connection支持setTable()和setDatabase()，但这些方法不被模型自动调用 - 自定义连接类必须继承
think\db\Connection，并在getTableName()或parseSql()阶段介入
用中间件实现分库分表路由，关键在请求上下文绑定
中间件本身不处理 SQL，但它可以提前解析 URL、参数或 Header，把分片键（如 user_id）存入 Request 或 Container，供后续 DB 层读取。否则分片逻辑会散落在各处，无法统一控制。
- 在中间件里用
$request->param('uid')或$request->header('X-Shard-Key')提取分片依据 - 把分片值写入
think\Container::getInstance()->bind('shard_key', $value)，确保模型和查询构造器都能访问 - 不要在中间件里直接调用
Db::connect()—— 此时连接尚未初始化，会触发默认连接池创建，导致后续分片失效 - 兼容性注意：TP6.1+ 的
Db门面是延迟绑定，但模型类（BaseModel）可能已提前加载，需在模型基类中重写getConnection()
自定义 Connection 类重写 getTableName() 是最稳的方案
ThinkPHP 在生成 SQL 前会调用连接对象的 getTableName() 方法，这里就是插入分表逻辑的黄金位置。相比改模型或重写查询器，它侵入最小、覆盖最全（包括 Db::name()、$model->table()、关联查询等）。
立即学习“PHP免费学习笔记（深入）”；
class ShardConnection extends \think\db\Connection
{
public function getTableName($name, $suffix = '')
{
$shard_key = Container::getInstance()->get('shard_key') ?: 0;
$shard_id = $shard_key % 4; // 简单取模分 4 片
$real_name = $name . '_' . str_pad($shard_id, 2, '0', STR_PAD_LEFT);
return parent::getTableName($real_name, $suffix);
}
}
- 必须在数据库配置中指定
'type' => 'app\common\db\ShardConnection'，否则 TP 仍用默认类 - 分库不能只靠改表名：还需重写
initConnect()或switchDatabase()动态选库，根据$shard_id查配置映射 - 事务跨分片会失败，TP 不支持分布式事务，遇到多表写入需提前判断是否同库同表，否则抛异常比静默错更安全
分库后 count()、join()、group() 几乎必然出问题
这些操作依赖全局视图或跨表扫描，而分库分表后数据物理隔离。TP 不会自动合并结果，也不会下发分布式查询。强行使用只会返回单库结果，且无任何警告。
-
count()：必须改用sum()汇总各分片结果，或引入 Elasticsearch 做聚合 -
join()：仅限同一库内表关联；跨库join在 MySQL 层就不支持，TP 不做翻译 -
group()：单库执行没问题，但若分组字段分布不均（如按create_time分组），结果会漏掉其他库的数据 - 最容易被忽略的是缓存键：TP 默认用完整 SQL 生成缓存 key，分表后不同分片的相同逻辑 SQL 会命中同一缓存，导致脏数据
分库分表不是加个配置就能跑，核心在于接受“某些 SQL 天然不支持”，然后在业务层兜底。比如把 count 拆成并发查再 sum，把跨库 join 拆成多次查询 + PHP 合并。工具能省力，但不能替你做架构取舍。
