shardingjdbc_学习笔记

sharding学习视屏教程

事务一致性问题(分表产生的跨节点带来的)

产生原因
数据库层上讲: 跨物理数据源节点 产生的分布工

跨节点更新

某个业务代码下多条DML语句并且在一个事务中 路由后发现不在同一个库下 ,因此产生了跨节点操作: 这是跨物理数据源节点
解决方案:
1.尽量避免维度的划分不合理,尽量在同一个分片上 而避免跨节点

• 如果实在避免不了 则采用

• 柔性事务方式 最大努力 最终一致性

• XA两阶段提交 (性能差)

• 链式提交方式 主要用于广播表
  2.考虑在应用的Service层来解决比如TCC,saga,消费最终一致性来解决

跨节点查询

1.尽量落在同一分片上,避免跨节点查询
2.如果实在避免不了,则在应用的Servei层做微服,分别查出数据做merger操作

垂直与水平拆分

扫盲

• 垂直拆库:业务功能单元拆分,专库专用,不同业务模块彼此隔离
  垂直拆表拆的是表结构字段,按访问热度拆,访问频率高的放一起比如商品列表,商品详情 列表访问高 详情访问低频
• 水平拆库
  - 水平拆表
  如下图所示 商品与店铺按功能模块做了垂直分库
  而商品又根据 store_id 取模分库后 根据product_id分表
  即库的分片键与表的分片键可以不一样
  
  单纯的垂直分库是无法解决单库压力大的问题,会造成数据不均衡,因此有必要进行 垂直与水平相结合的方式

分库分表带来问题

• 事务-致性问题
• 跨节点join问题
• 跨节点分页 排序、函数，主键需要全局唯一,公共表

解决:
1.上来进行垂直分库业务解耦
2.不要急着水平分库,先从缓存入手,不行 再考虑读写分离
3.最后考虑水平分库分表,单表数据在1000万以内

解析

路由

bindingTable

binding配置

要注意两点

• binding-tables[0] 有一个数组 如果只有一个系列的绑定表不能省略数组 写成这样是错的
  spring.shardingsphere.sharding.binding-tables =
  product_info,product_descript
  应用配置配错了spring.shardingjdbc.sharding.binding-tables[0] 配成了shardingjdbc的前缀导致自动装配无法装配绑定表,并且启动也不报错就是路由时执行能慢点儿 然后硬说绑定表未生效 后来发现自己配错了 晕

#设置product_info,product_descript为绑定表
spring.shardingsphere.sharding.binding-tables[0] = product_info,product_descript
spring.shardingsphere.sharding.binding-tables[1] = product_info,product_descript

绑定表不产生笛卡尔积

无笛卡尔积

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
当t_order 与t_order_item 配置了bindingTable后

//以t_order为主进行分片 没有笛卡尔积
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

主表在前以主表为主

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

• 以主表 t_order的路由分布为主
• 即使两个t_order t_order_iterm两个表的分片ID不一样,也以主表t_order为主
• 绑定表路由源码逻辑
  
  "只有一个逻辑表 或 是绑定表"的话 就取逻辑表的第一个作为路由
  shardingTableNames.iterator().next()

不绑定则会产生笛卡尔积

如果没有进行bindingTable那么进行迪卡尔积计算,所有的目标库进行排列组合

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

hint指定库表

HintManager instance = currHintManager.get();
instance.addDatabaseShardingValue("t_order",new HintComparavleValue("ds_1"));
instance.addTableShardingValue("t_order",new HintComparavleValue("t_order_0","t_order_1"));

获得表分布

Map<String, Set<String>> result = new HashMap<String,Set<String>>();
            ShardingRule shardingRule = ((ShardingDataSource) dataSource).getRuntimeContext().getRule();
            TableRule tableRule = shardingRule.getTableRule(logicTableName);
            List<DataNode> list =  tableRule.getActualDataNodes();

            for (DataNode node : list ){
                if (result.containsKey(node.getDataSourceName())){
                    Set<String> tableSet = result.get(node.getDataSourceName());
                    tableSet.add(node.getTableName());
                } else {
                    Set<String> tableSet = new HashSet<>();
                    tableSet.add(node.getTableName());
                    result.put(node.getDataSourceName(),tableSet);
                }
            }
            return result;

