当前位置：首页 > news >正文

从单表到分片：用ShardingSphere-JDBC实战改造Yudao-Cloud系统日志表（MySQL 8.0环境）

news 2026/6/12 8:02:53

从单表到分片：用ShardingSphere-JDBC实战改造Yudao-Cloud系统日志表（MySQL 8.0环境）

当系统登录日志表的数据量突破千万级时，单表查询性能会以肉眼可见的速度下降。最近在优化Yudao-Cloud项目时，就遇到了这个典型场景——system_login_log表的查询响应时间从最初的200ms逐渐攀升到2秒以上。本文将分享如何在不改动业务代码的前提下，通过ShardingSphere-JDBC实现日志表的水平分片与读写分离，最终使查询性能回归到毫秒级。

1. 分片方案设计

1.1 分片键选择策略

在system_login_log表中，有三个字段适合作为分片键候选：

用户ID：适合用户查询自己历史登录记录的场景
登录时间：适合按时间范围查询的审计需求
记录ID：适合全局唯一性要求高的场景

经过实际业务分析，我们最终选择用户ID作为分片键，原因如下：

-- 原始表结构示例 CREATE TABLE `system_login_log` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL, `login_time` datetime NOT NULL, `ip_address` varchar(45) DEFAULT NULL, `user_agent` text, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_login_time` (`login_time`) ) ENGINE=InnoDB;

提示：选择分片键时需要重点考虑业务查询模式。如果80%的查询都带有user_id条件，那么它比时间戳更适合作为分片键。

1.2 分片算法选型

ShardingSphere提供多种分片算法，针对用户ID这种离散值，我们选择取模分片：

算法类型	适用场景	优缺点
取模分片	离散值均匀分布	扩容困难但实现简单
范围分片	连续值如时间戳	易出现热点但扩容方便
哈希分片	任意数据类型	分布均匀但无法范围查询

最终确定的分片规则是：user_id % 4，将数据均匀分布到4个物理表中。

2. 环境配置实战

2.1 依赖配置关键点

在Yudao-Cloud的yudao-dependencies模块中添加ShardingSphere核心依赖：

<!-- pom.xml关键配置 --> <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId> <version>5.4.1</version> </dependency>

特别注意需要排除冲突的连接池依赖：

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class, DruidDataSourceAutoConfigure.class }) public class SystemApplication {}

2.2 分片规则配置

创建sharding-sphere-config.yaml配置文件，核心配置如下：

rules: - !SHARDING tables: system_login_log: actualDataNodes: ds.system_login_log_$->{0..3} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: user_mod shardingAlgorithms: user_mod: type: MOD props: sharding-count: 4

注意：实际部署时需要预先创建system_login_log_0到system_login_log_3四个物理表，且必须移除原表的自增ID属性。

3. 数据迁移方案

3.1 在线迁移步骤

双写阶段：配置ShardingSphere同时写入新旧表
数据同步：使用DataX工具全量迁移历史数据
校验阶段：对比新旧表数据一致性
切流阶段：逐步将查询切换到分片表

# DataX迁移任务示例配置 { "job": { "content": [{ "reader": { "name": "mysqlreader", "parameter": {"column": ["*"], "connection": [{ "jdbcUrl": ["jdbc:mysql://old-db:3306/yudao"], "table": ["system_login_log"] }]} }, "writer": { "name": "mysqlwriter", "parameter": {"connection": [{ "jdbcUrl": "jdbc:mysql://new-db:3306/yudao", "table": ["system_login_log_${0..3}"] }]} } }] } }

3.2 灰度发布策略

通过配置多个版本的数据源实现平滑迁移：

# 多版本数据源配置示例 spring: shardingsphere: datasources: v1: # 旧版单表 v2: # 新版分片 rules: sharding: default-data-source-name: v1 tables: system_login_log: actual-data-sources: v2

4. 性能优化实践

4.1 查询优化技巧

分片环境下需要特别注意的查询模式：

// 好的查询 - 带分片键条件 @Select("SELECT * FROM system_login_log WHERE user_id = #{userId}") List<LoginLog> listByUser(@Param("userId") Long userId); // 坏的查询 - 全表扫描 @Select("SELECT * FROM system_login_log WHERE ip_address = #{ip}") List<LoginLog> listByIp(@Param("ip") String ip);

对于必须的全表查询，可以通过绑定表优化：

# 绑定表配置 rules: - !SHARDING bindingTables: - system_login_log, system_operation_log

4.2 监控指标配置

在Prometheus中添加关键监控项：

# application.yml监控配置 management: metrics: export: prometheus: enabled: true tags: application: ${spring.application.name} endpoint: prometheus: enabled: true health: show-details: always

重点关注以下指标：