先说个结论Spring Boot 应用启动阶段“连 MySQL 很慢”十次里有八次不是 MyBatis-Plus 的问题卡住的反而是 JDBC 连接建立、连接池初始化或 MySQL 侧握手。有人把关键词从 mybatis-plus 改成 mybatis-plush搜索引擎都迷惑了问题依然还在。今天我把这条链路从头拆到尾启动日志怎么看、连接池到底干了什么、MySQL 为什么迟迟不回包最后给出一套能直接抄的配置覆盖 DNS 反查、TCP 超时、认证握手和连接池预热这几个最常见的坑。这套内容适合正在被“Service 启动 20 秒、其中 17 秒都在等数据库”困扰的开发者也适合刚接触 Spring Boot 和 MyBatis-Plus 的新人。我会尽量把每一步解释清楚而不是丢给你一堆参数让你硬背。1. 先把“慢”钉死在具体环节1.1 启动日志里最值得看的两行时间戳排查这个问题第一步不是看 Spring Boot 启动 Banner也不是打开 MyBatis-Plus 的 SQL 日志而是找到 HikariCP 这两行日志2025-01-05 09:15:01.203 INFO [main] com.zaxxer.hikari.HikariDataSource : biz-pool - Starting... 2025-01-05 09:15:01.478 INFO [main] com.zaxxer.hikari.HikariDataSource : biz-pool - Start completed.如果你的日志长这样两行之间只差 275ms说明数据库连接层基本没问题。真正的问题可能在其他 Bean 初始化或者某个启动阶段执行的 SQL 上。如果两行之间差出 5 秒、10 秒甚至更久2025-01-05 09:15:01.203 INFO [main] com.zaxxer.hikari.HikariDataSource : biz-pool - Starting... 2025-01-05 09:15:21.198 INFO [main] com.zaxxer.hikari.HikariDataSource : biz-pool - Start completed.这就说明问题很可能出在“物理连接建立”这个过程上。你要先盯住这个区间再去改配置而不是在 MyBatis-Plus 的 XML 映射文件里浪费时间。1.2 把“连接慢”拆成三种类型我在实际排查时会把现象拆成三类避免被表象带偏类型典型表现责任方连接建立慢Hikari 的 Starting 和 Start completed 之间差距大JDBC 驱动、网络、DNS、MySQL 服务器首次查询慢连接池初始化很快但第一个 Mapper 方法调用卡顿懒加载连接、首次 SQL 编译、认证握手延迟整体启动慢池日志看着正常但 Started Application 前面那段日志消失了MyBatis-Plus 扫描、PostConstruct 代码、多数据源初始化很多开发者只在日志里看到整体启动时间变长就下意识认为是“MyBatis-Plus 连数据库慢”。其实要先定位到具体区间才知道该往哪个方向查。把这三种类型对照着看后续排查会少走很多弯路。2. 逐层复盘为什么连接就是快不起来2.1 DNS 反查是第一大嫌疑人MySQL 在收到客户端 TCP 连接后默认会对客户端的 IP 做一次反向 DNS 解析目的是和用户表里的 host 字段做匹配。如果解析畅通几百毫秒内就能完成如果内网 DNS 查不到记录、解析超时或者请求被防火墙拦截连接就会一直悬在那里表现就是“明明 MySQL 活着但应用启动时连库要等十几秒”。这个问题在容器和 Kubernetes 环境里尤其常见。客户端 IP 是动态分配的根本不存在对应的 PTR 记录MySQL 会一直等到 DNS 查询超时。你从应用容器里ping数据库地址没问题直接命令行连 MySQL 也正常但应用启动就是慢原因往往是双方不在同一个网络命名空间下DNS 响应被放大了。最直接的验证方法是在 MySQL 服务器上执行SHOW GLOBAL VARIABLES LIKE skip_name_resolve;如果结果是OFF而你的客户端 IP 无法反解那基本就可以锁定这个原因了。解决办法很简单在my.cnf的[mysqld]段加上skip_name_resolve注意开启后MySQL 的用户授权就不能再用usersome.hostname这种域名形式只能使用 IP 或通配符若线上账户是按域名分配的改之前要提前核对好权限配置。2.2 JDBC URL 里缺了连接超时参数排查过几十次这类问题后我基本会把“连接慢”分成两类一类是网络环境复杂导致的慢另一类是压根没设置超时导致的“慢性死亡”。很多人的 JDBC URL 长这样jdbc:mysql://localhost:3306/demo?useUnicodetruecharacterEncodingutf8没有connectTimeout也没有socketTimeout。JDBC 驱动和 TCP 层在连接失败或握手缓慢时会按照操作系统的 TCP 超时策略重试默认可能需要几十秒甚至一分钟。我的习惯是至少补上这两个参数jdbc:mysql://127.0.0.1:3306/demo?connectTimeout3000socketTimeout60000connectTimeout3000表示 TCP 连接建立最多等 3 秒连不上就直接抛异常而不是让应用傻等。socketTimeout60000表示建立连接成功后单次读写操作最多等 60 秒避免某个慢 SQL 把连接挂死。这里有个容易搞混的点HikariCP 里的connection-timeout其实是“从连接池获取一条连接的最大等待时间”不是“JDBC 建立物理连接的等待时间”。很多人只改了 Hikari 的connection-timeout但 JDBC URL 里的connectTimeout没改问题依然存在。2.3 认证握手与 SSL 的开销被低估了MySQL 8 默认使用的caching_sha2_password认证插件在非 SSL 连接下第一次握手需要通过 RSA 公钥交换来验证密码。如果应用所在网络到数据库的延迟较高或者驱动版本太老、没启用公钥获取机制握手阶段就会多出好几次网络往返。常见的情况是连接不是建立不起来而是“每次建立都要多几百毫秒”。单独看一次无所谓但连接池启动时要创建多条连接累加起来就能砸出几秒的启动延迟。如果是在内网或开发环境且安全策略允许可以考虑在 JDBC URL 中加入sslModeDISABLEDallowPublicKeyRetrievaltruesslModeDISABLED可以避免 SSL 握手的额外往返allowPublicKeyRetrievaltrue允许客户端从服务器获取 RSA 公钥。但这里必须提醒生产环境是否允许禁用 SSL、是否允许明文传输一定要以公司的安全规范为准这条路适合本地排障不适合无脑照抄。2.4 连接池初始化策略影响启动速度Spring Boot 2.x 之后默认使用 HikariCP它对连接池的启动策略是保守的默认会在池初始化时尝试获取一条连接用于确认数据库可达。如果数据库响应慢这条初始连接就会把启动过程拉长。如果你想缩短启动时间不是把maximum-pool-size调小而是要检查两个参数minimum-idle池中最小空闲连接数。如果设置成 2启动时往往至少创建 2 条连接。initialization-fail-timeout控制启动阶段获取初始连接的超时行为。保持默认即可不建议为了“快”直接设成 -1那样数据库挂了应用可能也不会快速失败。另外一个非常容易被忽略的点如果项目里配置了“多数据源”或者“动态数据源”每一个 DataSource 都对应一个独立连接池启动时都会执行一次初始化。连接池数量翻倍启动耗时基本也是成倍增加。我之前接手过一个项目四个数据源全在主类初始化阶段一起拉连接启动直接慢到 40 秒。后来确认其中两个数据源根本不是所有模块都需要改成按需装配后启动时间立刻降下来了。2.5 MyBatis-Plus 到底背不背这个锅MyBatis-Plus 创建SqlSessionFactory时主要是扫描 Mapper 接口、解析 XML 文件、初始化实体元数据。这一步通常不涉及数据库连接不会因为表多、字段多而让 MySQL 连接变慢。那为什么很多人觉得是 MyBatis-Plus 的问题因为项目里很可能存在“启动阶段就调用了 Mapper”的代码。最常见的是在PostConstruct、ApplicationRunner、CommandLineRunner里写了几行初始化逻辑比如启动时加载菜单表、加载字典表、统计订单量。这些 SQL 一执行连接池才真正开始创建物理连接延迟就会落到“Spring Boot 启动”这个大时间段里。排查方法很简单看启动日志里“Started Application”前面的最后几步。如果能看到类似“加载字典表”“初始化权限数据”这类业务日志那就不是连接池的问题而是业务初始化 SQL 拖慢了整体启动和 MyBatis-Plus 本身没什么关系。3. 一步步定位问题别凭感觉改配置3.1 先用命令行量一遍“原始连接”耗时把应用放一边先在应用同一台机器上执行time mysql -h 127.0.0.1 -u demo -pdemo123 -e select 1如果这条命令本身就要 5 秒、10 秒那问题一定出在 MySQL 侧或网络侧应用侧怎么调连接池都没用。如果想进一步确认 TCP 层情况可以测一下端口连通时间time nc -vz 127.0.0.1 3306nc只做 TCP 握手不走 MySQL 认证。如果nc很快但mysql命令行很慢说明问题在握手/认证阶段如果nc都慢说明 TCP 链路本身就有问题需要查防火墙、路由、安全组。3.2 看 MySQL 侧的真实状态连接慢不一定是 MySQL 在偷懒也可能是一堆僵尸连接把线程池挤满了。登录 MySQL 执行SHOW GLOBAL STATUS LIKE Threads_created; SHOW GLOBAL STATUS LIKE Connections; SHOW GLOBAL VARIABLES LIKE connect_timeout; SHOW PROCESSLIST;Threads_created如果特别大说明有大量线程被频繁创建和销毁MySQL 每次创建线程都要消耗内存和 CPU。借助performance_schema你还可以看到连接的耗时分布。另一个细节connect_timeout默认是 10 秒它指的是 MySQL 服务器等待客户端完成认证握手的最长时间。网络状况很差时应用侧connectTimeout3000先断了MySQL 还没等到超时这个参数对“连接慢”的影响没有大家想的那么大但也不妨看一眼。3.3 打开 Hikari 和 JDBC 驱动日志到了应用侧把日志级别打开可以帮助确认连接请求到底卡在哪一步logging: level: com.zaxxer.hikari: DEBUG com.mysql.cj.jdbc: DEBUGHikari 的 DEBUG 日志会打印连接创建、连接获取、连接释放的过程。JDBC 驱动的 DEBUG 日志能看到驱动是否在做认证、是否在做元数据读取。如果看不到明显异常再用jstack pid抓一下线程栈重点看main线程是否阻塞在SocketInputStream.read或SocketOutputStream.write这类方法上。这一步适合做最后确认。大多数情况下先用命令行和 MySQL 状态就能定位到 80% 的问题不必每次都上线程转储。4. 一套可以直接上手的优化配置4.1 JDBC URL 的最终形态推荐把连接串写成这样至少覆盖connectTimeout、socketTimeout、时区和公钥获取这几个点spring: datasource: url: jdbc:mysql://127.0.0.1:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiconnectTimeout3000socketTimeout60000useSSLfalseallowPublicKeyRetrievaltrue注意我把localhost写成了127.0.0.1。Java 解析localhost时可能先尝试 IPv6 地址::1如果环境关闭了 IPv6解析超时会再退回 IPv4白白浪费几秒。开发环境直接用127.0.0.1最省事。4.2 HikariCP 连接池参数spring: datasource: hikari: pool-name: biz-pool minimum-idle: 2 maximum-pool-size: 10 connection-timeout: 3000 validation-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000解释一下这些参数的实际作用minimum-idle: 2保证池里至少预留 2 条空闲连接避免首次请求时才现建连接。maximum-pool-size: 10对一个常规业务服务来说已经足够不需要动不动就设 20、30。connection-timeout: 3000应用线程从池中拿不到连接时最多等 3 秒之后直接报错不让业务无限阻塞。max-lifetime: 1800000连接最长存活 30 分钟需要小于 MySQL 的wait_timeout否则 MySQL 侧已把连接断开连接池却还在复用。很多人漏掉max-lifetime结果白天业务量上来以后出现偶发连接异常查半天才发现是连接被 MySQL 服务端提前关闭了。连接池参数不只是管启动也会影响运行期的稳定性。4.3 MySQL 服务端参数调整如果确认是 MySQL 一侧的问题可以在my.cnf里做以下调整[mysqld] skip_name_resolve connect_timeout 10 wait_timeout 28800 interactive_timeout 28800 max_connections 300skip_name_resolve的优先级是最高的它从根源上避免了 DNS 反查。max_connections不要拍脑袋调成几千连接数是需要内存的设置过大在并发不高时反而浪费资源。改完my.cnf记得重启 MySQL并用下面的命令确认SHOW GLOBAL VARIABLES LIKE skip_name_resolve;4.4 系统与容器层面的优化如果应用跑在容器里检查一下 JVM 是否启用了 IPv6 解析优化。可以在启动命令中加入-Djava.net.preferIPv4Stacktrue这个参数和 JDBC URL 里用127.0.0.1是一套组合拳能明显减少因为 DNS、IPv6 解析导致的额外等待。另一个容易忽略的优化点是 Mapper 扫描路径。MyBatis-Plus 扫描时如果写成MapperScan(com.example.**.mapper)扫描范围过大启动期会做大量无意义的类加载和资源扫描。虽然这不是“连接 MySQL 慢”但会叠加在启动耗时上让你误判为数据库问题。建议把包路径尽量写精确比如MapperScan(com.example.module.user.mapper)5. 常见问题速查与实操经验5.1 一个速查表按现象对号入座现象可能原因优先处理方式Hikari Starting 到 Start completed 卡十几秒DNS 反查、网络握手慢MySQL 开启skip_name_resolveJDBC URL 加connectTimeout启动时报连接超时但 MySQL 单独连没问题防火墙、安全组拦截或驱动版本过旧先测nc -vz再升级驱动连接建立快但首次执行 SQL 很慢连接池懒加载、首次 SQL 编译慢适当调大minimum-idle做预热整体启动慢Hikari 日志正常启动阶段业务代码执行 Mapper SQL检查PostConstruct、ApplicationRunner多数据源项目启动翻倍变慢多个连接池同时初始化不常用的数据源改为按需装配偶发“连接已被关闭”异常连接池max-lifetime大于 MySQLwait_timeout把max-lifetime调到wait_timeout以内本地开发环境连库慢使用localhost触发 IPv6 解析改127.0.0.1加-Djava.net.preferIPv4Stacktrue5.2 再分享几条个人经验排查这类问题我的顺序是先做减法再做加法。先去掉一切慢表因素比如 DNS 反查、IPv6 解析、SSL 握手把连接时间压到几百毫秒以内再回头审视连接池参数是否需要调大。另一点是不要盲信“连接池越大越好”。很多应用并发量并不高却把maximum-pool-size设成 50结果 MySQL 侧线程数量虚高连接创建和销毁开销反而拖慢启动和运行。连接池大小应该从业务并发、数据库吞吐和响应时间出发而不是拍脑袋。最后补充一个容易踩的坑如果你用了useSSLfalse这种方式来加速一定要确认团队安全规范是否允许。本地开发可以这么干但生产环境连接是否加密必须由负责安全的人拍板否则后面审计会很被动。排查慢连接时临时禁用加密没问题不要在没评估的情况下把它留给生产。这个项目后续如果再遇到“启动慢”我建议你先保留一份启动日志的时间戳基线改一次配置就对比一次。用“Hikari 两行日志之间的耗时”作为核心指标比盯着整段启动时间可靠得多。有了基线再做参数调整和方案验证都会更从容。
