能源管理系统数据层改造：ShardingSphere 分库分表与动态数据源实战

做一个能源管理系统的数据层改造时，我踩过最多的坑不是业务代码，而是数据源装配和 ShardingSphere 的配置解析。恰好最近的项目又是围绕 Java 和 ShardingSphere 做分布式数据方案，而且网上很多人都在问“怎么把 Sharding 数据源注册进动态数据源”“在 yaml 注入分库参数报错怎么办”，我把整个改造过程里遇到的问题、排查链路和最终落地方案整理出来，希望能帮到正在做同类系统的朋友。这套方案基于 Java + Spring Boot + ShardingSphere（Sharding-JDBC 模式），核心场景是能源管理系统中设备采集数据的分布式存储与查询，内容覆盖分片规则设计、动态数据源集成、YAML 配置排查、JVM 内存问题优化，适合数据量已经明显变大、正在考虑分库分表，或者已经引入 ShardingSphere 但被各种集成问题卡住的团队参考。

1. 能源管理系统的数据压力到底出在哪

1.1 一张表从几百万行到几亿行的过程

很多能源管理系统最早的架构很简单，站点、设备、采集记录三张核心表打天下。设备采集记录表存的是电表、水表、气表上报的实时数据，字段也不复杂：设备ID、采集时间、采集值、单位，最多加一个站点ID用于归属判断。

刚开始一天也就几十万条，单表单月几百万行，普通 MySQL 加个索引完全扛得住。但随着接入站点增加、采集频率从 15 分钟一次变成 5 分钟一次甚至 1 分钟一次，数据增长速度完全不是线性的。 到了项目中期，单张采集表突破 1 亿行，这时候事情开始不对劲了：按时间范围查某一台设备一天的曲线，原来几十毫秒，现在经常要一两秒；按站点跑月度汇总报表，一个 SQL 可能在线上拖十几秒，直接把主库的 IO 打满；DBA 想加索引，发现加索引的时间比业务迭代还长。

这个阶段最典型的表现是：数据库 CPU 时不时飙高、慢查询日志越来越多、报表模块的接口频繁超时。而业务方又不断提新需求：跨站点的能耗对比、多站点聚合分析、历史趋势预测。数据量摆在那里，单库单表已经不可能靠加索引和缓存解决问题。

1.2 不只是数据量问题：查询模型和站点隔离

能源管理和普通互联网业务有个明显区别：数据天然带有强烈的时间属性和站点属性。用户最常执行的查询是“查某个站点下某台设备在某个时间段内的采集数据”和“按站点/区域汇总某段时间的能耗”。这两个查询模式非常固定，基本都是在站点ID和时间范围上做过滤。

这种模型对分库分表非常友好，因为分片键可以很自然地选成站点ID和时间。按站点ID分库，可以把不同站点的数据隔离到不同物理库，既降低单库压力，又方便后续做多租户扩展；按时间分表，可以控制每张表的体积，让索引和查询都保持在一个健康的状态。

另外，能源管理系统还容易忽略一个问题：多站点之间的数据隔离。 如果没有物理隔离，所有站点数据混在一张表里，查询时漏加站点条件就是严重事故。分库之后，路由条件天然绑定站点ID，等于把“隔离”下沉到了数据访问层。这一点对系统安全性的提升，比单纯解决性能问题更有价值。

1.3 为什么选 ShardingSphere 而不是自己写分库分表

我在项目初期也考虑过自己封装一套分库分表逻辑：根据站点ID的哈希值选择连接，根据时间拼接表名，再写个工具类处理插入和查询。做起来确实不难，但后续的坑非常明显：跨分片聚合、分页排序、分布式ID、事务一致性、扩容迁移，每一块都是硬骨头。

ShardingSphere 的 Sharding-JDBC 模式本质上是一个增强版的 JDBC 数据源。应用层看到的还是一个 DataSource，SQL 提交给它之后，由它完成解析、路由、改写、执行、结果归并。对于业务代码来说，几乎不需要感知分片的存在，这对一个几十个服务模块的能源管理平台来说非常重要。

ShardingSphere 5.x 的配置虽然有点绕，但社区活跃、资料齐全，遇到问题基本都能查到。而且它内置了多种分片算法，支持自定义分片算法，绑定表、广播表的机制也很成熟。这套方案比我早期设想的自研方案可靠得多。实际改造下来，最大的成本不是框架本身，而是如何把它和项目里已有的多数据源体系、连接池配置、JVM 参数匹配好。

