terrymanu commented on issue #24648:
URL:
https://github.com/apache/shardingsphere/issues/24648#issuecomment-3628138181
## Problem Understanding:
Using ShardingSphere-JDBC 5.2.0 with a custom ComplexKeysShardingAlgorithm;
databases are sharded by year, tables by month (table names only include month
01..12). A query across 2022-11 to 2024-03 ends up scanning 12 tables per
database. You hope to pass data source info into the algorithm to reduce
scanned tables.
## Root Cause:
The ComplexKeysShardingAlgorithm interface only passes current target names
(databases at DB stage, tables at table stage); table sharding does not include
the data source name. Because table names lack the year, the table sharding
algorithm cannot distinguish years and must conservatively return all 12
monthly tables for each database. This behavior follows the current naming and
interface design and is not a framework bug.
## Issue Analysis:
Database sharding correctly selects fbusi-2022/2023/2024. During table
sharding, only f_busi_01..12 are available and there is no year dimension, so
precise pruning is impossible. ShardingSphere’s design decouples database and
table sharding; table
algorithms should not rely on data source names. For time-based precision
routing, table names should embed the year (e.g., yyyyMM) or use the built-in
interval/inline time sharding; custom properties like datetime-pattern are only
consumed inside your algorithm and do not trigger automatic pruning by the
framework.
## Problem Conclusion:
This is expected behavior caused by your naming and custom algorithm design.
Change table naming to include the year (e.g., f_busi_yyyyMM) and adjust or use
the built-in time sharding algorithm so table sharding can route precisely
without relying on data source information.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
