数据库是 Mysql 的,分表策略是 shardingColumn UUID % 表数量 确定这个租户是属于表几。 目前只需要查一个租户表的数据,测试数据量大约几十万,Dao 层查 50 多秒,单表查很快,为啥使用 shardingsphere 这么慢?
语句是一个时间的范围查询 select field1,field2,field3 FROM table where field1 = #{UUID} and time <= #{time}
1
LowBi 2022-08-20 22:00:48 +08:00 via Android
虽然业务不一样,但我直接放弃了 sharding 自带的查询,自己联库表,每个库表里子查询来减少查询范围。我的算是分裤分表较少的情况,建议加个子查询
|
2
unregister OP @LowBi select temp.*(select field1,field2,field3 FROM table_1 where field1 = #{UUID} and time <= #{time}) as temp 是这样处理的吗?这样在 navicat 里执行查询时间就变成几十秒了。还有这个 sharding-jdbc 我感觉也是索引失效了。
|
3
unregister OP KEY `idx_uuid` (`uuid`) USING BTREE,
KEY `idx_time` (`time`), 创建的索引这样的 |