2. 分片键选错，后面运维全是坑

2.1 能源数据最适合的分片维度：站点 + 时间戳

分片键的选择是整个分库分表设计中最关键、最不可逆的决策。一旦表数据量大了再改分片键，要做数据迁移和重分布，成本极高。

能源系统中我强烈建议分片键选组合维度：站点ID用于分库，采集时间用于分表。核心理由有几点：

• 查询条件高度匹配：绝大多数查询都带 site_id 和 collect_time，路由可以直接落到单库单表，性能最好。
• 数据分布相对均匀：站点数量多、各站点数据量差距不大，按站点取模能保证数据基本分散。
• 归档清理方便：时间分表之后，历史数据可以直接按表淘汰或归档，不需要对单张大表做 DELETE 大事务。

如果单表数据量还在可控范围（比如单表 3000 万以下），也可以先只做分库不分表，减少表数量带来的元数据管理压力。但如果采集频率很高，建议一开始就把时间分表设计进去，避免半年后又做一次迁移。

2.2 分库分表规则设计：取模分库 + 按月分表

我们的核心表设计如下：

分片规则设计为：site_id 做 HASH_MOD 分到 2 个库，collect_time 按月分表，数据节点表达式为 ds-$->{0..1}.t_device_data_$->{202401..202412}。这里用 HASH_MOD 而不是 MOD，是因为站点ID不一定是从 0 开始的连续数字，如果用 MOD 算法，ID 为 1 和 3 的站点算出的分片结果可能不均匀，HASH_MOD 先做哈希再取模，能把分布打散。

如果想让配置更灵活，也可以做成按年份分表：ds-$->{0..1}.t_device_data_$->{2024}$->{1..12}。不过日期格式的补零问题比较麻烦，我更推荐在代码里自定义一个 MonthShardingAlgorithm，用 yyyyMM 生成表后缀，这样不管是 2025 年还是 2026 年，只要配置了对应的 actual-data-nodes 就能自动路由。

2.3 绑定表和广播表：不要漏掉这两个配置

很多初次使用 ShardingSphere 的人只配置了分片表，忽略了下两个关键配置。

第一是绑定表。如果系统里有另一张分片表也要按同样的分片键关联查询，比如设备分片表 t_device_$->{0..1} 和采集数据分片表 t_device_data_$->{0..1}，在 JOIN 查询的时候，如果不配置 binding-tables，ShardingSphere 会把两个分片表做笛卡尔积路由，产生 4 个 SQL 到库上执行。配置绑定表之后，路由会选择相同分片键的数据源和表，只产生 2 个 SQL，性能提升非常明显。

第二是广播表。像站点信息表、设备档案表、系统字典表这类数据量不大、但每个分片库的 SQL 都可能关联的表，要配置成 broadcast-tables。ShardingSphere 会把这些表自动同步到每个分片库，查询时从本地库读取，避免跨库 JOIN。

忽略这两个配置短期内看不出问题，但等数据量上来、报表 JOIN 一多，你会发现单条 SQL 被拆分成了几十条甚至在各个库之间来回查询，性能直接崩掉。

2.4 分布式ID方案对比

分库分表之后，数据库自增主键不能用了。我们对比过几种方案：

ShardingSphere 内置了 SNOWFLAKE 算法。用的时候注意两点：一是不同实例的 worker-id 不能重复，重复会导致 ID 冲突；二是如果你对 ID 的可排序性有强需求，可以在业务层把时间戳编入 ID 前缀，这样查询按 ID 排序时也能体现时间顺序。

3. ShardingSphere 与 Spring Boot 集成：从依赖到 YAML 落地

3.1 依赖选择：starter 的版本坑

Maven 依赖选择上，我们用 shardingsphere-jdbc-core-spring-boot-starter。这里有个容易被忽略的版本问题：如果你是 Spring Boot 2.x 项目，选用 5.2.1 或 5.3.x 版本问题都不大；但如果项目已经升级到 Spring Boot 3.x，需要确认 ShardingSphere 版本在 5.4.0 以上，否则会有兼容性问题。

