标准分片表配置需确保sharding-column类型与物理列严格对齐：数值型用long/integer，时间类转时间戳long；分片键不可为null；inline算法变量名须完全一致；复杂分片仅用于多键联合查询且dosharding必须返回非空集合；广播表须顶层配置、手动建表、禁用分片键条件。
标准分片表怎么配才不踩 sharding-column 类型错的坑
标准分片（Single Sharding）最常出问题的是 sharding-column 类型和实际 SQL 中的值类型不一致，比如数据库字段是 BIGINT，但分片算法里拿 String 做模运算，结果所有路由都打到同一个真实表。
实操建议：
-
sharding-column必须和物理列类型严格对齐：数值型就用Long或Integer处理，别 toString() 后再 parse；时间类字段慎用LocalDateTime，优先转为时间戳long再分片 - 分片键不能是
NULL—— ShardingSphere 5.x+ 会直接抛SQLException: sharding value is null，应用层得兜底校验 - 如果用
InlineShardingAlgorithm，表达式里的变量名必须和sharding-column完全一致，大小写敏感，比如配置了user_id，就不能在algorithm-expression里写成user_id % 4以外的变体
复杂分片（ComplexKeysShardingAlgorithm）什么时候必须写，又为什么总路由错
当一条 SQL 同时涉及多个分片键（比如 WHERE user_id = ? AND order_time > ?），且无法用标准分片覆盖时，才需要复杂分片。但它不是“更高级”，而是“更难控”——一旦实现没覆盖全组合，就会漏数据或全库扫描。
实操建议：
- 只在确实存在多键联合查询场景下启用，比如按用户 + 时间范围查订单；单键查询还配复杂分片，纯属给自己加锁
-
doSharding方法里必须返回非空集合，空集合会被当成“无匹配表”，导致No tables to route错误；哪怕只命中一个表，也要 returnArrays.asList("t_order_0") - 注意
Collection<shardingvalue></shardingvalue>的遍历顺序不固定，别依赖先后；要用stream().filter(...).findFirst()显式提取user_id和order_time对应的值
广播表（broadcast-tables）配了却没生效？检查这三处
广播表本意是让某张配置表（如 dict_province）在所有分片库中都存在且数据一致，但常因配置位置或 DDL 同步问题变成“假广播”。
实操建议：
- 必须在
sharding-rule下的顶层配置broadcast-tables，写在tables或default-database-strategy里无效 - 建表语句得在每个真实库上手动执行一遍，ShardingSphere 不自动同步 DDL；少一个库没建，查询时就会报
Table 'xxx.dict_province' doesn't exist - 广播表不支持分片键，也不参与任何分片计算，所以它的 SQL 里不能出现
WHERE条件含分片键的逻辑（比如WHERE user_id = ?），否则会被当成普通分片表处理
spring.shardingsphere.rules[0].tables.t_order.actual-data-nodes 路径写法差异影响路由性能
这个配置项决定 ShardingSphere 如何展开真实表名，写法不同会导致初始化耗时差几倍，甚至影响连接池预热。
实操建议：
- 用
t_order_${0..3}比t_order_0,t_order_1,t_order_2,t_order_3更高效——前者是惰性解析，后者启动时就全量加载所有数据源连接 - 如果分片数动态变化（比如扩容到 8 个），别硬编码范围，改用
t_order_${0..7}并确保对应库表已存在，否则首次查询会触发TableNotFoundException - 路径里不能含数据库名前缀（如
ds_0.t_order_0），除非你启用了default-database-strategy；否则会误判为跨库查询，强制走合并引擎，拖慢简单查询
复杂分片和广播表的边界特别容易模糊——比如把字典表配成复杂分片，或者给广播表加分片键，这类配置不会报错，但会在某次 JOIN 或事务中突然暴露路由异常。留心那些“看起来能跑通”的配置。
