本文主要给大家介绍JDBC Source批处理任务动态切分优化，希望大家批评指正
JDBC Source 如果配置了table_path 和 partition_column，引擎会对数据进行动态切分，可以通过分析样本数据优化切分区间，规避数据倾斜问题。
目前发现任务即使配置了where_condition，动态切分算法仍然会把数据进行全表切分，在从大表中读取少量数据的场景下，任务切分阶段会耗费大量的时间，需要修改下面相关的流程进行优化。
下面所有出现SQL语句的地方均以MySQL为例子进行说明，具体不同的数据源有不同的子类方法overwrite实现。
数据切分主流程
数据动态切分的代码入口位于DynamicChunkSplitter类中的splitTableIntoChunks方法，流程图中标红的方框表示需要修改的部分，详细在下面的子流程中展开说明。
查询最大最小值
需要加上Source的where_condition配置的判断和拼接。
通用字段切分
查询数据总条数部分
（1）增加且where_condition配置为空才走“是”的分支
（2）修改“否”分支，增加where_condition的判断和对应查询语句的拼接，子查询和表查询的规则如下：
如果配置了Query则查询SQL为
SELECT COUNT(*) FROM (<子查询>) T
否则查询SQL为
SELECT COUNT(*) FROM <表名>
如果配置了
where_condition则拼接到末尾
切分数据区间部分
详情见子流程
分页查询分片
查询下一个分片的结束边界nextChunkEnd
1.max查询部分
判断如果配置了where_condition则在limit那层查询添加条件拼接
2.min查询部分
判断如果配置了where_condition则添加条件拼接
样本查询分片
判断如果配置了where_condition则添加条件拼接
日期字段切分
复用了通用字段切分的1部分，只需修改一次即可。
分片使用流程
这里相关的流程不需要修改，这里分析是为了弄清楚分片是如何被使用的，以评估前面修改的必要性、正确性和风险。
数据被切分为分片后会被分发到Worker的SourceSeaTunnelTask中，最终在JdbcInputFormat类的open方法中被使用，主要流程如下
由上面流程可知，由分片生成的SQL在最后会判断拼接where_condition，如果在生成分片的阶段没有考虑where_condition，则生成的分片中可能有部分分片在追加上where_condition条件限制后查询不到数据，当这样的分片很多时，不但会影响分片切分的性能，也会影响数据读取的性能，因为过程中产生了大量的无效查询。
优化效果
优化之后本地测试从一个55G的MySQL表使用where_condition过滤读取多条数据的耗时从25分钟缩短到23秒。
提交的PR链接：https://github.com/apache/seatunnel/pull/8760