在开发过程中,进行了主要密钥ID查询。结果,我遇到了以下错误:
原始的Sharding-JDBC碎片策略配置是:
上面的配置使用主密钥ID作为单个胶片密钥,是表达式的片段策略。此shard策略仅支持=和操作员,并且不支持范围查询。如果您想查询范围,则需要配置标准策略。
相应的配置:
对于具体问题,请参考。官方github上的问题问题:https://github.com/apache/shardingsphere/issues/4180
其他配置可以引用:https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/manual/sharding-jdbc/config-config-yaml/
对于特定的碎片算法类,您可以参考官方GitHub上的示例:https://github.com/apache/shardingsphere-example
碎片算法需要根据实际情况开发。这是官方示例中的实施类:
包括碎片和碎片算法,由于碎片算法的独立性,它是独立的。真正可用于碎片操作的是Shard Key + Sharding算法,即Sharding策略。目前提供5个片段策略。
对应于squl语句=,> ,,,, <, >= ,,, <=, IN和BETWEEN AND的分片操作支持。StandardShardingStrategy只支持单分片键,提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。PreciseShardingAlgorithm是必选的,用于处理=和IN的分片。RangeShardingAlgorithm是可选的,用于处理BETWEEN AND, >,,,, <, >= ,,, <=分片,如果不配置RangeShardingAlgorithm,SQL中的BETWEEN AND将按照全库路由处理。
对应ComplexShardingStrategy。复合分片策略。提供对SQL语句中的=, >,,,, <, >= ,,, <=, IN和BETWEEN AND的分片操作支持。ComplexShardingStrategy支持多分片键,由于多分片键之间的关系复杂,因此并未进行过多的封装,而是直接将分片键值组合以及分片操作符透传至分片算法,完全由应用开发者实现,提供最大的灵活度。
对应InlineShardingStrategy。使用Groovy的表达式,提供对SQL语句中的=和IN的分片操作支持,只支持单分片键。对于简单的分片算法,可以通过简单的配置使用,从而避免繁琐的Java代码开发,如: t_user_$->{U_ID%8}表示将T_USER表分为基于U_ID模型8的8个表,并且表名是T_USER_0到T_USER_7。
对应于hintshardingstrategy。通过提示指定碎片值,而不是从SQL提取碎片值。
对应于非夏季策略。