还有一个常见坑是依赖冲突。 项目里如果之前引过旧版的 sharding-jdbc-spring-boot-starter（4.x 时代的包名），一定要全部清除，不能和 5.x 混用，否则会出现配置不生效、类方法找不到等奇怪问题。另外注意排除 ShardingSphere 自带的 logback 依赖，避免和项目统一日志配置冲突。

xml复制<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId>
    <version>5.2.1</version>
    <exclusions>
        <exclusion>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
        </exclusion>
    </exclusions>
</dependency>

3.2 YAML 配置模板：分片规则、绑定表、广播表、数据节点

下面是一个可用于参考的 YAML 配置核心结构，基于 ShardingSphere 5.x。

yaml复制spring:
  shardingsphere:
    datasource:
      names: ds-0,ds-1
      ds-0:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://192.168.1.10:3306/energy_0?useSSL=false&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true
        username: energy
        password: ${DS0_PASSWORD}
        maximum-pool-size: 10
      ds-1:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://192.168.1.11:3306/energy_1?useSSL=false&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true
        username: energy
        password: ${DS1_PASSWORD}
        maximum-pool-size: 10
    rules:
      sharding:
        tables:
          t_device_data:
            actual-data-nodes: ds-$->{0..1}.t_device_data_$->{202401..202412}
            table-strategy:
              standard:
                sharding-column: collect_time
                sharding-algorithm-name: month_table_algorithm
            database-strategy:
              standard:
                sharding-column: site_id
                sharding-algorithm-name: site_db_algorithm
            key-generate-strategy:
              column: id
              key-generator-name: snowflake
        binding-tables:
          - t_device, t_device_data
        broadcast-tables:
          - t_site
          - t_device
          - t_dict
        sharding-algorithms:
          site_db_algorithm:
            type: HASH_MOD
            props:
              sharding-count: 2
          month_table_algorithm:
            type: CLASS_BASED
            props:
              strategy: standard
              algorithmClassName: com.energy.sharding.MonthShardingAlgorithm
        key-generators:
          snowflake:
            type: SNOWFLAKE
            props:
              worker-id: 1
    props:
      sql-show: true

这个配置里有两个关键点要解释一下：

第一，actual-data-nodes 用的是 Groovy 行表达式。 $->{0..1} 和 $->{202401..202412} 是规则引擎支持的表达式写法，不是普通字符串，少了 $-> 前缀就会解析失败。这也是 yaml 注入分库参数时最容易报错的地方之一。

第二，自定义分片算法必须有具体的实现类。 CLASS_BASED 类型的算法需要指定 algorithmClassName 和 strategy 类型。如果不想写 Java 类，也可以用 inline 表达式，比如 type: INLINE 加 algorithm-expression: ds-${site_id % 2}。但 inline 表达式对复杂的月份转换不友好，所以我选择了自定义算法。

3.3 为什么把 ShardingSphere 配置成独立 DataSource 而不是主数据源

项目里已经存在一套多数据源体系，有主库、配置库、历史库等不同职责的库，通过 @DS 注解切换。如果直接把 ShardingSphere 的配置对象设置成主数据源，会引发两个问题：

一是所有没有显式指定数据源的业务代码都会被 ShardingSphere 接管，包括那些根本不需要分片的配置表、日志表查询，导致 SQL 被 ShardingSphere 解析一遍，增加无谓开销。

二是和现有动态数据源插件冲突。 动态数据源框架在启动时会创建自己的 RoutingDataSource，如果 ShardingSphere 也被当成普通数据源注册，两者之间的初始化顺序和依赖关系很容易出现循环依赖问题。

所以更好的做法是：ShardingSphere 生成一个名称明确的独立数据源 Bean（比如叫 shardingDataSource），再把它注册进动态数据源管理器，业务代码只在需要访问分片表的地方通过 @DS("sharding") 切换。

4. 把 Sharding 数据源注册进动态数据源：一次启动失败与排查链路

4.1 为什么要用动态数据源管理 Sharding

现在项目中已经有很多个数据源，仅靠 MyBatis 的 SqlSessionFactory 绑死一个数据源是行不通的。我们引入了 dynamic-datasource-spring-boot-starter，它允许在运行时维护一个数据源 Map，通过注解或代码切换。把 ShardingSphere 数据源放进这个 Map，业务层就可以像使用普通多数据源一样使用分片数据源。

