在开发过程中，进行了主要密钥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提取碎片值。
对应于非夏季策略。