解决mysql驱动连接MariaDB，rs.next()游标报错java.sql.SQLException：The statement (1) has no open cursor——TaoToken

1. 问题现场rs.next() 为什么突然说游标没打开你写了一段再普通不过的 JDBC 查询代码executeQuery()返回了ResultSet结果第一行rs.next()就炸了java.sql.SQLException: The statement (1) has no open cursor这句话的迷惑点在于语句明明执行了ResultSet对象也拿到了为什么游标是「没打开」的状态更奇怪的是同一套代码连 MySQL 一切正常换成 MariaDB 就翻车。这个异常在 Java 应用用 mysql 驱动连 MariaDB 的场景里出现频率相当高尤其是查询里带子查询、UNION、或者你手动设置过fetchSize的时候。先把结论摆出来这个报错的核心不是「连接断了」而是结果集游标在服务端被提前关闭或从未真正打开。MariaDB 和 MySQL 虽然协议高度兼容但在流式结果集Streaming ResultSet的处理策略上有差异。当你用 mysql 的com.mysql.cj.jdbc.Driver去连 MariaDB驱动会按 MySQL 的默认行为走而 MariaDB 服务端在某些查询形态下会提前释放内部游标客户端再去next()就撞上了「no open cursor」。适合谁看正在用 Spring Boot / MyBatis / 原生 JDBC 连 MariaDB却沿用 mysql 驱动或 mysql 风格 URL 的 Java 开发者以及被这个异常卡住、搜到一堆「换驱动」但不知道怎么平滑迁移的人。下面我会给出可复制的 JDBC URL、驱动类名、连接池配置以及一个最小复现用例帮你逐项定位根因。2. 前置准备TaoToken 与驱动环境确认在动手改代码之前先把「模型/接口调试」和「数据库驱动」两条线分开。排查这类 JDBC 异常时我习惯用一个稳定的接口调试入口来验证 SQL 逻辑本身没问题避免把「SQL 写错」和「驱动游标问题」混在一起。TaoToken 的模型对话入口可以用来快速验证一段 SQL 的语义、让模型帮你解释报错栈地址是模型对话https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite接入文档https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite注意TaoToken 在这里的角色是「帮你分析和验证」不是数据库代理也不是让你把生产库直连上去。数据库连接始终走你自己的 JDBC 配置。环境侧你需要确认三件事第一你用的驱动到底是哪个。打开pom.xml或build.gradle看依赖坐标。如果是mysql:mysql-connector-java或com.mysql:mysql-connector-j那就是 mysql 驱动连 MariaDB这正是本篇的场景。如果是org.mariadb.jdbc:mariadb-java-client那属于另一条路线。第二驱动版本。mysql 驱动 8.x 和 5.x 行为差异很大8.x 默认useSSL、时区、allowPublicKeyRetrieval等参数都会影响连接。用mvn dependency:tree | grep mysql或gradle dependencies确认实际生效版本。第三MariaDB 服务端版本。SELECT VERSION();一条就够。10.2 到 11.x 之间流式结果集和子查询游标的处理有细微差别报错形态也会不同。提示不要一上来就换驱动。先用最小复现用例确认是「驱动行为」还是「SQL 形态」触发的否则换完驱动可能只是把问题藏起来。3. 可复制配置JDBC URL、驱动类名与连接池骨架这一节是全文最该抄的部分。先给原生 JDBC 的最小配置再给连接池和框架配置骨架。3.1 JDBC URL 与驱动类名用 mysql 驱动连 MariaDB 时URL 前缀仍然是jdbc:mysql://但建议显式加上几个关键参数把流式行为控制住# mysql 驱动连 MariaDB 的推荐 URL jdbc.urljdbc:mysql://127.0.0.1:3306/your_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrueuseCursorFetchtruedefaultFetchSize1000 jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.usernameyour_user jdbc.passwordyour_pass关键参数逐个说useCursorFetchtrue让驱动使用服务端游标而不是把整个结果集一次性拉到客户端。defaultFetchSize1000给一个合理的批量大小避免Integer.MIN_VALUE那种极端流式设置。serverTimezone不设的话8.x 驱动经常在连接阶段就报时区错。如果你确实需要流式读取大结果集才用下面这种写法并且要清楚它的代价// 仅在需要流式读取超大结果集时使用 PreparedStatement pst connection.prepareStatement( realSql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY ); pst.setFetchSize(Integer.MIN_VALUE); // mysql 驱动的流式开关Integer.MIN_VALUE是 mysql 驱动特有的「逐行流式」信号。问题在于MariaDB 服务端在遇到子查询时可能提前关闭内部游标而客户端还以为流式游标开着于是rs.next()抛no open cursor。所以除非你明确要流式否则别随手加这一行。3.2 连接池骨架HikariCP# application.yml spring: datasource: url: jdbc:mysql://127.0.0.1:3306/your_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiuseCursorFetchtruedefaultFetchSize1000 driver-class-name: com.mysql.cj.jdbc.Driver username: your_user password: your_pass hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 connection-test-query: SELECT 1connection-test-query用SELECT 1就够别用复杂查询否则每次借连接都跑一遍子查询反而容易触发游标问题。3.3 如果你用 MariaDB 官方驱动换驱动是根治方案之一配置骨架如下spring: datasource: url: jdbc:mariadb://127.0.0.1:3306/your_db?useUnicodetruecharacterEncodingutf8useServerPrepStmtstrue driver-class-name: org.mariadb.jdbc.Driver username: your_user password: your_pass注意 URL 前缀从jdbc:mysql://变成jdbc:mariadb://驱动类名也换掉。MariaDB 驱动对自家服务端的游标处理更贴合no open cursor基本不会出现。但迁移前要确认你的 ORM 框架、分页插件、连接池都兼容。3.4 工具侧配置骨架如果你用某些数据库客户端或 AI 辅助工具配置里也会涉及连接串。以settings.json和config.toml为例{ database: { driver: com.mysql.cj.jdbc.Driver, url: jdbc:mysql://127.0.0.1:3306/your_db?useSSLfalseserverTimezoneAsia/ShanghaiuseCursorFetchtruedefaultFetchSize1000, user: your_user, poolSize: 5 } }[database] driver com.mysql.cj.jdbc.Driver url jdbc:mysql://127.0.0.1:3306/your_db?useSSLfalseserverTimezoneAsia/ShanghaiuseCursorFetchtruedefaultFetchSize1000 user your_user pool_size 5这些骨架的重点都是别用Integer.MIN_VALUE流式改用useCursorFetch 合理defaultFetchSize。4. 最小复现与逐项验证定位游标未打开的根因光看配置不够得能复现。下面是一个最小复现用例专门触发子查询 流式游标的组合。4.1 最小复现用例import java.sql.*; public class CursorRepro { public static void main(String[] args) throws Exception { String url jdbc:mysql://127.0.0.1:3306/test_db ?useSSLfalseserverTimezoneAsia/Shanghai; try (Connection conn DriverManager.getConnection(url, user, pass)) { String sql SELECT id, name FROM (SELECT id, name FROM users WHERE id ?) t ORDER BY id; PreparedStatement pst conn.prepareStatement( sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY ); pst.setFetchSize(Integer.MIN_VALUE); // 关键流式开关 pst.setInt(1, 0); ResultSet rs pst.executeQuery(); while (rs.next()) { // 这里可能抛 no open cursor System.out.println(rs.getInt(id) - rs.getString(name)); } } } }跑这段代码如果 MariaDB 服务端在子查询上提前关游标rs.next()就会抛The statement (1) has no open cursor。注意(1)是语句编号不是行号别被误导。4.2 逐项验证动作按顺序做每步只改一个变量第一步去掉pst.setFetchSize(Integer.MIN_VALUE)再跑。如果不报错了说明就是流式设置触发的。这是最常见的根因。第二步保留流式设置但把子查询改成单表查询SELECT id, name FROM users WHERE id ?。如果不报错说明是「流式 子查询」的组合问题MariaDB 对子查询的游标生命周期管理更激进。第三步把 URL 换成useCursorFetchtruedefaultFetchSize1000去掉代码里的setFetchSize(Integer.MIN_VALUE)。这是推荐的生产写法验证是否稳定。第四步换 MariaDB 官方驱动URL 前缀改jdbc:mariadb://重复第一步。如果彻底不报说明驱动层面对接更匹配。第五步检查连接池是否在查询中途回收了连接。把max-lifetime调大或者临时关掉连接池用裸连接跑排除池化干扰。注意no open cursor有时是「连接被关闭」的次生现象。如果连接池在rs.next()循环期间因为超时回收了连接也会报类似错误。所以第五步别跳过。4.3 验证成功的标志改完后你应该看到查询正常返回所有行rs.next()循环走完不抛异常用EXPLAIN看执行计划子查询被正常展开连接池日志里没有频繁的connection reset。如果用了useCursorFetch可以通过SHOW STATUS LIKE Com_stmt_fetch观察服务端游标拉取次数确认走的是游标而非全量拉取。5. 本篇常见错排查清单把踩过的坑列成表对照着查现象可能原因处理动作rs.next()首行就抛 no open cursor用了setFetchSize(Integer.MIN_VALUE)且 SQL 含子查询去掉流式设置改用useCursorFetch查询前几行正常中途抛错连接池回收连接或服务端游标超时调大max-lifetime检查net_write_timeout换 MariaDB 驱动后报类找不到依赖没引入或版本冲突加mariadb-java-client依赖排除旧 mysql 驱动URL 里useSSLtrue连不上MariaDB 未配 SSL测试环境设useSSLfalse生产配证书时区报错The server time zone value8.x 驱动默认时区不匹配URL 加serverTimezoneAsia/Shanghai分页插件报游标错分页 SQL 被改写成子查询 流式关闭分页插件的流式选项或换驱动几个容易忽略的点allowPublicKeyRetrievaltrue在 mysql 8.x 连 MariaDB 时经常需要否则认证阶段就失败useServerPrepStmts在 MariaDB 驱动下建议开启能减少游标问题MyBatis 的fetchSize设置如果配成Integer.MIN_VALUE同样会触发这个异常去mybatis-config.xml里检查。如果排查过程中需要让模型帮你读异常栈、解释某段 SQL 的执行计划可以用模型对话入口贴报错和 SQL让它逐行分析模型对话https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite长期做 Java 后端编码、需要反复调试 JDBC 和 SQL 的话Coding Plan 更适合持续使用Coding Planhttps://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite6. 接入与排障入口回到操作层面给你一条清晰的路径。先确认驱动和 URL再跑最小复现用例然后按第 4 节的五步逐项验证。绝大多数情况下把setFetchSize(Integer.MIN_VALUE)换成useCursorFetchtruedefaultFetchSize1000就能解决no open cursor。如果业务允许迁移到 MariaDB 官方驱动是更彻底的方案。需要生成或管理 API Key 做接口调试的走这里API Keyshttps://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite最后留一个我实际踩过的坑有次排查了半天最后发现是连接池的connection-test-query配了一条带子查询的 SQL每次借连接都触发一次游标问题日志里却只显示业务查询报错。把测试查询改成SELECT 1之后异常直接消失。所以排查时别只盯着业务 SQL连接池的健康检查语句、分页插件的改写 SQL、ORM 自动生成的语句都要看一眼。