但这里有个逻辑上的因果问题：ShardingSphere 数据源本身不是直接从 yml 的普通数据源信息创建的，它需要由 ShardingSphere 的配置工厂创建，并在创建时聚合多个物理数据源。所以不能像普通数据源那样直接配置 dynamic-datasource 的 url、username、password，必须通过代码注册。

4.2 完整的错误现场

我最初直接写了一个 ShardingDataSourceConfig 配置类，在里面用 @Bean 创建 ShardingSphereDataSource，然后在动态数据源配置里注入它。结果启动报错：

code复制The dependencies of some of the beans in the application context form a cycle:
  dataSource ...
  shardingDataSource ...
  dynamicDataSource ...

或者是：

code复制BeanCurrentlyInCreationException: Error creating bean with name 'shardingDataSource':
Requested bean is currently in creation

这个错误的核心是循环依赖：ShardingSphere 数据源创建时需要动态数据源上下文，而动态数据源又需要 ShardingSphere 数据源实例。两个 Bean 互相等待，Spring 容器直接拒绝启动。

4.3 排查链路：从循环依赖到 Bean 初始化顺序

遇到循环依赖，我的排查步骤是：

第一步，先看启动日志里循环依赖链路上都有哪些 Bean。 通常参与循环的不仅有 sharding 数据源，还有我们自定义的 MyBatis 配置、事务管理器等。如果链路里涉及动态数据源，说明初始化的先后顺序设计不对。

第二步，隔离 ShardingSphere 的创建过程。 不要让它依赖动态数据源框架的任何 Bean。ShardingSphere 数据源创建只需要读物理库连接信息，这部分信息可以通过配置类自己读取，最简单的做法是在配置类里用 @Value 或 @ConfigurationProperties 读取 ShardingSphere 的 yml 配置。

第三步，确认是否有多个 DataSource 类型的 Bean 被 MyBatis 自动扫描到。 如果有两个以上 DataSource，必须用 @Primary 标记主数据源，或者在配置 SqlSessionFactory 时显式指定。

第四步，通过实现动态数据源的 Provider 接口注册 Sharding 数据源，而不是在动态数据源的 Bean 创建阶段直接引用它。

4.4 正确的注册方式与注意事项

最终我们使用的是 dynamic-datasource 提供的 AbstractDataSourceProvider 扩展点，把 ShardingSphereDataSource 包装进动态数据源的数据源 Map。核心代码如下：

java复制@Configuration
public class ShardingDataSourceConfig {

    @Bean("shardingDataSource")
    public DataSource shardingDataSource() throws SQLException {
        // 通过程序方式加载 yml 中的分片配置，也可以直接读取 spring.shardingsphere.*
        ShardingSphereDataSource dataSource = ShardingSphereDataSourceFactory.createDataSource(
                createDataSourceMap(),
                loadShardingRules(),
                new Properties());
        return dataSource;
    }
}

然后在动态数据源 Provider 中注册：

java复制@Component
public class ShardingDataSourceProvider extends AbstractDataSourceProvider {

    @Autowired
    @Qualifier("shardingDataSource")
    private DataSource shardingDataSource;

    @Override
    public Map<String, DataSource> loadDataSources() {
        Map<String, DataSource> dataSourceMap = createDataSourceMap();
        dataSourceMap.put("sharding", shardingDataSource);
        return dataSourceMap;
    }
}

写完这段之后，还要处理一个非常重要的问题：动态数据源的 primary 数据源要明确指定。 如果 primary 仍指向原来的主库，那么所有不带 @DS 注解的查询都会正常走主库，只有显式指定 @DS("sharding") 的接口才会使用分片数据源。我一开始没设置 primary，结果 start 后 MyBatis 自动注入的数据源被自动判定为空，导致大量服务无法启动。

最后，ShardingSphere 数据源对象不建议频繁创建。 它内部会缓存元数据、分片规则等状态，创建成本不低。在动态数据源里注册一次就够了，不要每次请求都 new 一个。

5. YAML 注入分库参数报错：常见的几个坑与排查思路

5.1 缩进和换行导致的解析异常

YAML 配置对缩进极其敏感。Spring Boot 在启动时会读取 spring.shardingsphere 前缀下的配置，如果缩进不对，会直接报:

