Sharding-JDBC查询踩坑&骚操作笔记

0 本文主要涉及

在Java 项目使用 Sharding-JDBC 3.0.0 版本对MySQL 5.8 中分表数据库表进行带括号和 or 条件数据查询遇到的一个Bug&解决方法

1 场景简介

一个稍微有点复杂的分表数据库数据查询场景，分表键是 user_id 64个分表，分表路由算法 user_id%64，比较特殊的是查询条件，类似下面这样（这里省略了其他查询条件），关键在带有括号和 or 的条件，以及带有分页参数（当然实际代码中这些条件和分页参数都是通过MyBatis动态生成的）

select * from table_a where user_id=111 and (status is null or status =1) limit 0,10

测试发现在前端页面上进行翻页操作是无效的，总是返回第一页的数据，而且多翻几次接口返回就超时了，经过打日志&断点 MyBatis 查看生成的 SQL 都没发现问题，后续又直接断点了 JDBC 最终生成的 SQL 和参数才发现，分页参数有异常，每次查询都变成了从 limit 0 开始，所以导致每次都是从头开始查而且越翻页查数据越多最后接口超时了

2 原因&解决方案

既然不是 MyBatis &更上层逻辑的问题，唯一可能出现问题的就是 Sharding-JDBC 了，最后通过搜索相关 bug 场景发，现了确实就是旧版本 Sharding-JDBC 的 Bug 导致
相关连接：
解析带括号里面的or条件无法解析 · Issue #279 · apache/shardingsphere · GitHub
Shardingjdbc分页 Limit 总是从0开始查询所有数据问题的解决办法

上述链接中博主的解决方案是对 Sharding-JDBC 进行了降级，不过好像老版本也是有问题的，而且目前由于该项目代码几经易手、逻辑复杂，贸然调整核心依赖版本风险较大；最后在和有经验同事的沟通后有了一个很离谱的解决方案，而且经测试在Sharding_JDBC 3.0.0版本下确实能行，只需对原有 SQL 关键字进行调整，如下：

select * from table_a where user_id=111 and (status is null || status =1) limit 0,10

就是把原 SQL 中的 or 关键词改为了或运算符 || (注意不是 | 位运算符)这样就能实现或条件的逻辑而 Sharding-JDBC 又能正常分页处理了，估计是全网独家方案了，不过有点过时，毕竟只支持 Sharding_JDBC 3.0.0版本的

具体原因就是 Sharding-JDBC 会对SQL进行语法解析，它不支持 || 语法，没解析出来，这样就不会触发原来 or 逻辑的 bug，但是 || 又能正常在 MySQL 数据库中作为 or 的逻辑 (注意 || 表示或运算是MySQL的方言，MySQL 5.8版本还支持，且不能开启PIPES_AS_CONCAT模式，看官网说后续版本可能会废弃)，通过这样卡 bug 的方式实现了代码逻辑（需要注意这里必须明确查询的 SQL 必需带有分表键，这样才能保证不把数据库打爆）
官网资料：
MySQL :: MySQL 5.7 Reference Manual :: 12.4.3 Logical Operators
MySQL :: MySQL 8.4 Reference Manual :: 14.4.3 Logical Operators

以及下面是 Sharding-JDBC 作者在Issues中的回复