PHP手动分表路由需在应用层实现，核心是重写数据库连接类的getTableName()方法，根据分片键（如user_id）动态生成物理表名，避免硬编码；分片键须从统一入口提取，严禁跨分片操作。
PHP 本身不提供原生分库分表能力，所有可行方案都绕不开「路由逻辑下推到应用层」或「交由中间件代理」——前者可控但易出错，后者省心但引入外部依赖。别信“一行代码自动分片”的宣传，真正在生产扛住千万级数据的，都是在getTableName()里抠细节，或在ShardingSphere-Proxy配置里反复调参的结果。
怎么用 PHP 手动实现分表路由（无中间件）
这是中小项目最常用、也最容易失控的方式。核心是拦截 SQL 构建前的表名生成环节，而不是事后拼字符串。
- 直接在模型里写
$this->table('user_' . ($uid % 16))会导致关联查询、软删除、时间戳等全部失效——因为 ThinkPHP/Laravel 的底层机制只认逻辑表名 - 必须重写数据库连接类的
getTableName()方法，在这里根据当前上下文（如 Request 中绑定的user_id）动态返回物理表名 - 分片键不能硬编码进 SQL，得从统一入口提取：比如中间件中解析
$_GET['uid']或 Header 中的X-Shard-Key，再存入Container::getInstance()->bind('shard_key', $value) - 避免跨分片操作：
COUNT(*)、JOIN、GROUP BY在手动分片下基本不可靠，要么改用 ES 聚合，要么在应用层收拢结果再计算
为什么连 ShardingSphere-Proxy 要特别注意 PDO 配置
PHP 连 ShardingSphere-Proxy 看似只是换了个端口（默认 3307），但几个配置点不调对，立刻报错或路由失败。
- 必须禁用 PDO 的模拟预处理：
PDO::ATTR_EMULATE_PREPARES => false，否则INSERT INTO user VALUES (?, ?)会被 PDO 自行转义，Proxy 无法识别分片键 - 不能用参数化
LIMIT ?, ?，Proxy 5.x 对该语法解析不稳定，得写成LIMIT 0, 20字面量 - 数据库名必须填逻辑库名（如
sharding_db），不是物理库名（ds_0、ds_1）；表名也只写逻辑表名（t_user），不能带后缀 -
JOIN多表时，ON 条件字段必须全是分片键，比如ON u.user_id = o.user_id，否则 Proxy 直接拒绝执行并抛出Cannot route inputs
取模分表 vs 时间分表：选错策略比写错代码更难救
分片策略一旦上线，改起来成本极高。两种主流方式适用场景差异极大，不能凭直觉拍板。
立即学习“PHP免费学习笔记（深入）”；
- 取模（
$id % 8）适合用户 ID、订单号这类高基数、均匀分布的字段，能保证写入负载分散，但彻底丧失按时间范围查询的能力 - 时间分表（
order_202604）天然支持归档、冷热分离和按月统计，但容易产生热点——比如每月 1 号零点大量订单涌入同一张表，IO 扛不住 - 混合策略更实用：先按
user_id % 4分库，再按create_time月度分表，但要求所有查询必须带user_id和时间范围，否则查不到数据 - 别用
create_time单独做分片键——它不是高基数字段，且新老数据访问频次差异大，极易导致数据倾斜和查询抖动
全局 ID 怎么生成才不拖慢插入性能
自增主键在分库分表下彻底失效，但随便上 UUID 或 Redis 自增会成为性能瓶颈。
- UUID（v4）字符串太长，索引体积翻倍，InnoDB 页分裂加剧，QPS 上千就明显卡顿
- Redis INCR 每次插入都要网络往返，压测时 RT 直接从 2ms 涨到 15ms+
- 推荐号段模式（Leaf-segment）：一次从 DB 拿 1000 个 ID 缓存在内存，用完再取，吞吐轻松过 5w/s；或者本地雪花算法（Snowflake），需确保机器时钟不回拨
- 如果业务允许，用
user_id + 时间戳高位拼接也能满足唯一性，且天然有序，利于范围扫描
真正难的从来不是“怎么分”，而是“怎么让分了之后的系统还能像单库一样可查、可联、可监控”。分片键一旦写死，后续加字段、改查询、做迁移，全得围着它转。上线前务必用真实流量压测路由逻辑，尤其关注跨分片事务失败时的补偿路径是否闭环。