code复制Failed to bind properties under 'spring.shardingsphere.rules.sharding'

解决方式是先确认文件里没有混用 Tab 和空格。我遇到过同事把 IDE 的缩进设置成 Tab，结果整个分片规则都没被解析到。强烈建议统一用空格缩进，并在 IDE 里开启空白字符显示。

5.2 算法表达式被当成普通字符串

ShardingSphere 的行表达式必须写 $->{} 这种形式，比如 ds-$->{0..1}。但 YAML 里如果把这个值用双引号包裹，某些解析场景下会把 $ 当普通字符处理，导致节点解析不到。

正确写法是不加引号，或者严格按照官方文档写：

yaml复制actual-data-nodes: ds-$->{0..1}.t_device_data_$->{202401..202412}

如果经过 Spring 占位符解析后 $->{...} 被吞掉，可以考虑把配置放到独立的 YAML 文件中，并使用 ShardingSphereDataSourceFactory 通过代码加载，规避占位符冲突。

5.3 分片算法名称引用错误

ShardingSphere 5.x 中，表策略里通过 sharding-algorithm-name 引用 sharding-algorithms 下定义的算法名称。名称写错时，启动时会报：

code复制Cannot find sharding algorithm with name [xxx]

这类错误很好排查，就是配置名对不上。但有一个隐性问题：如果 sharding-algorithms 里定义了某个算法，但没有任何表引用它，ShardingSphere 也不会报错，只会静默忽略。所以要经常确认自己到底配置了哪些算法、哪些表在引用。

5.4 4.x 升级 5.x 后配置项改名

老项目如果用 4.x 升级到 5.x，很多配置项发生了改变：

4.x 的配置直接迁移到 5.x 基本都会报错或配置不生效，不建议在一个大版本升级里同时做分库分表改造，最好先把 ShardingSphere 版本升完、确认基础功能正常，再动分片规则。

5.5 YAML 配置校验的快速方法

在 Spring Boot 启动日志里开启 sql-show: true，然后执行一条带 siteId 的查询，看日志中实际执行的 SQL 是否路由到预期的库和表。

yaml复制props:
  sql-show: true

日志中会输出类似：

code复制actual SQL: ds-0 ::: select * from t_device_data_202403 where site_id = 1001 and collect_time between ... 

如果发现路由到错误的分片或查询了全部节点，优先检查分片算法和分片键的数据类型。常见的原因是分片键配置成了字符串，但实际值是 Long，导致哈希取模结果不一致。

6. 内存溢出问题：ShardingSphere 元数据加载与连接池配置

6.1 insufficient memory 的典型现场

应用部署到一台 2C4G 的服务器上，启动后没运行多久就出现：

code复制java.lang.OutOfMemoryError: Insufficient memory

一开始我怀疑是堆内存设置太小，直接调大 -Xmx，但问题反而更严重，进程频繁被系统杀掉。后来用 jstat -gcutil 和 jmap -heap 查看，发现堆内存并没有打满，真正的问题是 JVM 的 native memory 被大量占用，系统内存不足。

6.2 原因一：分片数据源连接池配置过大

ShardingSphere 在启动时会为每个物理数据源创建独立的连接池。默认情况下，HikariCP 的 maximum-pool-size 如果沿用通用配置（比如 50），两个分片库就是 100 个连接，每个连接都持有线程栈和网络缓冲区，内存开销非常可观。对于一个 4G 内存的实例来说，这个配置几乎必然触发 native memory 不足。

这里需要明确一个概念：并不是连接数越大性能越好。 分片架构下，单条SQL只会路由到一个或少数几个分片，每个分片同时执行的并发连接数取决于应用的并发度，而不是连接池上限。我们把每个分片数据源的 maximum-pool-size 调整为 10，minimum-idle 调整为 5，系统内存占用立刻下降明显。

6.3 原因二：批量插入性能与内存占用

能源采集数据的特点是持续写入，如果一条一条 insert，不仅慢，而且对数据库和连接池的压力都很大。ShardingSphere 支持批量插入，但默认情况下 MySQL JDBC 驱动不会自动合并批量语句，需要连接串增加 rewriteBatchedStatements=true 才能真正发挥作用。

我们在采集入库模块里做了两层优化：

第一层，业务代码攒批。 按 500～1000 条一批提交，避免频繁网络往返。