时间滚动

时间滚动的几种形式

代码结构

代码地址

改写

正确性改写

表名替换 聚合函数改写 avg改成 sum account
分页改写

SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10
改写后的值-->会导致性能慢
SELECT * FROM t_order ORDER BY id LIMIT 0, 1000010
应用最好写成这样 用一个自增有序的id做为条件,把前面的跳过去
SELECT * FROM t_order WHERE id > 100000 LIMIT 10
或者这样
SELECT * FROM t_order WHERE id > 100000 AND id <= 100010 ORDER BY id

优化性改写

order by 排序补列
group by 排序补列 并且补列order by 而走流式
主键自动生成 补主键列 ,补占位符? 通过修改语法树的列节点和binding

执行-连接的管理

内存限制模式(OLAP)

即每个表一个连接,通过多线程方式并发查询进行流式结果集合并, 通常是面向统计类需求即OLAP 最大限度提升吞吐量
内存限制模式会出现死锁,sharding团队也成功的解决了,死锁的场景为:

改变是获取连接的时候进行同步锁

附:
加锁会降低并发 sharding也考虑了 并不是任何场景都加锁
1.如果是面向OLAP的场景,并且选择了内存限制模式 发现路由结果为 这个库下的一个表 那么不用加锁 只有路由同个库下的两个表时才加锁,因为按表建立连接,两张表不加锁就会发生上图死锁
2.如果是面向OLTP的场景,那么一定是按库建连接,这时连接会复用,不必要加锁

连接限制模式(OLTP)

即一个库下有20张表要访问处理的话,会只创建一个连接复用串行的处理(如果目标库为多个库仍然一个库一个连接并发处理),该模式通常带有分片键严格控制数据库连接,以保证本地事务

具体使用哪种模式看已使用的连接数 来平衡更合理 有一个平衡策略:

maxConnectionsSizePerQuery

具体的说明地址

结果集归并

流式结果集

流式结果集排序,游标比较后下移 一边操作一边排序
特点:
不会一下将所有的结果集装入内存,极大节省内存消耗

装饰者归并???

group分组归并

SELECT name, SUM(score) FROM t_ score GROUP BY name ORDER BY name;
它可以进进流式归并 与 内存归并

• 流式归并:要求分组字段 与 排序字段 必须保持一致 这样每个库执行都是排序的 具体原理通过 通过 优先级队列比较后 进行游标下移来进行流式归并 流式归并的前提条件为 fetchsize打开
• 内存归并: 如果排序字段没有 或者 不是分组字段 则直接进行内存归并(消耗内存)
  流式归并
  group by name order by sum(score) 这种走内存归并 (一)
  group by name order by name 这种走流式归并 (二)
  group by name 这种会进行order by 补列 进行流式归并(三)
  即只有(一) 这种情况会走内存
  orderby groupby limit 分页的改写 都可以走流式
  特别是分页这块儿 要加一处全局自增的ID做为查询条件索引变快

装饰器模式
是指处理聚合函数 三种类型，比较，求和和平均值 也是基于流式

我的问题:
1.装饰器到底是啥? 处理聚合函数的吗 怎么样能通俗话解释
2.迭代是指内存归并吗
3.如果order by id后走流式问题不会太大,排序也在数据库端 xx说不靠谱,面向OLAP的还可以,面向OLTP的不行啊

雪花算法

关于sharding雪花算法具体说明

配制

配制分片算法

inline的spring配置

