ShardingSphere启动慢别急着升级先试试调这个隐藏参数当你面对一个启动需要近一分钟的ShardingSphere应用时第一反应可能是升级到最新版本。但在实际企业环境中版本升级往往牵一发而动全身。今天我要分享的是一个被多数人忽略的隐藏参数——max.connections.size.per.query它能让你在不升级的情况下显著改善启动性能。1. 元数据加载的幕后机制ShardingSphere在启动时需要加载所有分表的元数据信息。当系统中有数千张表时这个过程会变得异常缓慢。通过分析日志我们经常能看到这样的记录2024-01-10 10:12:25:527[main][INFO] Loading 4947 tables meta data. 2024-01-10 10:13:14:312[main][INFO] Meta data load finished, cost 49078 milliseconds.核心问题在于加载策略。在5.0.0-beta之前的版本中元数据加载采用单线程串行方式。而决定这一行为的关键参数就是max.connections.size.per.query默认值1单线程串行加载设置1多线程并行加载// 源码关键片段 public static SchemaMetaData load(DataSource dataSource, int maxConnectionCount, String databaseType) { ListListString tableGroups Lists.partition(tableNames, Math.max(tableNames.size() / maxConnectionCount, 1)); return 1 tableGroups.size() ? load(dataSource.getConnection(), tableGroups.get(0), databaseType) : asyncLoad(dataSource, maxConnectionCount, tableNames, tableGroups, databaseType); }2. 参数调优实战指南2.1 配置方式根据你的项目配置方式可以选择以下任一方法调整参数YAML配置方式spring: shardingsphere: datasource: yourDataSourceName: max-connections-size-per-query: 20Java代码配置方式Bean(name dataSourceSharding) public DataSource getShardingDataSource(Qualifier(dataSource) DataSource dataSource) { Properties properties new Properties(); properties.put(ConfigurationPropertyKey.MAX_CONNECTIONS_SIZE_PER_QUERY.getKey(), 20); return ShardingDataSourceFactory.createDataSource(dataSourceMap, ruleConfig, properties); }2.2 参数值的选择表数量推荐值说明1001-2提升有限保持默认即可100-10005-10显著减少加载时间100010-20需配合连接池大小调整提示该值不应超过数据源连接池的最大连接数否则会导致启动失败3. 运行期影响深度解析调整这个参数不仅影响启动速度还会改变SQL执行策略。当执行分片查询时-- 逻辑SQL SELECT * FROM user WHERE name张三 -- 实际执行假设分10表 SELECT * FROM user_0 WHERE name张三 ... SELECT * FROM user_9 WHERE name张三执行模式对比模式触发条件内存消耗连接占用适用场景连接限制模式max值 分片数高低查询结果集小内存限制模式max值 ≥ 分片数低高查询结果集大// 执行模式判断逻辑 ConnectionMode connectionMode maxConnectionsSizePerQuery sqlUnits.size() ? ConnectionMode.CONNECTION_STRICTLY : ConnectionMode.MEMORY_STRICTLY;4. 必须规避的三大陷阱4.1 连接数耗尽风险参数值设置过大可能导致启动时元数据并行加载消耗过多连接运行时无分片键查询占用全部连接典型错误配置# 危险连接池最大为20却设置参数为30 spring.datasource.druid.max-active20 spring.shardingsphere.datasource.ds.max-connections-size-per-query304.2 内存溢出隐患当遇到以下情况时容易引发OOM大结果集查询无分片键的全表扫描参数值设置过小强制走连接限制模式4.3 分片键缺失的连锁反应缺少分片键的查询会触发全路由此时参数值的影响会被放大-- 危险查询缺少user_id分片键 UPDATE user SET status1 WHERE create_time2023-01-01应对策略强制分片键检查为这类查询单独设置较小的参数值避免在生产环境执行全表操作5. 性能对比实测数据我们在测试环境模拟了不同场景下的表现启动时间对比5000表参数值加载时间(ms)提升幅度148,921-512,40374.6%108,75282.1%207,89183.9%查询性能对比10分片参数值平均响应(ms)内存峰值(MB)1235420518738010152210在实际项目中我发现将参数设置为分片数量的1/3到1/2往往能取得最佳平衡。例如对于30个分片的系统设置10-15既能保证启动速度又不会过度消耗连接资源。
ShardingSphere启动慢？别急着升级，先试试调这个隐藏参数（max.connections.size.per.query详解）
ShardingSphere启动慢别急着升级先试试调这个隐藏参数当你面对一个启动需要近一分钟的ShardingSphere应用时第一反应可能是升级到最新版本。但在实际企业环境中版本升级往往牵一发而动全身。今天我要分享的是一个被多数人忽略的隐藏参数——max.connections.size.per.query它能让你在不升级的情况下显著改善启动性能。1. 元数据加载的幕后机制ShardingSphere在启动时需要加载所有分表的元数据信息。当系统中有数千张表时这个过程会变得异常缓慢。通过分析日志我们经常能看到这样的记录2024-01-10 10:12:25:527[main][INFO] Loading 4947 tables meta data. 2024-01-10 10:13:14:312[main][INFO] Meta data load finished, cost 49078 milliseconds.核心问题在于加载策略。在5.0.0-beta之前的版本中元数据加载采用单线程串行方式。而决定这一行为的关键参数就是max.connections.size.per.query默认值1单线程串行加载设置1多线程并行加载// 源码关键片段 public static SchemaMetaData load(DataSource dataSource, int maxConnectionCount, String databaseType) { ListListString tableGroups Lists.partition(tableNames, Math.max(tableNames.size() / maxConnectionCount, 1)); return 1 tableGroups.size() ? load(dataSource.getConnection(), tableGroups.get(0), databaseType) : asyncLoad(dataSource, maxConnectionCount, tableNames, tableGroups, databaseType); }2. 参数调优实战指南2.1 配置方式根据你的项目配置方式可以选择以下任一方法调整参数YAML配置方式spring: shardingsphere: datasource: yourDataSourceName: max-connections-size-per-query: 20Java代码配置方式Bean(name dataSourceSharding) public DataSource getShardingDataSource(Qualifier(dataSource) DataSource dataSource) { Properties properties new Properties(); properties.put(ConfigurationPropertyKey.MAX_CONNECTIONS_SIZE_PER_QUERY.getKey(), 20); return ShardingDataSourceFactory.createDataSource(dataSourceMap, ruleConfig, properties); }2.2 参数值的选择表数量推荐值说明1001-2提升有限保持默认即可100-10005-10显著减少加载时间100010-20需配合连接池大小调整提示该值不应超过数据源连接池的最大连接数否则会导致启动失败3. 运行期影响深度解析调整这个参数不仅影响启动速度还会改变SQL执行策略。当执行分片查询时-- 逻辑SQL SELECT * FROM user WHERE name张三 -- 实际执行假设分10表 SELECT * FROM user_0 WHERE name张三 ... SELECT * FROM user_9 WHERE name张三执行模式对比模式触发条件内存消耗连接占用适用场景连接限制模式max值 分片数高低查询结果集小内存限制模式max值 ≥ 分片数低高查询结果集大// 执行模式判断逻辑 ConnectionMode connectionMode maxConnectionsSizePerQuery sqlUnits.size() ? ConnectionMode.CONNECTION_STRICTLY : ConnectionMode.MEMORY_STRICTLY;4. 必须规避的三大陷阱4.1 连接数耗尽风险参数值设置过大可能导致启动时元数据并行加载消耗过多连接运行时无分片键查询占用全部连接典型错误配置# 危险连接池最大为20却设置参数为30 spring.datasource.druid.max-active20 spring.shardingsphere.datasource.ds.max-connections-size-per-query304.2 内存溢出隐患当遇到以下情况时容易引发OOM大结果集查询无分片键的全表扫描参数值设置过小强制走连接限制模式4.3 分片键缺失的连锁反应缺少分片键的查询会触发全路由此时参数值的影响会被放大-- 危险查询缺少user_id分片键 UPDATE user SET status1 WHERE create_time2023-01-01应对策略强制分片键检查为这类查询单独设置较小的参数值避免在生产环境执行全表操作5. 性能对比实测数据我们在测试环境模拟了不同场景下的表现启动时间对比5000表参数值加载时间(ms)提升幅度148,921-512,40374.6%108,75282.1%207,89183.9%查询性能对比10分片参数值平均响应(ms)内存峰值(MB)1235420518738010152210在实际项目中我发现将参数设置为分片数量的1/3到1/2往往能取得最佳平衡。例如对于30个分片的系统设置10-15既能保证启动速度又不会过度消耗连接资源。
