ShardingSphere应用专题--4.1.1版本--Sharding-JDBC应用注意点（八）

前言：

1.基础的环境介绍请移步ShardingSphere应用专题–4.1.1版本–sharding jdbc环境搭建（四）
你可以同时打开两个页面，避免因查找原始配置上下翻动。

2.ShardingSphere官方文档更新不及时，很容易踩坑。贴出的4.x版本文档实际是4.0.1版本的，如果你准备使用该版本可以参考官方文档。本文使用的是此时最新的正式版本4.1.1版本，配置与官方文档配置不同。事实上，源码中有非常详细的版本配置文档，本文也是参考4.1.1 tag的源码配置。

3.ShardingSphere各版本差异很大，甚至核心依赖的包名都不一样，使用时，一定要确认使用哪个版本，目前调研的结果：3.x、4.0.1、4.1.1、5.0.0-alpha都存在很大的配置差异

个人测试

（1）测试点

根据官方文档，自己找了部分感兴趣的例子做了测试，以下是postman的测试请求截图：

（2）各场景测试结果

具体的sql点击

支持（但有bug）：官方声明支持，但实际存在bug
不支持：官方明确不支持
支持（需配置）：需要开启配置才能使用

测试用例名称	特点介绍	原生ORM环境	读写分离环境	分表环境	分库分表环境	分库分表+读写分离环境
插入		支持	支持	支持	支持	支持
批量插入		支持	支持	支持（但有bug）	支持（但有bug）	支持（但有bug）
根据id批量更新	包含case when	支持	支持	支持（但有bug）	支持（但有bug）	支持（但有bug）
根据id删除		支持	支持	支持	支持	支持
根据id查询		支持	支持	支持	支持	支持
根据billItemId查询billItem		支持	支持	支持	支持	支持
or及range测试		支持	支持	支持（需配置）	支持（需配置）	支持（需配置）
手动分页排序测试		支持	支持	支持	支持	支持
pageHelper排序分页测试		支持	支持	支持	支持	支持
简单聚合函数		支持	支持	支持	支持	支持
聚合函数嵌套去重	sum（distinct xx）	支持	支持	不支持	不支持	不支持
group by		支持	支持	支持	支持	支持
group by having		支持	支持	不支持	不支持	不支持
Union（All）		支持	支持	不支持	不支持	不支持
Join（不跨库）		支持	支持	支持	支持	支持
insertOnDuplicateKeyUpdate		支持	支持	支持（但有bug）	支持（但有bug）	支持（但有bug）
更新分库分表字段	支持	支持	不支持	不支持	不支持	不支持
根据id查询（包含mysql关键字）	关键字为‘text’	支持	支持	支持（但有bug）	支持（但有bug）	支持（但有bug）

补充：经测试，以上【支持（但有bug）】部分在5.0.0-alpha版本已经修复

批量插入的bug源码分析：

当为某个数据节点比如：master.bill_0做数据拼接时，原始的数据节点已经被路由引擎加工过了，比如路由到1，0，1，0，1，0
对应的id为7，8，9，10，11，12，这个满足设定的id%2的分表逻辑


然而当实际进行sql重写的时候，Parameters实际上是倒叙的，这就导致，本来要
1，0，1，0，1，0的路由本应对应的id为7，8，9，10，11，12
现在变成了1，0，1，0，1，0对应的id为12，11，10，9，8，7 就完全错误了
而如果批量插入个数是奇数，1，0，1，0，1且id生成策略刚好满足表交替，这个时候，数据就又神奇的对了，因为这个排列，倒着读和正读一样。。。

好在官方在5.0.0-alpha版本中已经修复了这个bug（我没有找到对应的issue，但是通过5.0.0-alpha测试了一下，发现parameters的成为正序了，数据也对了）

官方不支持项

参阅官方文档-sql使用规范

ShardingSphere应用注意点

• 虽然Sharing-JDBC已经支持绝大多数常用的甚至不常用的sql，但是仍然存在譬如Union（All），having子句等等不支持项。使用之前，应针对不支持项做接入前评估。如果你的项目存在大量这种不支持的语句，那么接入Sharing-JDBC的分库及分表功能，sql改写可能是场灾难。。。

• 对于老的项目，存在一定量的老数据，当接入ShardingSphere时，需要考虑老数据的维护问题，同理，当已经使用Sharding-JDBC做了分库分表项目，需要变更分库分表逻辑，让数据更加分散，比如原来拆成10个表，现在要拆成64个表。如何在保证不影响原项目运行的前提下，优雅的无感的解决老数据及增量数据是个难题。好在ShardingSphere 提供了Sharding-Scaling 用来专门处理这类问题，具体参阅：ShardingSphere应用专题–4.1.1版本–Sharding-Scaling实现弹性伸缩（十七）

• Sharding-JDBC是针对JDBC层做的增强，不依赖具体的ORM实现，对于接入方也提供了最大的兼容性

• 关于spring.shardingsphere.props.max.connections.size.per.query的配置,该配置直接影响底层是使用流式处理，还是串行。在系统线程允许的情况下，理论上：该数值的配置应大于最大分表数，才能保证库下面所有分表查询均可以使用流式处理，库级别系统默认都是开启新的线程处理，不受该参数影响

• 分页查询,分组查询 应针对查询的效率做详细的测试报告，目前官方该版本没找到这方卖弄的单项测试报告，官方测试报告。事实上，官方测试报告仅作为参考，系统接入前可以借助测试引擎定制自己系统的性能测试报告。这里可以参考使用【测试引擎】，使用示例可以参阅
  ShardingSphere应用专题–4.1.1版本–Sharding-JDBC测试引擎（TODO）

• join查询，应关注不要在分库分表过程中产生跨库关联。另外，优先使用广播表，如果不满足，尽量考虑使用绑定表