Diagnosing Slow SQL Execution in DBLE Due to Incorrect Stringhash Partition Configuration

The client’s DBLE test environment experienced timeouts when a specific function failed to retrieve backend data within the expected timeframe, resulting in error messages.

The environment runs DBLE version 2.19.07.3 on MySQL 5.7.25. Two tables, cusvaa (67 rows) and cusm (approximately 76 million rows), are sharded into eight partitions using the stringhash rule with a partition length of 10.

Initial investigation showed the SQL took an excessively long time to execute. Examination of the SQL and its execution plan revealed that DBLE was pulling the full data set from each shard, performing a merge and join in the middle layer, indicating that the sharding key was not being applied effectively.

Further analysis of the configuration files ( schema.xml and rule.xml ) uncovered that, although both shards used the same stringhash rule, the function definitions differed—specifically, the hashSlice tuple was missing or inconsistent, resulting in different partitioning behavior.

After aligning the rule.xml function configuration—defining both partitionLength[] , partitionCount[] , and the hashSlice tuple—the configuration was reloaded. The new execution plan confirmed that the sharding key was now correctly applied.

Subsequent testing showed the query completing in seconds, confirming that the performance issue was resolved by correcting the sharding rule configuration.

In conclusion, the stringhash function must include both partition arrays and the hashSlice pair; DBLE only pushes SQL directly to each shard when the sharding rules match, otherwise it must retrieve all data to the DBLE layer for merge and join, leading to severe slowdowns.