java复制List<DeviceCollectRecord> records = new ArrayList<>(500);
while (hasData()) {
    records.add(parseRecord());
    if (records.size() >= 500) {
        deviceRecordMapper.batchInsert(records);
        records.clear();
    }
}

第二层，批量插入 SQL 的 XML 写法要合理。 用 <foreach> 拼接还是用 <script> 方式看 MyBatis 习惯，但核心是要保证 ExecutorType.BATCH 或 rewriteBatchedStatements 生效。这个优化做完后，同样数据量的写入耗时下降了 60% 以上，JVM 中频繁创建的小对象也少了很多。

6.4 原因三：元数据加载范围过大

ShardingSphere 启动时会连接每个分片数据源，加载分片规则涉及表的元数据。如果 actual-data-nodes 配置了一个非常大的表数量范围（比如按天分表，一配就是几年），启动时元数据加载时间会非常长，内存也会瞬间升高。

优化方向是收窄 actual-data-nodes 范围。 能源数据按月份分表，我们滚动保留最近 12 个月的表，早期历史表直接走归档库，不参与分片配置。这样既控制了元数据加载量，也让路由逻辑更清晰。

6.5 调整后的 JVM 参数参考

基于上述分析，我们调整了启动参数。注意这里不是万能模板，是给同等量级（两个分片库、单表千万级、日增百万条以下）的参考：

bash复制-Xms512m
-Xmx2g
-XX:MaxMetaspaceSize=256m
-XX:+UseG1GC
-XX:MaxDirectMemorySize=512m

MaxDirectMemorySize 要特别提一下。ShardingSphere 的结果归并和网络 IO 会用到堆外内存，如果不限制，默认可能跟着堆大小走，在容器环境里容易造成误判。限制了堆外内存后，OOM 的日志也会更清晰，便于定位。

6.6 上线后的验证：从慢查询到秒级返回

改完配置之后，我们做了一个简单压测。单站点设备某月的数据查询，原来在单库单表时代要 2.8 秒左右，分片后稳定在 0.1 秒到 0.2 秒；月度全站汇总报表从 18 秒降到了 1.2 秒。这里的关键是查询 SQL 都带了 site_id 和 collect_time，路由精准命中单个分片，没有触发全库扫描。

如果查询没有带分片键，ShardingSphere 会执行全路由，把 SQL 发给所有分片库执行后再合并结果。 这样的查询在数据量小的时候还能忍受，数据量一大就会变成灾难。所以我在代码审查时定了一条规则：所有采集数据查询接口必须显式传入站点ID或时间范围，否则不允许走分片数据源。

7. 上线后复盘：几个最有价值的提醒

这套方案上线后，系统已经稳定跑了几个月。虽然很多细节和踩坑过程都已经在前面写过了，但最后我还是想把一些没有归类到具体章节的经验单独列出来，提醒准备上车的团队。

不要把业务里所有表都做成分片表。 能源系统里很多配置表、字典表、操作日志表，数据量增长很慢，单表完全能抗住。这些表如果也参与分片，只会白白增加配置复杂度和元数据加载开销。合适的做法是：真正的大表走分片，小表走广播或默认数据源。

分片键的约束要提前嵌入到接口设计和代码规范里。 我们初期踩过一个大坑：某个报表服务在拼接查询条件时，没有把 site_id 传进来，结果 ShardingSphere 把 SQL 广播到了所有分片表和所有库，导致该服务接口直接超时。后来我们在路由入口加了一层参数校验，强制要求带站点ID，才彻底解决这类问题。

还有一点是关于监控的。 开启 sql-show 只能在开发环境用，生产环境建议通过 ShardingSphere 的 metric 或日志采集来观察每个分片的执行情况，重点是慢SQL和全路由SQL。全路由SQL一旦出现，基本就是代码漏了分片键，必须及时处理。

最后说说团队协作层面。 分库分表改造不只是 DBA 或某个后端工程师的事，它会影响所有读写采集数据的服务。改之前要和业务方一起确认历史数据的保留策略、归档方案和跨年表的切换方式；改之后要给团队做一次配置和排查的经验分享，尤其是 YAML 配置的几个坑点，知道的人越多，后续踩坑的概率越低。这套方案不是银弹，但对我们能源管理系统的数据治理来说，是目前投入产出比最高的选择。