我最早接触这套组合的时候其实心里是有点犯嘀咕的。MyBatis 和 JDBC 算是老搭档了中间再塞一个 ShardingSphere听起来就像给老房子做加固总担心哪里敲了承重墙。但等真正把“MySQL MyBatis ShardingSphere JDBC”这一整套跑通之后我才意识到这根本不是简单的加固而是给数据访问层上了一套完整的“指挥系统”。项目里遇到的很多让人头疼的问题——SQL 性能调优、分页插件失效、连接池打满、分库分表后的路由混乱——在这套组合下都有了清晰的解法。这篇文章我就把从头梳理的思路、配置过程中的坑、以及实测下来最稳的方案一次性讲清楚适合那些正在做 Java 后端、想把数据访问层真正吃透的同行参考。1. 内容整体设计与思路拆解1.1 技术组合的定位谁在负责什么在聊配置之前得先把这套组合里每个角色的分工理顺。很多人一上来就急着写配置文件结果遇到问题时连“该查哪一层”都分不清。JDBCJava Database Connectivity是 Java 访问数据库的底层标准接口。它负责最基础的连接管理、SQL 语句执行、结果集处理。没有它上层一切框架都是空中楼阁。它就像水管工手里的扳手虽然笨重但所有流量最终都要经过它。MySQL是存储层负责把数据真正落盘。它处理事务、索引、锁是最终的数据归宿。MyBatis是基于 JDBC 的持久层框架它帮你省去了手工写Connection、PreparedStatement、ResultSet的繁琐过程让你专注于写 SQL 和结果映射。它并不会绕过 JDBC而是在 JDBC 外面包了一层“减负壳”。ShardingSphere在这个组合里扮演的是“数据网关”的角色。它拦截你发给 MyBatis 的 SQL根据分片规则重新改写然后路由到正确的数据库实例或数据表上。实时业务场景中分库分表最难的不是“拆”而是“拆完之后查询怎么办”。ShardingSphere 的价值就在于把“拆”这件事对你透明化。理解了这个分工你就能明白为什么说“MyBatis ShardingSphere JDBC”不是简单的叠加而是各司其职的协同。1.2 为什么需要 ShardingSphere 这一层很多人会问单库单表跑得好好的为什么要引入 ShardingSphere 这么个重家伙答案是数据量到了一定规模单表瓶颈绕不过去。比如你有一张订单表日增 100 万行一年下来就是 3.6 亿行。这时候哪怕你加了再多的索引写入并发和查询性能都会出现断崖式下跌。MySQL 的 B 树索引虽然高效但索引文件过大之后内存放不下磁盘 IO 就成了瓶颈。此时你只有两条路要么升级硬件贵且不解决问题要么拆分数据。ShardingSphere 支持两种模式分库库内分表和分表跨库分表。举个例子订单表可以按用户 ID 取模分到 4 个库每个库里再按月份分 12 张表总共 48 张物理表。对应用层来说你仍然是在操作一张名为t_order的逻辑表剩下的工作 ShardingSphere 替你完成了。在数据量持续增长的项目里这套机制能让你把精力留在业务上而不是天天关心底层数据应该被存放在哪里。1.3 这套组合的实际收益与代价这套组合不是银弹它有收益也有代价。收益方面最直观的是开发效率。你用 MyBatis 写 SQL依然可以享受到动态 SQL 的灵活性你用 ShardingSphere可以把分库分表的复杂度从业务代码里剥离。过去你要在 Service 层里手动判断路由到哪个数据源现在不需要了。代价方面主要集中在连接数消耗和SQL 限制上。分库分表后一次全库查询可能会被拆成多次执行连接池压力成倍增长。另外ShardingSphere 对 SQL 语法有限制比如子查询涉及多分片时改写逻辑会很复杂OVER开窗函数也可能不支持。所以这套组合适合那种“读多写少、数据量大、业务规则相对明确”的场景并不适合所有项目。2. 核心配置与实操要点2.1 MySQL 版本选择与安装避坑在配置整套组合之前MySQL 版本选择这一步一直被很多人忽视。你最好根据自己的 MySQL 服务端版本匹配合适的 JDBC 驱动版本。标题里提到的组合行业里最常见的环境是 MySQL 5.7 或 8.0。如果是 MySQL 5.7推荐 JDBC 驱动用mysql-connector-java5.1.49 或 8.0.x8.0 驱动向下兼容 5.7。如果是 MySQL 8.0直接用 8.0.33 这类较新版本即可。注意不要用 8.0 驱动连接 5.6 或更老的 MySQL因为 8.0 驱动默认启用了 caching_sha2_password 认证插件老版本 MySQL 根本认不了。安装环节最容易踩坑的是初始化和密码策略。MySQL 8.0 初始化后会生成临时密码在日志文件里很多人没注意到--initialize-insecure这个参数导致 root 密码始终不对。建议测试环境直接用--initialize-insecure开发环境刷新权限后自定义密码生产环境强制配置复杂密码。我之前在 Linux 服务器上部署 MySQL 时遇到过Cant connect to local MySQL server through socket /tmp/mysql.sock这类经典报错。排查思路很简单先确认 mysqld 进程是否在跑再确认 socket 文件位置是否和客户端配置一致。用mysqladmin ping验证服务端状态用ls -l /tmp/mysql.sock查看 socket 文件。避免在 socket 文件都不存在的情况下反复重启客户端程序浪费时间。2.2 JDBC 连接串的核心参数useSSL 与 serverTimezone网上 MySQL JDBC 连接串五花八门好多人直接复制粘贴结果环境一换就原地爆炸。这里我给出一个生产环境验证过的配置模板并逐一解释每个参数的作用jdbc:mysql://127.0.0.1:3306/test_db?useSSLfalseuseUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/ShanghairewriteBatchedStatementstrueallowMultiQueriestrueuseSSLfalse除非你的业务真的需要加密传输否则建议关掉。开启 SSL 后每次握手都要做一次证书交换既增加延迟又消耗 CPU。MySQL 8.0 默认连接串不带useSSLfalse很多开发工具连上后一直提示 SSL 警告原因就在这里。serverTimezoneAsia/Shanghai这个必须手动指定。如果你的数据库时区是 CST而应用服务器时区不同插入的时间字段就会相差 8 小时。两个时区信息出现错乱恰好是项目中排查时间数据“无端偏移”的关键点。rewriteBatchedStatementstrue批量插入优化。配合 MyBatis 的ExecutorType.BATCH可以让 JDBC 驱动将多条 INSERT 合并成一条多值 INSERT 发送到数据库性能提升以倍数计。allowMultiQueriestrue允许一个语句中写多个用分号分隔的 SQL。这个开关只在 MyBatis 执行复杂初始化脚本时用到要注意它放大了 SQL 注入风险生产环境非必要不开启。有一点需要说明MySQL Connector/J 8.x 中设置useSSLfalse已经足够了不再需要sslmode那样的参数。如果使用 PG 数据库才会有sslmoderequire之类的选项这里不做展开。2.3 MyBatis 核心配置二级缓存与日志打印MyBatis 的配置主要关注两点缓存和 SQL 日志。缓存方面MyBatis 默认开启一级缓存SqlSession 级别但这个缓存生命周期极其短暂——你的 Service 方法里如果每次操作都新建 SqlSession一级缓存根本起不了作用。二级缓存Mapper 级别才是值得好好调教的配置方式很简单mapper namespacecom.example.mapper.OrderMapper cache evictionLRU flushInterval60000 size512 readOnlytrue/ /mapper配置二级缓存之前请务必确认两个前提第一接口方法的返回对象必须实现了Serializable否则缓存写入时报错第二如果涉及多表关联查询脏数据风险极高建议只给单表单查询的 Mapper 开二级缓存。我对这块的切身体会是分布式环境下MyBatis 二级缓存是个“看起来很美”的功能在分库分表场景下一旦某张表的数据被 ShardingSphere 路由到多个库缓存和实际数据的同步逻辑就变得特别绕。如果你用了 ShardingSphere尽量直接关闭二级缓存避免数据不一致问题。日志打印方面在 Spring Boot 项目里配置application.ymlmybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这样会将 SQL 输出到控制台方便开发环境调试。但注意生产环境千万别开启不然日志文件增长速度超出你想象。更建议的方式是使用p6spy这类代理工具打印的 SQL 会带上参数值和执行耗时排查慢查询时信息更全面。2.4 分页插件的选型与配置分析分页插件的用法是搜索热词里反复出现的话题。MyBatis 的 PageHelper 一直是最常用的分页组件但这个组件在 ShardingSphere 环境下的兼容性比较微妙。我实测下来的结论是基于拦截器实现的 PageHelper在单库单表场景下很好用。一旦引入 ShardingSpherePageHelper 的count(*)查询可能会被改写异常总数统计失真。如果你还没引入 ShardingSpherePageHelper 的经典用法是这样的PageHelper.startPage(pageNum, pageSize); ListOrder orders orderMapper.selectByCondition(condition); PageInfoOrder pageInfo new PageInfo(orders);核心原理PageHelper.startPage()底层是用ThreadLocal保存分页参数拦截器拦截下一次查询时自动拼接LIMIT语句。这里有个经典坑如果你先调用startPage()但后面连续执行了两次数据库查询第二查也会被强制分页。避免方法把分页参数绑定在紧随其后的第一条查询语句上。而在 ShardingSphere 环境下我建议放弃 PageHelper改为手动分页。原因很简单——经过分片改写后的 SQL在多个分片库上分别执行 LIMIT 后再合并PageHelper 的本地内存分页逻辑会遗漏部分数据。简单说它帮不上忙反而会在聚合阶段给你添乱。3. 实操过程与核心环节实现3.1 依赖引入Maven 依赖清单这里我给出一个在 Spring Boot 2.7.x MySQL 8.0 环境中实测通过的完整依赖组合dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version scoperuntime/scope /dependency dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version /dependency /dependencies版本要特别留意ShardingSphere 5.x 的groupId是org.apache.shardingsphere和 4.x 时期的io.shardingsphere完全不同。老项目的依赖如果继续沿用 4.xAPI 命名和新版是天壤之别。新版使用ShardingSphereDataSource和规则对象旧版则是ShardingDataSourceFactory。3.2 基础数据源配置多数据源场景在引入了 ShardingSphere 之后你不再直接将DataSource配置为 MySQL 的连接地址而是配置一个 ShardingSphere 管理的数据源。举个真实项目里分库分表配置的案例spring: shardingsphere: datasource: names: ds0, ds1 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/db_order_0?useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 maximum-pool-size: 20 ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/db_order_1?useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 maximum-pool-size: 20注意这里用的是jdbc-url而不是url原因是 HikariCP 对 ShardingSphere 的数据源属性名要求是jdbc-url。填错的话HikariPool 初始化时会报“Cannot resolve dataSource property url”排查时很容易抓瞎。生产环境还需要额外设置connection-timeout和validation-timeout避免数据库故障时应用线程被大量阻塞。连接池大小也不是越大越好——MySQL 默认 max_connections 是 151应用侧如果给每个实例都开 100 个连接两台实例就把数据库连接挤爆了。合理经验值单应用实例连接池 20~30 即可。3.3 分片规则配置取模分表 分库ShardingSphere 5.x 使用 YAML 配置分片规则核心是rules部分。这里给出一个按用户 ID 取模分库、订单号范围分表的片段示例spring: shardingsphere: rules: sharding: tables: t_order: actual-data-nodes: ds$-{0..1}.t_order_$-{2023..2024} table-strategy: standard: sharding-column: create_date sharding-algorithm-name: month_range database-strategy: standard: sharding-column: user_id sharding-algorithm-name: user_mod sharding-algorithms: user_mod: type: MOD props: sharding-count: 2 month_range: type: INTERVAL props: datetime-pattern: yyyy-MM-dd HH:mm:ss datetime-lower: 2023-01-01 00:00:00 datetime-interval-amount: 1 datetime-interval-unit: MONTHS分片算法MOD就是按分片键取模这里按user_id % 2路由到ds0或ds1。时间范围分片用的是INTERVAL算法按月切分 2023 到 2024 年的数据到t_order_202301、t_order_202302等物理表。使用时间分片有个重要前提分片键字段必须上索引否则每次查询全分片扫描性能等于全表扫描乘以分片数。路由策略选standard还是complex也要仔细斟酌。单分片键用standard多分片键协同路由时用complex并且需要指定sharding-columns比如同时按订单创建时间和用户 ID 路由。生产环境优先选用“分库键 分表键”联合设计让大多数查询只命中一个库的一张表性能才能达到最优。3.4 MyBatis Mapper 写法与 SQL 优化分库分表之后MyBatis 的 Mapper 写法要多留意。逻辑表名保持不变物理表名交给 ShardingSphere 改写。比如Mapper public interface OrderMapper { Select(SELECT * FROM t_order WHERE user_id #{userId} AND create_date #{startTime}) ListOrder selectByUserAndTime(Param(userId) Long userId, Param(startTime) LocalDateTime startTime); }这个 SQL 里t_order是逻辑表ShardingSphere 会根据user_id和create_date自动匹配物理表。写这类 SQL 时我有一个特别深的体会查询条件里必须带上分片键。如果 SQL 里只写了create_date而没有user_idShardingSphere 只能走全路由——所有库的所有月份表全扫一遍性能直接从 10ms 涨到 1s 甚至更糟。如果有些查询确实没法带分片键可以考虑使用 ShardingSphere 的broadcast表机制或者接受全路由的现实并加一层 Redis 缓存兜底。千万不能不设分片键又期望框架能猜到你要查哪台库这是性能灾难的开端。3.5 事务问题分布式事务处理分库分表后的一个大问题是本地事务失效。你更新了ds0.t_order_202311一条记录同时又更新了ds1.t_order_202311另一条记录原先在单库上的Transactional只能保证其中一个库的一致性跨库场景要配合其他方案。ShardingSphere 5.x 提供了两种分布式事务方案XA 强一致和BASE 最终一致Seata。XA 的配置方式是spring: shardingsphere: props: xa-transaction-manager-type: Atomikos配合代码里的ShardingSphereTransactionType(TransactionType.XA)和Transactional使用。注意XA 事务在数据量小、并发低的场景下很稳定但在高并发下性能损耗比较大每个分支事务都要等待全局事务协调RT 会明显上升。更推荐的是 Seata AT 模式的最终一致性方案。它不锁数据库资源而是通过全局锁和 before-image 快照实现分布式事务的回滚。适合电商下单、库存扣减之类可接受短暂数据不一致、最终必须一致的场景。我项目里用的是 Seata 1.6.1 ShardingSphere 5.x跑了大半年稳定性靠谱。3.6 批量插入性能提升实测前面提到了rewriteBatchedStatementstrue这里说一个具体案例。我们项目里有个定时任务每分钟要从消息队列拉取 3 万条支付流水写入到t_pay_log表。最初用 MyBatis 默认 Executor逐条 INSERT耗时 25 秒。调整方案分两步第一步在 JDBC 连接串加入rewriteBatchedStatementstrue。第二步在 MyBatis 配置中开启批量执行器SqlSession sqlSession sqlSessionFactory.openSession(ExecutorType.BATCH, false); try { PayLogMapper mapper sqlSession.getMapper(PayLogMapper.class); for (PayLog log : logs) { mapper.insert(log); } sqlSession.commit(); } finally { sqlSession.close(); }调整后耗时从 25 秒降到 4 秒左右近 6 倍的提升。原理就是驱动把多条 INSERT 语句拼接成INSERT INTO ... VALUES (...),(...),(...)一次性发给 MySQL大幅减少网络往返次数。MySQL 单次允许的最大包大小默认是 4MBmax_allowed_packet如果一次性插入 5 万行导致包超大需要同时调大这个参数。4. 常见问题与排查技巧实录4.1 驱动版本不兼容引发的一连串问题热词里有个典型错误提示大意是“This version of the JDBC driver is only compatible with Elasticsearch version...”。这其实是连错了目标——你用 MySQL 的 JDBC 驱动去连接 Elasticsearch自然会版本不匹配。排查思路很简单先确认spring.datasource.driver-class-name配的是com.mysql.cj.jdbc.Driver然后确认jdbc.url前缀是不是jdbc:mysql://。如果这些都没错再检查依赖中是否不小心引入了多个版本的 JDBC 驱动Maven 依赖树里出现两个版本时用mvn dependency:tree查看排除脏依赖。还有一个常见的报错com.mysql.cj.exceptions.InvalidConnectionAttributeException: The server time zone value Öйú±ê׼ʱ¼ä。这个乱码是 MySQL 服务端的 timezone 使用了 CST而 Java 无法识别。最简单的修复方式就是在 JDBC 连接串后面加上serverTimezoneAsia/Shanghai。4.2 MySQL 2002 报错排查实录热词里有一条ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock这个问题在本地开发环境特别常见。大概有三层原因服务没启动。macOS 上brew services start mysql后确认进程运行状态再用客户端连接。socket 文件路径不一致。客户端默认找/tmp/mysql.sock而服务端配置socket/var/lib/mysql/mysql.sock两边不在同一处。查看服务端实际 socket 路径mysql -uroot -p -h127.0.0.1 -P3306强制 TCP 连接避免走 socket 文件进去执行show variables like socket;或者检查/etc/my.cnf、/etc/mysql/my.cnf中的配置。访问权限受限。连接串里使用用户rootlocalhost但只有root127.0.0.1的授权时需要用 TCP 协议配合-h指定主机再去验证权限。建议统一方案Java 应用永远通过 TCP 连接jdbc:mysql://127.0.0.1:3306/...不要依赖本地 socket 文件。这样可以把本地开发和服务器部署的差异降到最低减少“本地跑得好好的上服务器就连不上”的尴尬。4.3 MyBatis Update 执行慢的定位思路热词里有“mybatis update 执行慢”。看到这种问题第一步不要怀疑 MyBatis先拿到真实 SQL 去 MySQL 命令行跑一遍。常见症结有三个没走索引UPDATE的 WHERE 条件字段没有索引MySQL 只能全表扫描定位行。用EXPLAIN SELECT * FROM ... WHERE ...查看 type 字段如果是ALL说明妥妥的全表扫描必须补索引。锁等待阻塞UPDATE语句执行慢可能是行锁被其他事务占用在等锁。执行show processlist看是否有Waiting for table metadata lock或Waiting for lock状态找出占用事务并检查代码里事务提交时机。大批量更新导致 undo 膨胀一次性UPDATE大量行InnoDB 在事务提交前要保留 undo log 用于回滚占用大量内存和磁盘也会拖慢整个操作。排查工具推荐挂上performance_schema开启events_statements_history_long能直接看到等待事件和耗时分布。这套链路配齐后大部分 SQL 慢的问题都可以在分钟级别定位到人。4.4 ShardingSphere 路由不生效的解决思路如果你配置了分片规则但查询时发现数据不对或直接报错“Cannot find table rule”注意排查下面几点检查tables下的逻辑表名称是否和 Mapper 里的 SQL 表名大小写一致。MySQL 表名大小写敏感度由lower_case_table_names参数决定开发机器和 Linux 服务器上行为经常不一致。检查 Java 代码里是否通过TableName注解或 XML 里写死了物理表名。ShardingSphere 只能改写它认识的那些逻辑表如果你自己在 SQL 里写了t_order_202311它反而不会去拦截等于完全绕开了分片。使用了 Hint 强制路由时检查hintShardingAlgorithm是否配置到了对应sharding-algorithms。Hint 路由的方式极容易因为键名拼写不一致而失效。一个真实的项目教训我们有一次升级 ShardingSphere 从 4.1.1 到 5.3.2发现原本能命中分片键的查询全部走了全库路由。原因是 5.x 版本对sharding-columns的驼峰转换更严格我们把userId写成了userid导致分片键匹配不上。启用下划线风格命名字段后路由就恢复精准了。这种问题靠 log 翻半天看不出来直接在配置文件里把sharding-columns: user_id规范化最有效。4.5 连接池耗尽问题排查分库分表后连接池特别容易被打满原因前面提过一次跨分片查询会被拆分执行需要同时从多个数据源获取连接。症状日志报HikariPool-1 - Connection is not available, request timed out after 30000ms。排查用show processlist看 MySQL 侧连接数是否打满再用 JVisualVM 或 jstack 看应用侧哪些线程持有连接不放。解决第一把maximum-pool-size调低到合适范围20~30第二精简事务边界避免在长事务中执行多个跨分片查询第三确认没有连接泄漏——比如 MyBatis 批量操作后 SqlSession 没有正确关闭这种连接泄漏排查起来相当耗时间务必用try-with-resources或者在 finally 中关闭。配置一个connection-test-query: SELECT 1虽然简单但在高并发场景会把数据库负载拉高。Hikari 默认用JDBC4 isValid()做连接活性检测比 testQuery 高效得多这个配置不用额外加。4.6 批量插入与分页在 ShardingSphere 下的特殊现象补充两个实战中容易被忽略的场景批量写入场景ShardingSphere 遇到批量 INSERT 时会把一条 SQL 拆分成多次执行分别路由到不同的分片。此时 JDBC 的rewriteBatchedStatements并不生效因为 SQL 已经被中间件接管改写。如果想提升批量插入性能推荐把ExecutorType.BATCH和 ShardingSphere 的max-connections-size-per-query结合调整同时降低每次提交的批次大小减少连接占用。分页深翻页场景在 ShardingSphere 下做LIMIT 100000, 10框架会在每个分片上都执行LIMIT 100000, 10再把结果合并后截取效率极其低下。建议业务上改成“游标分页”的方式——用WHERE id #{lastId} ORDER BY id LIMIT 10每次传上次查询的最后一条 id。实测从深翻页到游标分页后第 100 页以后的查询耗时从 2 秒降到 50 毫秒数据量大时效果极为明显。5. 工具链配置细节与开发调试心得5.1 开发环境配置快速验证清单在本地搭这套环境时我习惯按下面这个顺序依次验证出现问题就卡在对应环节不要一次性全部启动再来排查验证 MySQL 启动状态用命令行客户端连接mysql -uroot -p -h127.0.0.1 -P3306确认能通过 TCP 连接。验证 JDBC 连接写一个只含 JDBC 驱动的 Java main 方法用连接串去拿Connection并执行SELECT 1。这里能排除绝大多数 SSL 和时区参数问题。验证 MyBatis 单表查询不引入 ShardingSphere先只配置 MyBatis确保 Mapper XML 能正常扫描、SQL 能正常执行。引入 ShardingSphere 验证路由配置分片规则后执行插入和查询确认日志中打印了Actual SQL: ds0 ::: SELECT ...看到实际路由到哪个库哪张表。这套顺序走一遍整个链路的故障点就立即清晰了。很多同学一上来就把所有组件全部启动然后不知从何排查根源就是没把问题的“分层”思路理清。5.2 日志输出技巧与调试命令MyBatis 打印的 SQL 日志是最直观的排查工具但要想看 ShardingSphere 的“真实路由结果”光靠 MyBatis 日志还不够。在application.yml中增加logging: level: org.apache.shardingsphere: debug然后执行一条查询观察日志中类似Actual SQL: ds0 ::: SELECT * FROM t_order_202311 WHERE user_id 10086的内容。这里能看到逻辑 SQL 和实际 SQL 的对比是验证分片规则是否生效的关键。另外一个调试技巧全局启用log-impl: org.apache.ibatis.logging.stdout.StdOutImpl后如果 SQL 日志里的占位符?太多手动转成真实参数很麻烦。这时候用 MyBatis 的配置属性mybatis.configuration.map-underscore-to-camel-case: true简化结果映射的同时加上shardingSphere的 debug 日志两边的输出一对SQL 全貌就齐了。5.3 常见工具推荐DBeaver社区版够用连接 MySQL 时自带 SSL 设置提示避免踩useSSL参数的坑。查看表结构、执行计划都很顺手。MySQL Workbench官方工具用于查看 InnoDB 状态、管理用户权限比较合适。热词里也有提到大家在 MySQL 安装配置时常遇到字符集不匹配的问题Workbench 的图形化界面都能直接调整。arthas阿里开源的 Java 诊断工具排查应用中“哪个方法慢”特别好使。用trace命令定位到 Mapper 层耗时再结合 MySQL 慢查询日志判断是应用侧还是数据库侧的问题效率极高。mysqldumpslow / pt-query-digest分析 MySQL 慢查询日志的工具。分页插件执行慢、Update 执行慢这类问题的分析第一步就是让它把 Top 10 慢 SQL 列出来比盲猜强得多。6. 从单库迁移到 ShardingSphere 的踩坑复盘6.1 迁移分片键选择与线上平滑过渡我之前带过一个金融类项目订单表数据量大约 2 亿行。当时刚拆库团队里第一个纠结的问题就是分片键选什么。用户 ID 是天然的业务分片键用户查询订单时可以精准路由但运营人员经常按商户号去查订单这时候没有分片键就只能全分片扫描了。最终方案是双分片键user_id作为主分片键merchant_id通过冗余表映射路由。也就是说写操作按user_id均匀分布读操作如果只带merchant_id先查询映射表找到目标用户再回源查询订单表。这样既保证了写入均匀又满足运营端的高频查询。过渡期间怕的就是“拆库后性能反而下降”。我们当时做了灰度对比先把一个月的数据根据规则拆到双库双表随后把新写入流量切换到 ShardingSphere 数据源查询流量前一小时按 10% 放量确认 RT 稳定后逐步切到 100%。整个过程大约用了两个窗口期数据库连接数、慢查询数、平均耗时都需要监控一格不能少。6.2 分布式主键方案对比分库分表之后单库的自增 ID 不能再用否则多个分片产生的 ID 一定重复。业界常用方案有三个我按实测难度排序雪花算法SnowflakeShardingSphere 内置了这个方案。在 YAML 里配置key-generator即可生成的 ID 是长整型趋势递增适合做索引。唯一注意的地方机器时钟回拨会导致 ID 重复运算时必须有回拨容忍逻辑。UUID最简单32 位字符串缺点是不是数字做索引时容易导致索引碎片并且 Java 生成的 UUID 是无序随机串插入性能下降明显。不推荐作为索引列除非你有类似消息队列 ID 的绑定需求。Redis 自增用 Redis 生成递增序列再结合日期作为前缀性能好、有序但引入了额外的 Redis 依赖需要考虑高可用问题。我实际项目里选的是雪花算法。原因很简单不需要额外维护中间件ShardingSphere 生成全局唯一 ID 已经内置跟分片键配合得最好。还有一点是它在插入时能保持大致有序这让索引写入性能远好于 UUID 那种随机分布。6.3 数据迁移与双写校验迁移时最怕的是旧数据丢失所以会用到双写校验。我们的流程大概是存量数据按分片规则用 DataX 或自研导出程序批量导入到分片表。开启双写阶段旧库写入的同时通过 MQ 异步转发一份到新分片库保证增量数据两边都有。每天跑一次对账程序按主键 ID 对比新旧两边的字段值发现不一致就告警并触发补偿任务。这个方案在生产跑了两周对账差异率从 0.5% 一路降到 0.01% 以下最终才敢把流量完全切到新库。期间排查出的问题包括批次写入时字段为空、串行读出来处理时乱序、旧库的 DELETE 操作没有转发到新库每一个都是经验累积。7. 总结与经验沉淀说了这么多回到最初的问题MySQL MyBatis ShardingSphere JDBC 的价值到底在哪在我看来它最大的价值不是某个单一技术而是给数据访问层提供了一个可演进的架构底座。单机时代Mysql MyBatis 足够支撑几百万到几千万级数据量的业务数据量突破天花板后引入 ShardingSphere 扩容分布式能力而应用代码不需要做翻天覆地的改动。JDBC 是整个链路里最低的通用层任何上层变化都要尊重它的行为。把这些组件的边界认清楚了你才真正掌控了你自己项目的数据库访问能力。我个人在实际操作中最深的体会是这套组合并不意味着你不再需要了解底层原理反而倒逼你把 SQL 写出“能被框架可靠路由”的样子——条件里明确带上分片键事务边界尽量精简连接参数准确配置。这些基本功在任何一个系统里都是通用的。每当我看到有人又复制了一个连接串、又默认配置缓存、又忘了给分片键做索引我就知道他大概率又要踩一遍我当年踩过的坑了。这套技术栈后续还可以继续扩展的方向我个人觉得是结合现代可观测性组件把每个分片上的慢查询、连接池指标、路由命中率都统一收集起来。让数据访问层跟应用层同等透明是大型系统健康运维的必经之路。趁现在项目复杂度还能掌控尽早把基础打牢后面加应用、加流量都不会太慌。