spring.shardingsphere.sharding.binding-tables[0]=device,xxx其它表
spring.shardingsphere.sharding.tables.device.actual-data-nodes=ds${0..1}.device_$->{0..1}
#库规则
spring.shardingsphere.sharding.tables.device.database-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.device.database-strategy.inline.algorithm-expression=ds$->{id % 2}
#spring.shardingsphere.sharding.tables.device.database-strategy.inline.algorithm-expression=ds$->{Math.abs(id.hashCode() + device_name.hashCode()) % 2}
#表规则
spring.shardingsphere.sharding.tables.device.table-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.device.table-strategy.inline.algorithm-expression=device_$->{Math.abs(String.valueOf(id).hashCode()) % 2}
#雪花算法
spring.shardingsphere.sharding.tables.device.key-generator.column=id
spring.shardingsphere.sharding.tables.device.key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.tables.device.key-generator.props.worker.id=123

• inline 不支持范围查询

比如id为分片键不支持 select * from student where id between 1 and 5;

• inline 不支持多个分片键

比如两个分片键路由user_id,id作为分片键不支持
select * from t_order where id=100 and user_id=1000;

• 分片键可以支持in查询
  select * from student where id in(1,2,3); 是完全没问题

标准standard的spring配置

spring.shardingsphere.sharding.binding-tables[0]=xxxdevicexxx,xxx
spring.shardingsphere.sharding.tables.xxxdevicexxx.actual-data-nodes=ds${0..1}.xxxdevicexxx_$->{0..1}
#ds0库下的xxxdevicexxx_0001,xxxdevicexxx_0002一直到xxxdevicexxx_1024
#spring.shardingsphere.sharding.tables.xxxdevicexxx.actual-data-nodes=ds0.xxxdevicexxx_$->{ def list = []; (1..1024).each{element-> list << String.format("%04d",element)}; list}
#库的分片规则
spring.shardingsphere.sharding.tables.xxxdevicexxx.database-strategy.standard.sharding-column=id
spring.shardingsphere.sharding.tables.xxxdevicexxx.database-strategy.standard.precise-algorithm-class-name=com.xxx.StandardDbPreciseAlgorithm
spring.shardingsphere.sharding.tables.xxxdevicexxx.database-strategy.standard.range-algorithm-class-name=com.xxx.StandardDbRangeAlgorithm
#表的分片规则
spring.shardingsphere.sharding.tables.xxxdevicexxx.table-strategy.standard.sharding-column=id
spring.shardingsphere.sharding.tables.xxxdevicexxx.table-strategy.standard.precise-algorithm-class-name=com.xxx.StandardTbPreciseAlgorithm
spring.shardingsphere.sharding.tables.xxxdevicexxx.table-strategy.standard.range-algorithm-class-name=com.xxx.StandardTbRangeAlgorithm

• standard 不支持多个分片键
  比如两个分片键路由user_id,id作为分片键不支持
  select * from t_order where id=100 and user_id=1000;
• standard可以支持in查询,会多次调用standard算法返回库表
• standard支持范围查询即select * from t_date where date>=‘2020-01-01’ and date <=‘2020-07-01’ 具体可参考下方链接
• shardid is not null是不会进入standard算法的

具体的算法连接为

复杂complex的spring配置

spring.shardingsphere.sharding.tables.xxxcomplex_ricexxx.actual-data-nodes=ds${0..1}.xxxcomplex_ricexxx_$->{0..1}
#ds0库下的xxxcomplex_ricexxx_0001,xxxcomplex_ricexxx_0002一直到xxxcomplex_ricexxx_1024
#spring.shardingsphere.sharding.tables.xxxcomplex_ricexxx.actual-data-nodes=ds0.xxxcomplex_ricexxx_$->{ def list = []; (1..1024).each{element-> list << String.format("%04d",element)}; list}
#库的分片算法
spring.shardingsphere.sharding.tables.xxxcomplex_ricexxx.database-strategy.complex.sharding-columns=id
spring.shardingsphere.sharding.tables.xxxcomplex_ricexxx.database-strategy.complex.algorithm-class-name=com.xxx.ComplexDbAlgorithm
#表的分片算法
spring.shardingsphere.sharding.tables.xxxcomplex_ricexxx.table-strategy.complex.sharding-columns=id
spring.shardingsphere.sharding.tables.xxxcomplex_ricexxx.table-strategy.complex.algorithm-class-name=com.xxx.ComplexTbAlgorithm

