1. 这不是“又一个Web框架”——WebFlux连MySQL都敢动到底图什么“WebFlux 操作 MySQL 是种什么体验”——看到这个标题很多后端老手第一反应是皱眉WebFlux 是响应式、非阻塞的MySQL 驱动默认是阻塞的 JDBC这俩放一块儿不就像让高铁开进胡同口听着就别扭。但现实是越来越多项目在真实生产环境里把 WebFlux 和 MySQL 搭在一起用不是为了炫技而是被几个具体问题逼出来的某电商大促期间订单接口 P99 延迟飙到 2.3 秒排查发现 70% 时间卡在数据库连接池等待上某 SaaS 平台用户并发从 5000 涨到 1.2 万Tomcat 线程数拉满GC 频率翻倍扩容三台机器后负载反而更不均衡还有某实时数据看板服务前端轮询频率设为 2 秒结果后端每秒生成 800 个短生命周期的 JDBC 连接连接池频繁回收重建CPU 软中断飙升……这些都不是理论瓶颈是凌晨三点告警群里刷屏的真实截图。核心关键词就三个WebFlux、MySQL、响应式数据访问。它解决的从来不是“能不能连上数据库”这种基础问题而是“当大量轻量级请求比如移动端心跳、IoT 设备状态上报、前端微粒化查询持续涌入时如何让有限的线程资源不被数据库 I/O 卡死”。这里的关键认知差在于很多人以为 WebFlux MySQL 是要彻底抛弃 JDBC其实恰恰相反——它是在 JDBC 的物理约束下用响应式编排做“时间换空间”的调度优化。真正被替换的不是驱动本身而是传统 Controller → Service → DAO 这条链路上的线程绑定模型。你依然用的是 mysql-connector-java 8.0.33依然走的是 TCP 三次握手连 MySQL Server但你的 Spring WebFlux 应用不再为每个 HTTP 请求分配一个专属线程去等 ResultSet.next()而是把“发 SQL”和“收结果”拆成两个可调度的异步事件中间腾出来的线程可以立刻去处理下一个请求的 Header 解析或 JWT 校验。适合谁读如果你正面临以下任一场景这篇就是为你写的用 Spring Boot 2.6 或 3.x已启用 WebFlux 但数据库层还套着 Transactional JdbcTemplate接口压测时线程池总在 80% 以上徘徊业务中存在大量“查一次就扔”的只读操作如用户资料快照、商品库存轻量校验但当前方案每次都要走完整事务模板团队在推进响应式架构改造但 DBA 明确表示“不允许上 R2DBC 驱动因缺乏审计日志/慢 SQL 监控能力”你得在 JDBC 框架内找到折中路径或者你只是好奇当教科书说“JDBC 天然阻塞”而社区又鼓吹“全栈响应式”这两股力撞在一起代码到底长什么样报错堆栈会多出几层 Mono连接池配置数字该调大还是调小接下来的内容不讲 Reactive Streams 规范定义不画 Publisher-Subscriber 关系图只聚焦一件事把 WebFlux 和 MySQL 在真实项目里焊死在一起时你必须亲手拧紧的那几颗螺丝。从驱动选型的底层权衡到连接池参数的毫米级调整再到 Mono/Flux 返回值在 Controller 层的语义陷阱——全是我在三个不同规模项目里踩坑、回滚、再上线后记下的实操笔记。2. 核心设计思路为什么非要“拧巴地”把 WebFlux 和 MySQL 绑一起2.1 不是技术洁癖是线程成本倒逼的架构选择先破除一个迷思WebFlux MySQL 的组合并非追求“绝对零阻塞”。MySQL 官方 JDBC 驱动mysql-connector-java至今未提供原生的异步协议实现底层仍是 socket.read() 阻塞调用。所谓“响应式访问”本质是用事件循环 线程复用把原本属于业务线程的阻塞等待转移到专用的 I/O 线程池中执行。这听起来像文字游戏但对高并发场景意义重大。举个具体例子假设你用 Tomcat Spring MVC单机支持 2000 并发背后是 2000 个线程在等数据库返回。每个线程平均占用内存 1MB含栈空间、局部变量光线程内存就吃掉 2GB。而 WebFlux 默认使用 NettyI/O 线程数通常设为 CPU 核数 × 2比如 16 核机器配 32 个 EventLoop。这 32 个线程通过 Selector 复用能同时管理数万个 TCP 连接。当一个 HTTP 请求需要查 MySQL 时Netty 线程不自己去执行 JDBC而是把“执行 SQL”的任务提交给一个独立的JDBC 执行线程池比如 HikariCP 的内部线程自己立刻返回去处理下一个请求。等 JDBC 线程拿到 ResultSet 后再把结果发布到 Reactor 的事件环上由 Netty 线程消费并写回 HTTP 响应。整个过程Netty 线程不阻塞JDBC 线程只专注 I/O职责清晰资源利用率翻倍。提示这里的关键分界点是“谁来调用 Connection.createStatement()”。在传统 MVC 中这是业务线程干的在 WebFlux 中必须确保这个动作发生在专门的 JDBC 线程池里否则 Netty 线程一旦被 JDBC 阻塞整个事件环就卡死。这也是为什么所有 WebFlux JDBC 方案都强制要求配置 separate JDBC 线程池而不是直接用 Mono.fromCallable(() - jdbcTemplate.query(...)) —— 后者看似简洁实则把阻塞操作扔进了 Netty 线程等于自废武功。2.2 两种主流路径R2DBC vs JDBC Wrapper选哪个不是看文档是看运维能力目前 WebFlux 操作 MySQL 主流就两条路没有第三条R2DBC推荐用于新项目基于 MySQL 的二进制协议重写的纯响应式驱动完全绕过 JDBC。它用 ByteBuf 替代 InputStream用 Flux 替代 ResultSet天然支持背压backpressure。Spring Data R2DBC 提供了类似 JPA 的 Repository 抽象写法接近传统 ORM。但它有硬伤不支持存储过程、不支持 savepoint、部分复杂 SQL如多表 union all order by需手动拼接且最关键的是——DBA 很难监控。R2DBC 的 SQL 日志是打在应用层的慢查询无法被 MySQL 的 slow_log 捕获审计系统也抓不到原始语句这对金融、政务类项目是红线。JDBC Wrapper推荐用于存量改造不换驱动仍用 mysql-connector-java但用 Reactor 工具类包装 JDBC 调用。典型方案是Mono.fromCompletionStage(CompletableFuture.supplyAsync(() - { /* JDBC code */ }, jdbcExecutor))。优势是零学习成本SQL 完全兼容DBA 监控体系无缝接入劣势是需要手动管理线程池背压支持弱因为 JDBC 本身不支持高并发下容易出现“下游消费者来不及消费上游 JDBC 线程池积压任务”的雪崩。我参与的三个项目中两个选择了 JDBC Wrapper 路径一个是某高校教务系统因历史原因必须保留 Oracle 和 MySQL 双库而 Oracle 官方无 R2DBC 驱动统一技术栈只能选 JDBC另一个是某物流轨迹平台其 MySQL 集群启用了定制版审计插件R2DBC 的二进制协议会绕过插件导致合规风险。只有第三个全新 IoT 数据接入平台因数据写入频次极高每秒 5 万设备上报且无强审计需求才上了 R2DBC。注意网上很多教程说“R2DBC 性能比 JDBC 快 3 倍”这是严重误导。在单次查询场景下R2DBC 因少了 JDBC 的 Statement 解析开销确实快 10%~15%但在高并发批量查询时瓶颈往往在 MySQL Server 的连接数、buffer pool 命中率、网络带宽驱动层差异可忽略。真正拉开差距的是连接复用效率——R2DBC 的 Connection 是真正的轻量级对象创建销毁几乎无成本而 JDBC 的 Connection 依赖底层 socket频繁新建会触发 TIME_WAIT 状态堆积。所以 R2DBC 的优势不在“单次更快”而在“扛住更高连接密度”。2.3 架构分层必须重构Controller 层的 Mono 不是终点而是起点很多开发者以为把 Controller 方法返回值改成 Mono 就算完成响应式改造。这是最危险的认知偏差。真正的分层重构要从 Controller 往下穿透三层Controller 层只做 HTTP 协议转换不碰业务逻辑。例如GetMapping(/user/{id}) public MonoResponseEntityUser getUser(PathVariable Long id)这里 Mono 表示“HTTP 响应体的生成是异步的”但绝不意味着里面能塞 service.getUser(id).map(...) 这样的链式调用——因为 service 层若没响应式化map 里的代码仍在阻塞线程上执行。Service 层必须声明为响应式契约。传统public User getUser(Long id)要改为public MonoUser getUser(Long id)。重点来了这个 Mono 的源头必须是数据访问层的响应式返回值不能是 new Mono.just(jdbcTemplate.queryForObject(...))。后者只是把同步结果包了一层壳线程阻塞问题丝毫未解。Repository 层这才是真正的分水岭。若选 R2DBC用DatabaseClientSqlResult若选 JDBC Wrapper则必须用Mono.fromCompletionStage()包装CompletableFuture且CompletableFuture的 supplier 必须运行在专用 JDBC 线程池中。任何跨层的.block()调用比如在 Service 层调用 repository.getUser(id).block()都是自杀行为会立即让 Netty 线程陷入阻塞。我见过最典型的反模式是开发为快速上线在 Repository 层写return Mono.just(jdbcTemplate.queryForObject(sql, args, User.class))然后在 Controller 层加Async注解试图“解耦”。结果压测时线程池耗尽错误日志里全是java.lang.IllegalStateException: block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-epoll-3—— 这说明 Netty 线程reactor-http-epoll-3正在执行 block()而 Reactor 明确禁止这种操作。3. 实操细节从驱动引入到连接池调优每一行配置都有讲究3.1 Maven 依赖版本对不上连编译都过不了WebFlux MySQL 的依赖组合极其敏感稍有不慎就会出现NoSuchMethodError或ClassCastException。以下是经过生产验证的最小可行组合以 Spring Boot 3.2.0 为例!-- WebFlux 核心 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-webflux/artifactId /dependency !-- 若选 R2DBC 方案 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-r2dbc/artifactId /dependency dependency groupIdio.r2dbc/groupId artifactIdr2dbc-mysql/artifactId version1.1.3/version !-- 必须与 spring-boot 版本匹配 -- /dependency !-- 若选 JDBC Wrapper 方案 -- dependency groupIdcom.h2database/groupId artifactIdh2/artifactId scoperuntime/scope /dependency !-- 注意mysql-connector-java 8.0.33 是最后一个支持 JDK 17 的稳定版 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version scoperuntime/scope /dependency关键点解析r2dbc-mysql 版本必须严格对应 Spring Boot 版本。Spring Boot 3.2.x 对应 r2dbc-mysql 1.1.x而 1.0.x 只支持 Boot 2.7。网上很多教程用 0.8.x 版本那是针对 Spring Boot 2.3 的强行升级会导致io.r2dbc.spi.R2dbcNonTransientException类找不到。mysql-connector-java 8.0.33 是分水岭。8.0.33 之后的版本如 8.1.x移除了com.mysql.cj.jdbc.MysqlConnectionPoolDataSource类而某些 JDBC Wrapper 工具如 r2dbc-proxy依赖此类型会导致启动失败。所以宁可保守用 8.0.33。HikariCP 不需要显式引入。Spring Boot 3.x 默认内置 HikariCP 5.0.x但它的HikariConfig类在 5.0.0 中新增了setInitializationFailTimeout()方法若你代码里手动 new HikariConfig() 并调用此方法而实际加载的是旧版 Hikari如 4.0.3就会报 NoSuchMethodError。因此所有连接池配置必须通过application.yml完成避免手写 new。3.2 application.yml 配置12 个参数每个都影响 P99 延迟下面是一份生产环境实测有效的 JDBC Wrapper 方案配置R2DBC 配置逻辑不同后文单独说明spring: datasource: url: jdbc:mysql://10.0.1.100:3306/mydb?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: app_user password: ${DB_PASSWORD} driver-class-name: com.mysql.cj.jdbc.Driver hikari: # 1. 连接池大小不是越大越好 maximum-pool-size: 32 # 2. 最小空闲连接设为 0避免冷启动时建连延迟 minimum-idle: 0 # 3. 连接存活时间必须小于 MySQL 的 wait_timeout默认 28800 秒 max-lifetime: 25200 # 4. 连接测试启用但用最轻量的 SQL connection-test-query: SELECT 1 # 5. 获取连接超时WebFlux 场景建议设小避免请求长时间挂起 connection-timeout: 3000 # 6. 空闲连接回收配合 minimum-idle0避免空闲连接占资源 idle-timeout: 60000 # 7. 初始化连接数WebFlux 不需要预热设为 0 initialization-fail-timeout: -1 # 8. 关键禁用 Spring Boot 自动配置的 DataSourceTransactionManager # 因为 WebFlux 不支持 Transactional 的同步事务语义 autoconfigure: exclude: org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration # 9. 自定义 JDBC 执行线程池核心 task: jdbc-executor: core-pool-size: 16 max-pool-size: 64 queue-capacity: 200 keep-alive-seconds: 60 # 10. WebFlux 服务器调优 webflux: server: # 11. Netty 线程数CPU 核数 × 2 是黄金比例 netty: resources: # 12. 降低默认的连接空闲超时避免连接堆积 idle-timeout: 30s逐条解释为何这样设maximum-pool-size: 32这是最容易误配的参数。很多人想“反正机器内存够池子开大点”结果导致 MySQL Server 的max_connections被打爆。计算公式是WebFlux 实例数 × maximum-pool-size ≤ MySQL max_connections × 0.7。假设你有 4 台应用实例MySQL max_connections500则单实例最大池子不能超过 87但实际我们设 32因为还要预留连接给后台任务、管理端口等。32 个连接在 16 核机器上配合 16 个 JDBC 执行线程能实现 2:1 的连接/线程比避免线程争抢连接。minimum-idle: 0传统 MVC 为减少首次请求延迟会设 minimum-idle5但 WebFlux 的请求模型是“短连接、高频率”空闲连接长期不被使用反而浪费资源。设为 0 后连接按需创建用完即毁HikariCP 的连接回收速度极快实测 10ms 内。max-lifetime: 252007 小时MySQL 的wait_timeout默认 8 小时但网络设备如 SLB、防火墙常设 30 分钟空闲断连。如果连接池里的连接活过网络设备的超时下次取出时会报Communications link failure。所以 max-lifetime 必须小于所有中间件的空闲超时取 7 小时是安全值。connection-timeout: 30003 秒这是最关键的超时。在 WebFlux 中一个请求的总耗时 Netty 线程处理时间 JDBC 线程执行时间 网络传输时间。如果 JDBC 执行卡住如锁表connection-timeout 就是最后的保险丝。设 3 秒意味着当数据库响应慢于 3 秒HikariCP 会抛出HikariPool$PoolInitializationException上层 Mono 会 onError你可以统一降级返回缓存或空数据而不是让请求无限等待。jdbc-executor 的 core-pool-size: 16这个线程池专供 JDBC 调用其大小必须 ≤ maximum-pool-size32否则会出现“线程数 连接数”的饥饿状态。16 是经验值16 核 CPU每个核心处理 1 个 JDBC 任务基本不排队。max-pool-size 设 64 是为应对突发流量queue-capacity200 是缓冲区防止瞬间洪峰把线程池打垮。idle-timeout: 30sNetty 默认空闲超时是 60 秒但我们的业务场景如移动端心跳要求更快释放连接。设 30 秒后空闲连接自动关闭节省文件描述符Linux 系统单进程默认 1024 个 fd用完会报Too many open files。3.3 R2DBC 方案实操从 URL 到 Repository避不开的 5 个坑若你选择 R2DBC配置更简洁但陷阱更隐蔽spring: r2dbc: url: r2dbc:mysql://10.0.1.100:3306/mydb?zeroDateTimeBehaviorconvertToNullserverTimezoneAsia/Shanghai username: app_user password: ${DB_PASSWORD} # R2DBC 不需要 HikariCP它有自己的连接池 pool: max-size: 128 min-idle: 0 acquire-timeout: 30s max-life-time: 30m validation-query: SELECT 1R2DBC 的 URL 前缀是r2dbc:mysql://不是jdbc:mysql://且不支持 useSSLfalse 这种 JDBC 参数SSL 控制通过sslModeDISABLED实现。实测中以下 5 个问题最高频时区问题R2DBC 的serverTimezone参数必须用Asia/Shanghai不能用GMT%2B8否则解析失败报Unable to determine the time zone。这是因为 R2DBC 的 URL 解析器不识别 URL 编码格式。NULL 值映射MySQL 的DATETIME字段存0000-00-00 00:00:00时JDBC 驱动默认转成null但 R2DBC 会抛DateTimeParseException。解决方案是在 URL 加zeroDateTimeBehaviorconvertToNull或在实体类字段上加Column(nullable true)。批量插入性能陷阱R2DBC 的DatabaseClient.insert()不支持 JDBC 那样的addBatch()必须用Flux.fromIterable(list).flatMap(item - databaseClient.insert().into(...).using(item).then())。但这样会发起 N 次独立 SQL性能极差。正确做法是手写INSERT INTO table VALUES (?,?),(?,?)的多值语法用DatabaseClient.sql()执行。事务传播失效R2DBC 的Transactional只支持REQUIRED和REQUIRES_NEW不支持SUPPORTS或NOT_SUPPORTED。且事务必须在同一个DatabaseClient实例中执行跨 Bean 调用时若没用Autowired DatabaseClient而是 new 出来的事务会丢失。连接泄漏R2DBC 的Connection是 Flux必须显式调用.doFinally(signalType - connection.close())否则连接不会归还池子。Spring Data R2DBC 的ReactiveCrudRepository会自动处理但手写DatabaseClient时极易遗漏。3.4 Repository 层代码实录JDBC Wrapper 的标准写法这是生产环境跑了一年多的 JDBC Wrapper Repository 示例包含异常处理和线程池注入Repository public class UserRepository { private final JdbcTemplate jdbcTemplate; private final Executor jdbcExecutor; // 从配置类注入的专用线程池 public UserRepository(JdbcTemplate jdbcTemplate, Qualifier(jdbcExecutor) Executor jdbcExecutor) { this.jdbcTemplate jdbcTemplate; this.jdbcExecutor jdbcExecutor; } public MonoUser findById(Long id) { String sql SELECT id, name, email FROM user WHERE id ?; // 关键用 CompletableFuture.supplyAsync 包装指定线程池 return Mono.fromCompletionStage( CompletableFuture.supplyAsync(() - { try { // 这里才是真正的 JDBC 调用运行在 jdbcExecutor 线程中 return jdbcTemplate.queryForObject(sql, new Object[]{id}, (rs, rowNum) - new User(rs.getLong(id), rs.getString(name), rs.getString(email))); } catch (EmptyResultDataAccessException e) { // 将 JDBC 异常转为响应式语义 throw new UserNotFoundException(User not found: id); } }, jdbcExecutor) ); } // 支持背压的批量查询重要 public FluxUser findAllByIdIn(ListLong ids) { if (ids.isEmpty()) { return Flux.empty(); } // 构建 IN 查询避免 SQL 注入 String placeholders ids.stream().map(i - ?).collect(Collectors.joining(,)); String sql SELECT id, name, email FROM user WHERE id IN ( placeholders ); Object[] args ids.toArray(); return Flux.fromStream(() - { // 使用 Stream 支持背压下游消费慢时上游自动减速 ListUser users jdbcTemplate.query(sql, args, (rs, rowNum) - new User(rs.getLong(id), rs.getString(name), rs.getString(email))); return users.stream(); }).subscribeOn(Schedulers.fromExecutor(jdbcExecutor)); } }关键技巧supplyAsync的第二个参数jdbcExecutor必须传入否则默认用 ForkJoinPool.commonPool()会污染全局线程池。EmptyResultDataAccessException是 Spring JDBC 的标准异常但 Mono 不认识它必须手动throw new UserNotFoundException让全局异常处理器捕获。findAllByIdIn用Flux.fromStream()而不是Flux.fromIterable()因为后者会一次性加载全部数据到内存而fromStream()支持背压当 HTTP 响应写入慢时如客户端网速差上游 JDBC 查询会自动暂停避免 OOM。4. 实操全流程从本地调试到线上灰度一个都不能少4.1 本地开发调试用 H2 数据库模拟 MySQL但要注意 3 个差异点本地开发绝不能直连测试库必须用内存数据库。H2 是最佳选择但它的 SQL 语法和 MySQL 有细微差别不注意会在线上出问题自增主键语法MySQL 用AUTO_INCREMENTH2 用IDENTITY。建表语句要写成CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, -- MySQL 写法 name VARCHAR(50) )在 H2 中AUTO_INCREMENT会被自动识别为IDENTITY但某些旧版 H21.4.200 之前不支持需显式写id BIGINT PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY。日期函数MySQL 的NOW()在 H2 中是CURRENT_TIMESTAMP。Spring Boot 的schema-h2.sql文件里所有INSERT INTO user VALUES (1, NOW())必须改为INSERT INTO user VALUES (1, CURRENT_TIMESTAMP)。索引命名冲突MySQL 允许同名索引跨表H2 要求索引名全局唯一。如果多个表都有idx_user_nameH2 启动会报Index already exists。解决方案是给索引加前缀idx_user_name→idx_user_name_idx。调试时开启 H2 Consolespring.h2.console.enabledtrue访问http://localhost:8080/h2-console用jdbc:h2:mem:testdb连接能实时查看数据变化。但注意H2 的事务隔离级别默认是READ_UNCOMMITTED而 MySQL 是REPEATABLE_READ所以本地测不出幻读问题必须在测试环境用真 MySQL 验证。4.2 单元测试Mock JDBC 还是集成测试我的答案是“双轨制”WebFlux MySQL 的测试必须分两层单元测试Unit Test用ExtendWith(MockitoExtension.class)MockBean JdbcTemplate验证 Service 层的 Mono 链式调用逻辑。例如Test void shouldReturnUserWhenIdExists() { // Given User expected new User(1L, Alice, aliceexample.com); when(jdbcTemplate.queryForObject(anyString(), any(Object[].class), any(RowMapper.class))) .thenReturn(expected); // When StepVerifier.create(userService.findById(1L)) .expectNextMatches(user - user.getId().equals(1L)) .verifyComplete(); }这里用StepVerifier验证 Mono 行为不启动 Web 容器速度快毫秒级。集成测试Integration Test用SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT)AutoConfigureTestDatabase(replace AutoConfigureTestDatabase.Replace.NONE)连接真实的 H2 内存库验证整个 WebFlux 流水线。重点测Controller 层的 HTTP 状态码、响应头是否正确异常是否被全局ControllerAdvice捕获并转成标准 JSON背压是否生效用Flux.interval(Duration.ofMillis(100)).take(1000)模拟慢消费者。注意集成测试必须设置spring.r2dbc.url或spring.datasource.url为 H2否则会尝试连线上 MySQL导致测试失败。我在某次 CI 流水线中就因忘记配TestConfiguration导致 200 个测试用例全部连错库构建耗时从 2 分钟涨到 25 分钟。4.3 线上灰度发布用 Spring Cloud Gateway 做流量染色精准控制WebFlux MySQL 改造是高危操作必须灰度。我们采用 Spring Cloud Gateway 的RequestHeaderRoutePredicateFactory根据请求头X-Feature-Flag: webflux-db决定路由spring: cloud: gateway: routes: # 新 WebFlux 链路 - id: webflux-service uri: lb://webflux-app predicates: - HeaderX-Feature-Flag, webflux-db filters: - StripPrefix1 # 老 MVC 链路兜底 - id: mvc-service uri: lb://mvc-app predicates: - HeaderX-Feature-Flag, mvc-db - Path/api/user/**灰度分三步第一阶段1% 流量所有请求默认走 MVC仅对内部测试账号如X-User-ID: test-123的请求添加X-Feature-Flag: webflux-db头观察日志中的Mono.onEachOperator记录确认无block()调用。第二阶段10% 流量按地域灰度比如只放开华东区 IP 段10.10.*.*用 Gateway 的RemoteAddrRoutePredicateFactory配合X-Forwarded-For头。第三阶段全量监控 24 小时确认 MySQL 的Threads_running指标下降 40%P99 延迟稳定在 120ms 以内再切全量。关键监控指标Netty 线程池使用率reactor.netty.http.server.requests.rate每秒请求数 vsreactor.netty.http.server.data.received.bytes.total接收字节数比值异常升高说明 Netty 线程在处理大 Body需优化。JDBC 线程池队列长度task.jdbc-executor.queue.size持续 50 表示 JDBC 线程不足需调大max-pool-size。MySQL 连接数show status like Threads_connected应稳定在maximum-pool-size × 实例数 × 1.2以内。5. 常见问题与排查技巧实录那些让你凌晨三点爬起来的日志5.1 典型问题速查表问题现象错误日志关键词根本原因解决方案接口响应慢P99 2sHikariPool-1 - Connection is not available, request timed out after 3000ms.HikariCP 连接池耗尽JDBC 线程池积压检查task.jdbc-executor.queue.size增大max-pool-size或优化慢 SQLMono 返回空但数据库有数据EmptyResultDataAccessExceptionRepository 层未捕获此异常Mono 被 onError 终止在supplyAsync中 catchEmptyResultDataAccessException返回null或自定义异常应用启动失败报NoSuchBeanDefinitionException: DatabaseClientNo qualifying bean of type io.r2dbc.spi.ConnectionFactoryR2DBC 依赖未引入或spring.r2dbc.url未配置检查pom.xml是否漏spring-boot-starter-data-r2dbc确认application.yml中spring.r2dbc.url格式正确日志里大量Connection has been closedjava.sql.SQLException: Connection has been closed连接被 HikariCP 回收但业务代码还在用检查是否有PostConstruct方法中提前获取 Connection 并缓存必须改为每次请求新建R2DBC 查询返回 null但 H2 中数据正常DateTimeParseException: Text 0000-00-00 00:00:00 could not be parsedMySQL 的 zeroDateTimeBehavior 未配置在 R2DBC URL 中添加zeroDateTimeBehaviorconvertToNull5.2 独家排查技巧三招定位“幽灵阻塞”有些阻塞不会报错但会让 P99 延迟悄悄爬升。我总结了三招“无侵入式”诊断法第一招线程堆栈快照分析当发现延迟升高时立即执行jstack -l pid thread_dump.txt在thread_dump.txt中搜索reactor-http-epoll看是否有线程状态为RUNNABLE但堆栈停留在java.net.SocketInputStream.socketRead0。如果有说明 Netty 线程正在执行 JDBC 阻塞调用——检查是否误用了Mono.block()或Flux.toStream().collect()。第二招HikariCP 内置监控HikariCP 提供 JMX 接口访问jconsole→ MBeans →com.zaxxer.hikari→HikariPool-1→Pool查看 ActiveConnections