分库分表后WHERE不带分片键会导致全库扫描，性能急剧下降；解决方法是通过冗余映射表路由、引入ES/ClickHouse统一检索，或严格限制跨分片操作。
分库分表后，WHERE 条件里没带分片键，查询直接变全库扫描
这是最常踩的坑：比如按 user_id 分片，但业务查的是 email 或 phone，中间件（如 ShardingSphere-Proxy、MyCat）无法路由，只能把 SQL 发给所有库所有表。结果响应慢、连接打满、从库延迟飙升。
解决思路不是“强行让中间件猜”，而是提前约定：非分片键查询必须走冗余索引或异步归集。
- 在每个分片库中建
email_to_user_id映射表（带user_id），写入时双写，查询先查映射再路由到目标分片 - 对模糊搜索、后台报表等低频场景，用
Elasticsearch或ClickHouse做统一检索层，不走分库分表主库 - 禁止在核心交易链路中执行跨分片
JOIN或GROUP BY—— 中间件要么不支持，要么性能极差
ShardingSphere-JDBC 的 standard 分片策略怎么配才不翻车
很多人抄文档只配了 sharding-column 和 algorithm-expression，结果上线后发现 INSERT 正常，UPDATE 却报 Cannot route any table for xxx —— 因为没配 sharding-key 的 UPDATE 路由逻辑。
关键点是：分片算法必须覆盖所有 DML 操作的路由依据，且表达式里不能硬编码库/表名。
-
database-strategy.standard.sharding-column必须和table-strategy.standard.sharding-column一致（如都是user_id），否则 UPDATE 时库和表路由错位 - 算法表达式推荐用
t_user_$->{user_id % 4}这种动态计算，别写死成t_user_0～t_user_3，否则加库加表要改代码 - 如果业务有
SELECT * FROM t_user WHERE user_id IN (1, 2, 3)，确保sharding-algorithm支持IN拆解，老版本InlineShardingAlgorithm不支持，得换ComplexKeysShardingAlgorithm
手动计算分片键时，user_id 是字符串还是整数？类型不一致直接路由错库
PHP 里 intval("123abc") 返回 123，而 MySQL 的 CONVERT("123abc", SIGNED) 也返回 123，看似没问题。但遇到 "abc123"，PHP 返回 0，MySQL 返回 0，结果都路由到第 0 号库——可实际数据根本不在那里。
根源是分片键类型必须严格对齐，且校验前置。
- 入库前强制校验
user_id是否为纯数字：ctype_digit($user_id)，否则抛异常，不接受弱类型输入 - 分片计算统一用
bcmod($user_id, 8)（避免大整数溢出），不用%运算符 - 如果业务已存在字符串型 ID（如 UUID），别硬转数字，改用哈希：
abs(crc32($uuid) % 8)，并确保所有语言实现一致（PHP/Java/Go 的crc32结果要对得上）
跨分片分页（LIMIT 10000,20）为什么越往后越慢？
中间件会把 LIMIT 10000,20 拆成 LIMIT 0,10020 发给每个分片，汇总后内存排序再截取。100 个分片 × 10020 行 = 百万级临时数据，PHP 进程 OOM 是常态。
真实可行的方案只有两个：游标分页、或业务妥协。
- 用最大自增 ID 或时间戳做游标：
WHERE created_at > '2024-01-01' ORDER BY created_at LIMIT 20，每次请求带上次最后一条的created_at - 如果必须用偏移量，限制前端最多查到第 100 页（
LIMIT 2000,20），超限提示“请按条件筛选” - 绝对不要在分库分表场景下用
SELECT COUNT(*)做总条数——中间件会扫全库，改成近似值：维护一个shard_count表，每次写入后异步更新各分片行数
分片键的选择和使用贯穿整个查询生命周期，一旦定错，后期改造成本远高于初期多花两小时评审。尤其注意 PHP 的类型隐式转换、中间件的 SQL 解析边界、以及分页这类表面简单实则高危的操作。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