• 支持in查询会调用多次 batchInsert插入 多个values时 一条value会调用一次complex的算法 比如有5条values的话那么就会调用5次complex的算法
• shardid is not null是不会进入complex算法的
• 支持多个分片键,id和user_id
• standard支持范围查询即select * from t_date where date>=‘2020-01-01’ and date <=‘2020-07-01’ 具体可参考下方链接

算法参考地址为

hint的spring配置

spring.shardingsphere.sharding.tables.xxxtest_sqlxxx.actual-data-nodes=ds${0..1}.xxxtest_sqlxxx
spring.shardingsphere.sharding.tables.xxxtest_sqlxxx.database-strategy.hint.algorithm-class-name=com.xxx.shardingsample.common.algorithm.HintDbAlgorithm
spring.shardingsphere.sharding.tables.xxxtest_sqlxxx.table-strategy.hint.algorithm-class-name=com.xxx.shardingsample.common.algorithm.HintTbAlgorithm

具体的hint测试案例地址为

default的默认配置

#默认inline表达式算法 库表分片规则
spring.shardingsphere.sharding.default-database-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.default-database-strategy.inline.algorithm-expression=ds$->{id % 2}
spring.shardingsphere.sharding.default-table-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.default-table-strategy.inline.algorithm-expression=device_$->{id % 2}
#default 默认数据源
spring.shardingsphere.sharding.default-data-source-name=ds0
#default 默认雪花算法
spring.shardingsphere.sharding.default-key-generator.column=id
spring.shardingsphere.sharding.default-key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.default-key-generator.props.worker.id=123


###########################################
默认standard标准算法库分片
spring.shardingsphere.sharding.default-database-strategy.standard.sharding-column=device_name,id
spring.shardingsphere.sharding.default-database-strategy.standard.precise-algorithm-class-name=com.xxx.shardingsample.common.algorithm.StandardDbPreciseAlgorithm
spring.shardingsphere.sharding.default-database-strategy.standard.range-algorithm-class-name=com.xxx.shardingsample.common.algorithm.StandardDbRangeAlgorithm
默认standard标准算法表分片
spring.shardingsphere.sharding.default-table-strategy.standard.sharding-column=id
spring.shardingsphere.sharding.default-table-strategy.standard.precise-algorithm-class-name=com.xxx.shardingsample.common.algorithm.StandardTbPreciseAlgorithm
spring.shardingsphere.sharding.default-table-strategy.standard.range-algorithm-class-name=com.xxx.shardingsample.common.algorithm.StandardTbRangeAlgorithm

默认complex标准算法库分片
spring.shardingsphere.sharding.default-database-strategy.complex.sharding-columns=id
spring.shardingsphere.sharding.default-database-strategy.complex.algorithm-class-name=com.xxx.shardingsample.common.algorithm.ComplexDbAlgorithm
默认complex标准算法表分片
spring.shardingsphere.sharding.default-table-strategy.complex.sharding-columns=id
spring.shardingsphere.sharding.default-table-strategy.complex.algorithm-class-name=com.xxx.shardingsample.common.algorithm.ComplexTbAlgorithm
默认hint算法库分片
spring.shardingsphere.sharding.default-database-strategy.hint.algorithm-class-name=com.xxx.shardingsample.common.algorithm.HintDbAlgorithm
默认hint算法表分片
spring.shardingsphere.sharding.default-table-strategy.hint.algorithm-class-name=com.xxx.shardingsample.common.algorithm.HintTbAlgorithm
默认none无算法库分片
spring.shardingsphere.sharding.default-database-strategy.none=
默认none无算法表分片
spring.shardingsphere.sharding.default-table-strategy.none=

有关于默认库与单库单表的测试案例地址说明

打印日志

spring.shardingsphere.props.sql.show=true

配置单表多表

配置单库单表

配置单库多表

#单库多表
spring.shardingsphere.sharding.binding-tables[0]=device
spring.shardingsphere.sharding.tables.device.actual-data-nodes=ds0.device_$->{0..1}
spring.shardingsphere.sharding.tables.device.table-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.device.table-strategy.inline.algorithm-expression=device_$->{id % 2}
spring.shardingsphere.sharding.tables.device.key-generator.column=id
spring.shardingsphere.sharding.tables.device.key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.tables.device.key-generator.props.worker.id=123
spring.shardingsphere.props.sql.show=true

