ShardingSphere分片键查不到数据因SQL未显式命中分片列，仅支持裸列等值或IN查询；MyBatis需参数名与分片键严格一致；ORDER BY+LIMIT会归并排序导致性能差和结果不准，应改用游标分页。
ShardingSphere 的 sharding-column 为什么总查不到数据？
因为分片键（sharding-column）在 SQL 中没被显式命中，或被隐式改写绕过了。ShardingSphere 不会解析 WHERE 条件里的表达式、函数或子查询，只认字面量匹配的等值或 IN 查询。
常见错误现象：SELECT * FROM order WHERE DATE(created_time) = '2024-01-01' —— 这个 created_time 虽是分片键，但套了 DATE() 函数，路由直接失效，查全库；又或者用 LIKE '2024%' ，同样不触发分片。
- 必须保证分片键出现在 WHERE 中，且是裸列 + 等号/IN，如
WHERE order_id = 123或WHERE user_id IN (101, 102) - 避免在分片键上用函数、类型转换、拼接（如
CONCAT('u', user_id)）、别名引用（SELECT user_id AS uid FROM t WHERE uid = 1不行） - 如果业务真要按时间范围查，得把分片键设为
date_str字段（如 '20240101'），而不是依赖created_time时间戳字段做路由
MyBatis 里怎么传参才能让 Sharding 正确路由？
MyBatis 的 #{} 是安全的，但如果你用了 ${} 拼接，或者参数是 Map 且 key 名和分片键不一致，路由就断了。
使用场景：Spring Boot + MyBatis + ShardingSphere-JDBC，DAO 层用 @Select("SELECT * FROM order WHERE order_id = #{orderId}")，但查出来是全库扫描。
- 确认 XML 或注解中参数名和实体类/Map 的 key 完全一致，比如分片键是
order_id，那必须写#{order_id}，不能写#{id}即使值一样 - 避免在 DAO 方法里用
@Param("xxx")重命名，除非你同步更新了分片策略配置里的sharding-column映射 - 批量插入时，
<foreach></foreach>里的item必须带明确属性，如#{item.order_id}；如果 item 是 Map，key 得是"order_id"字符串，不能是"orderId"
分库分表后 ORDER BY 和 LIMIT 为什么变慢还结果不准？
因为 ShardingSphere 默认做归并排序，不是下推到各分片执行完再合并——它只保证最终逻辑正确，不保证性能或分页语义。
典型表现：SELECT * FROM order ORDER BY create_time DESC LIMIT 20,10，返回结果跳过条目、重复、甚至漏数据。
-
LIMIT的偏移量会被放大：假设 4 个分片，LIMIT 20,10实际会在每个分片取LIMIT 30,10，再内存归并，开销大且不准 - 解决办法优先用游标分页：
WHERE create_time ，把上次查到的最小时间当参数传下去 - 如果非用
OFFSET，调大props.sql-show和props.max-connections-size-per-query，但别指望它快；更关键的是，在分片策略里把create_time加进sharding-column或复合分片键，让时间范围尽量落在单分片内
MySQL 主从延迟导致 ShardingSphere 读写分离查不到刚写的记录？
不是 ShardingSphere 的锅，是它默认走负载均衡策略选从库，而主从同步有延迟。尤其在“写完立刻查”这种强一致性场景下，问题突出。
错误现象：用户注册（INSERT）后跳转详情页（SELECT），偶尔 404；日志显示 SELECT 发到了从库，但 binlog 还没追上。
- 最简单解法：对关键链路强制走主库，用
HintManager，如HintManager.getInstance().setWriteRouteOnly();，之后的 SQL 都发主库 - 不要依赖
transactional自动识别读写——ShardingSphere 的事务绑定只管连接，不管主从路由决策 - 如果用 Spring @Transactional，记得配置
default-read-only="false"并显式标注@Transactional(readOnly = true)的方法，否则所有事务内查询都可能被误判为只读
分片键设计、参数传递、归并逻辑、主从路由——这四个点卡住，Sharding 就不是加速器，而是黑盒放大器。尤其是复合分片策略里多个键的联动关系，一旦配置和实际 SQL 对不上，问题往往藏得深、复现难。