具体的详细的配置地址

配置多库多表

#多库多表
spring.shardingsphere.sharding.binding-tables[0]=device
spring.shardingsphere.sharding.tables.device.actual-data-nodes=ds${0..1}.device_$->{0..1}
spring.shardingsphere.sharding.tables.device.database-strategy.inline.shardingColumn=id
spring.shardingsphere.sharding.tables.device.database-strategy.inline.algorithmExpression=ds$->{id % 2}

spring.shardingsphere.sharding.tables.device.table-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.device.table-strategy.inline.algorithm-expression=device_$->{Math.abs(String.valueOf(id).hashCode()) % 2}
spring.shardingsphere.sharding.tables.device.key-generator.column=id
spring.shardingsphere.sharding.tables.device.key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.tables.device.key-generator.props.worker.id=123

具体配置连接

配置多库多表读写分离

详见链接

不支持SQL

不支持SQL	原因
CASE WHEN	不支持case when
SELECT COUNT(*) FROM (SELECT * FROM t_order o)	支持
SELECT COUNT(*) FROM (SELECT * FROM t_order o where o.id in(SELECT id FROM t_order WHERE status = ?)) —即子查询嵌套不支持	不支持
INSERT INTO tbl_name (col1, col2, …) VALUES(1+2, ?, …)	value里有运行符不支持
INSERT … SELECT	insert into … select 是不支持的
SELECT COUNT(col1) as count_alias FROM tbl_name GROUP BY col1 HAVING count_alias > ?	having是不支持的
SELECT * FROM tbl_name1 UNION SELECT * FROM tbl_name2	union是不支持的
SELECT * FROM tbl_name1 UNION ALL SELECT * FROM tbl_name2	union all不支持的
SELECT * FROM ds.tbl_name1	不能包含库名
sum(distinct colum1), sum(column1) from tab	不支持两种聚合函数同时使用
sum(distinct colum1) from tab	这个是支持的
把distinct 给改写成group by的一种方式也是可以考虑	aa

distinct支持的语句

SELECT DISTINCT * FROM tbl_name WHERE col1 = ?
SELECT DISTINCT col1 FROM tbl_name
SELECT DISTINCT col1, col2, col3 FROM tbl_name
SELECT DISTINCT col1 FROM tbl_name ORDER BY col1
SELECT DISTINCT col1 FROM tbl_name ORDER BY col2
SELECT DISTINCT(col1) FROM tbl_name
SELECT AVG(DISTINCT col1) FROM tbl_name
SELECT SUM(DISTINCT col1) FROM tbl_name
SELECT COUNT(DISTINCT col1) FROM tbl_name
SELECT COUNT(DISTINCT col1) FROM tbl_name GROUP BY col1
SELECT COUNT(DISTINCT col1 + col2) FROM tbl_name
SELECT COUNT(DISTINCT col1), SUM(DISTINCT col1) FROM tbl_name
SELECT COUNT(DISTINCT col1), col1 FROM tbl_name GROUP BY col1
SELECT col1, COUNT(DISTINCT col1) FROM tbl_name GROUP BY col1

换数据源

配置中心变了之后 触发DalDataSource的 refresh()

应用得注意的点

SQL语句中别使用schema

还不支持在DQL和DML语句中使用Schema ,
select * from ds_0.t_order #这种是不支持的

分页的性能优化

select * from t_order order by id limit 1000000,10
select * from t_order order by id limit 0,1000010 (改写后)
建议的性能优化: select * from t_order where id>1000000 and id<1000010 order by id
或者 select * from t_order where id>1000000 limit 10

不支持的SQL

CASE WHEN ,HAVING,UNION(ALL)

不支持

特殊的子查询

子查询中包含数据表的子查询

select count(*)
from (select * from order o where o.id in(select id from order where status=?)) --这种不支持
具体地址说明
https://shardingsphere.apache.org/document/legacy/4.x/document/cn/features/sharding/use-norms/sql/

子查询上包含聚合函数不支持

非默认库下的单库单表子查询支持

比如默认库为ds0,ds1上的单库单表的子查询不支持

--子查询在form
select pen.*
  from pen, (select * from card where myname = 'xxx') ca
 where pen.name = ca.myname;
 --子查询在column
select id,( select myname from card where myname='xxx') as name from pen where pen.id=1
 --子查询在where
select * from pen where name in(select myname from card where myname='maqingbin')

默认库为ds0
ds1上有两张单表 pen 和 card 配置如下

spring.shardingsphere.sharding.tables.pen.actual-data-nodes=ds1.pen
spring.shardingsphere.sharding.tables.card.actual-data-nodes=ds1.card
spring.shardingsphere.sharding.default-data-source-name=ds0

分片键在聚合函数或运算表达式,会全表扫

select * from t_order where to_date(create_time,‘yyyy-mm-dd’)=‘2019-01-01’
create_time在聚合函数中 不会指定,而会全表扫描

关于distinct

基本上全支持了,只有极个性的场景不支持,即普通聚合函数和disninct聚合函数同时使用不支持
select sum(distinct col1),sum(col2) from tb_name 即这种不支持

接入的出现问题

metadata导致的启动慢

metadata的原理说明

• 要么将metadata缓存,如果直接缓存,连接还是持有的
• 京东的实战连接

metadeta的配置说明

#要么将设置为false 即不进行元数据的检查 默认为fasle
spring.shardingsphere.check.table.metadata.enabled =false
#并行执行默认为1,把数量改大点
spring.shardingsphere.props.max.connections.size.per.query=50

metadata的源码修改说明

源码修改连接地址

配置配错了总说找不到分表

由于对%2后产生数据倾斜

库为ds0 表为device_0,device_1
库为ds1 表为device_0,device_1
1.由于库的分片键与 表的分片键相同并且取模规则也相同
如果id%2=0 则最终数据总会落到ds0.device_0上 ,那么ds0.devie_1就会浪费
如果id%2=1 则最终数据总会落到ds1.device_1上 ,那么ds1.devie_0就会浪费

解决这种情况为:

• 库按id直接取模 即 id%2
• 表按id字符串后的hashCode来取模 即String.values(id).hashCode() %2
  由于取hashCode会有负值所以要加上Math.abs()进行绝对值一下
  具体的配置如下:

spring.shardingsphere.sharding.tables.device.actual-data-nodes=ds${0..1}.device_$->{0..1}
spring.shardingsphere.sharding.tables.device.database-strategy.inline.shardingColumn=id
spring.shardingsphere.sharding.tables.device.database-strategy.inline.algorithmExpression=ds$->{id % 2}
spring.shardingsphere.sharding.tables.device.table-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.device.table-strategy.inline.algorithm-expression=device_$->{Math.abs(String.valueOf(id).hashCode()) % 2}

4.1.1版本出现的问题测试结论

我们整理的测试结果

4.0.1_hintManager.setDatabaseShardingValue的Bug

StandardRoutingEngine.java
下面区域的注释代码为4.0.1版本有BUG即分库不分表时 有问题,4.1.0之后修复了

private List<RouteValue> getDatabaseShardingValuesFromHint() {
//        return getRouteValues(HintManager.getDatabaseShardingValues(logicTableName));
        return getRouteValues(HintManager.isDatabaseShardingOnly() ? HintManager.getDatabaseShardingValues() : HintManager.getDatabaseShardingValues(logicTableName));
    }

select count 解析不出表名

select count(1) count from xxtabxx 解析不出表名
变通的解决方式为  通过  as 给count起别名
select count(1) as count from xxtabxx

只有 select count(1) 有这个问题 select name myname from tab 这种是没问题的
如果解析不出表名,则会走默认路由

random随机选择数据源

如果没有配置表规则, 并且也没有配置默认库,那么就会走随机策略

各种异常

关于连接关闭的异常

关于连接释放
spring–sharding-druid的关系