★ FEATURED ARTICLE 1. 先说说这个问题的典型表现上周在技术交流群里有个做电商业务的同学 A 甩了两张截图出来本地起的 SpringBoot 2.7 MyBatis Plus 项目控制台日志在“HikariPool-1 - Starting...”和“HikariPool-1 - Start completed.”之间卡了将近 20 秒到了测试环境更离谱应用重启后健康检查迟迟不通流水线直接判定部署失败。他确认过 SQL 本身不慢跑起来之后的接口响应都正常就是“起不来”每次都卡在连接 MySQL 这个环节。这个现象我太熟悉了。SpringBoot 项目启动慢有相当大一部分不是业务代码的问题而是数据源初始化阶段被拖住了。之前还遇到过几次“假慢”明明数据库压力很小可应用每次启动都要多等半分钟到几分钟尤其在联调阶段前端团队催着要环境后端这边干着急。这里把我在实际排查中遇到的几类原因和完整解决过程写下来主要围绕“连接 MySQL 慢”这个核心展开从 DNS 反解、HikariCP 参数、JDBC URL 配置、MySQL 8 认证协议几个角度梳理给出能直接抄的配置和排查命令。先聊清楚“慢”到底是什么概念。正常情况SpringBoot MyBatis Plus 项目里HikariCP 建一条数据库连接的耗时应该在几十到几百毫秒如果 DNS、网络、认证环节出问题单条连接的耗时会被拉长到 3 到 30 秒。而应用启动时不是只建一条连接的连接池的初始化和参数配置会放大这个延迟。下面从现象开始一步一步把问题拆开。1.1 从日志看启动卡点先看一段典型的“慢启动”日志时间线时间是我从实际排查记录里整理出来的示意14:00:00.123 INFO com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Starting... 14:00:05.889 INFO com.zaxxer.hikari.HikariPool-1 - HikariPool-1 - Start completed. 14:00:05.902 INFO org.apache.catalina.core.StandardEngine - Starting Servlet Engine: Apache Tomcat 14:00:17.452 INFO o.s.b.w.e.tomcat.TomcatWebServer - Tomcat started on port(s): 8080 14:00:18.003 INFO com.baomidou.mybatisplus.core.MybatisConfiguration - MyBatis Plus banner loading...如果你看到启动日志里HikariPool-1 - Starting...到Start completed.之间隔了好几秒甚至几十秒不用怀疑瓶颈就在连接池建立物理连接这一步。SpringBoot 默认整合了 HikariCP这个时间差代表连接池在启动阶段为池子“播种”第一条连接所花费的时间后面所有依赖数据源的 Bean 初始化都得等它。顺带说明一下有人会把锅甩给 MyBatis Plus觉得是 MP 在启动时扫描了太多 Mapper 或者解析注解导致慢。实际上 MP 的 Mapper 扫描和实体类解析都是纯内存操作耗时通常在几百毫秒以内它不是主要原因。真正会让启动卡到“肉眼可见”的几乎都是网络层和数据库连接握手层的问题。1.2 影响到底有多大这个问题看着只是“启动多等一会”实际影响远超直觉本地开发每次改代码热重启多等半分钟到几分钟一天下来几十次重启攒起来的时间很吓人联调环境多个服务并行启动数据库连着多个连接池每个都慢整个环境从部署完到可用的时间被拉得很长发布系统很多 CI/CD 流水线对健康检查有超时限制启动慢了直接判定发布失败触发回滚线上事故就是这么来的容器化场景K8s 里 Pod 有startupProbe如果应用在限定时间内没就绪会被反复杀掉重启形成“永远起不来”的恶性循环。所以别把“连接慢”当小事下面这两套排查思路能帮你把问题从“玄学”变成“可量化”。2. 动手排查前先确认瓶颈在哪个环节排查这类问题最忌讳的是“凭感觉改配置”。我见过有人一上来就往上加各种连接池参数改了一轮发现没变化最后才定位到是数据库服务器 DNS 的问题。所以先做两个动作量化延迟、分离变量。2.1 用时间轴拆解启动阶段先把 SpringBoot 启动过程粗略切三段JVM 启动 Spring 容器装配阶段加载配置、创建 Bean包括创建数据源 DataSource 对象数据源初始化阶段HikariCP 建连接池按配置尝试建第一条物理连接MyBatis / MyBatis Plus 装配阶段创建 SqlSessionFactory、扫描 Mapper、注册拦截器。“启动连接 MySQL 很慢”慢的就是第 2 阶段里“创建物理连接”这件事。为了精确定位建议在启动时加一些 JVM 参数观察网络解析行为同时把 HikariCP 的日志级别调到 DEBUGlogging: level: com.zaxxer.hikari: DEBUG com.mysql.cj.jdbc: DEBUGcom.mysql.cj.jdbc是 MySQL 8 驱动mysql-connector-j 8.x的日志包名打开之后能很清楚地看到驱动在建连接、握手认证、获取时区等不同子步骤的耗时。日志里出现大量 “Connecting to jdbc:mysql://...” 之后长时间没有后续输出基本可以断定问题出在 TCP 连接或者认证阶段。2.2 区分“连接慢”与“初始化慢”这一步很关键有些项目启动慢是“连接慢”另一些项目则是“连接成功但之后的后置逻辑慢”比如有初始化 SQL、有定时任务抢锁、有缓存预热。这俩的排查方向完全不同。我的做法是做一个对照实验。临时在配置里把连接池初始化的 fail-fast 关掉让启动不再等待数据库连接spring: datasource: hikari: initialization-fail-timeout: -1如果改完之后应用秒起说明启动慢的根源确实在“建连接”这个环节如果仍然慢那就要去查后面的 Bean 初始化和业务启动逻辑。这个实验做完记得把配置改回来initialization-fail-timeout: -1意味着数据库挂了应用也能启动生产环境要看情况决定是否保留。另外启动命令里加-Djava.net.preferIPv4Stacktrue也是一个值得先试的开关。如果你的 JDBC URL 写的是localhost部分环境下 JVM 会优先尝试 IPv6 的::1失败再回退 IPv4这两次尝试本身就可能引入几秒的延迟。2.3 复现与对照实验思路为了把变量隔离我在实际项目里一般按这个顺序做对照组本机跑一个 MySQL应用连127.0.0.1看启动是否正常应用改为连接远端数据库服务器其他不变观察延迟是否出现在数据库服务器本机执行mysql -h 127.0.0.1 -P 3306 -u user -p -e select 1对比连本地与连远端的耗时用 telnet 或 nc 直接测 TCP 端口连通性先排除防火墙和安全组的问题。第 1 步正常、第 2 步变慢几乎可以确定是网络链路或数据库服务器侧的配置问题而不是应用代码问题。下面几节的内容就是我基于这种排查思路最终锁定的几个最常见元凶。3. 排第一位的元凶MySQL 的 DNS 反解先给你一个结论在我处理过的“连接 MySQL 很慢”的案例里DNS 反向解析简称 DNS 反解占了一半以上。这个坑很隐蔽因为它不在应用代码里也不在连接池配置里而是藏在 MySQL 服务器端。3.1 为什么 MySQL 要做反解以及它凭什么拖慢连接MySQL 在收到一条 TCP 连接请求时默认会对客户端的 IP 做一次反向 DNS 解析拿到对应的主机名再把主机名和mysql.user表里的 Host 字段做匹配用来判断这个账号允许从哪些主机登录。问题在于很多内网环境的 DNS 服务器并不具备反向解析能力或者反向解析的响应特别慢。MySQL 每收到一次连接请求都要去问 DNS“192.168.1.20 的主机名是什么”DNS 迟迟不回MySQL 就干等着。这个等待时间一次就够呛而连接池启动时往往要建多条连接延迟被进一步放大。我在某项目里遇到过更典型的场景数据库服务器能正常出网但内网 DNS 只在某个网段可用应用服务器所在网段恰好解析不到结果每条连接都要等 5 秒超时。单看数据库负载、单看应用日志都正常只有把启动时间线拉出来才发现每条连接耗时非常平均地分布在 5 秒左右这就是典型的反解超时特征。3.2 怎么确认是不是它确认方法很简单在 MySQL 服务器上执行# 在数据库服务器本机执行把 IP 换成应用服务器的实际 IP nslookup 192.168.1.20 # 或者看 MySQL 当前的配置 mysql -uroot -p -e SHOW GLOBAL VARIABLES LIKE skip_name_resolve;如果nslookup迟迟不出结果或者返回Non-existent domain且响应很慢那基本可以锁定是这个原因。另一个辅助特征开启 MySQL 的通用日志后会发现大量连接记录里的 host 解析环节非常慢但普通业务日志看不出来。3.3 服务端配置 skip-name-resolve 的完整操作确认之后最直接的解法是在 MySQL 配置文件里打开skip_name_resolve。以 Linux 下用 my.cnf 的常见配置为例[mysqld] skip-name-resolve改完重启 MySQLsystemctl restart mysqld # 或 /etc/init.d/mysql restart重启后验证配置是否生效SHOW GLOBAL VARIABLES LIKE skip_name_resolve; -- 返回 ON 即生效我的习惯是先把应用连接池的连接数调小重启应用验证单条连接的耗时是否恢复正常确认有效后再把配置推广到所有环境。这个参数对 MySQL 来说是全局生效的不影响事务和数据风险主要出在账号授权方式上下面专门说一下。3.4 改完之后的注意事项账号授权方式变化这是最容易踩的坑。开启skip_name_resolve之后MySQL 不再解析主机名那么mysql.user表里 Host 字段写主机名的账号就会匹配不上出现“原来能连的账号突然 Access denied”。解决办法是把账号的 Host 改成 IP 或直接用%。比如-- 原来可能是这样的 CREATE USER appapp-host.internal IDENTIFIED BY password; -- 改成这样 CREATE USER app192.168.1.% IDENTIFIED BY password; -- 或者不推荐权限范围太大 CREATE USER app% IDENTIFIED BY password;这里我强烈建议按实际网段授权而不是一上来就%。还有一个细节开启该参数后SHOW PROCESSLIST看到的 Host 列显示为 IP 而不是主机名这属于正常现象别吓一跳。另外如果数据库和应用在同一台机器账号是rootlocalhost走 socket 连接一般不受影响但应用如果通过 TCP 连接127.0.0.1要确保授权能匹配到。我在一次优化后就没注意这个导致应用启动时报Access denied for user applocalhost排查了半天才发现是授权表的锅。4. 排第二位的元凶JDBC 连接参数和 HikariCP 初始化策略DNS 反解排查完之后第二大类问题集中在 JDBC URL 和连接池本身的初始化策略上。这两块经常被混为一谈但它们的职责完全不同分开讲清楚。4.1 connectTimeout 为什么必须显式设置很多人写 JDBC URL 只写了库地址和参数漏掉了connectTimeout。这里有两个不同层面的超时特别容易混淆超时项所属层面默认值作用connectTimeoutJDBC 驱动层0永不超时TCP 连接建立 MySQL 握手全过程connectionTimeoutHikariCP 连接池层30000ms应用从池子里借连接时最长等待时间socketTimeoutJDBC 驱动层0永不超时连接建立后的读写超时当网络不通、防火墙丢包、安全组没放行的时候TCP 层的 SYN 重传会按操作系统内核参数重试这个时间可能长达 2 分钟。如果connectTimeout是默认的 0应用启动时这 2 分钟就全花在“等连接超时”上。这也是为什么我建议所有 JDBC URL 都显式带上连接超时让失败尽快暴露jdbc:mysql://db.internal.example:3306/appdb?connectTimeout3000socketTimeout60000connectTimeout3000表示 3 秒内建立不了连接就直接报错启动失败的速度大大加快。生产环境的合理取值我一般建议 3 到 5 秒太小了网络抖动时容易误报太大了故障时等待太久。顺带说一个跟 JDBC URL 无关但常见的情况如果你的项目连的是负载均衡后面的数据库注意负载均衡器如果只做 TCP 转发连接建立的时间会叠加在connectTimeout上别把connectTimeout设得太苛刻而导致偶发启动失败。4.2 HikariCP 三个关键参数initialization-fail-timeout、minimum-idle、maximum-pool-size先看initialization-fail-timeout。HikariCP 在连接池启动时默认会尝试创建一条初始连接来“验活”这是 fail-fast 机制。如果这条连接建得慢启动就被拖住建不出来应用直接启动失败。这个参数有三个典型值默认值 1单位毫秒池启动时快速尝试拿一条连接失败立即抛异常0不主动尝试建立初始连接池直接启动后续按需建连负数如 -1完全跳过初始连接检查数据库挂了应用也能启动但第一次真正执行 SQL 时才报错。绕开 fail-fast 可以解决“启动被数据库拖住”但要注意它只是把问题延后了。如果你希望应用快速启动、同时数据库故障时要尽早暴露更合理的做法是保留快速失败把根本原因连接慢解决掉而不是简单跳过检查。再看minimum-idle和maximum-pool-size。HikariCP 会尽量维持minimum-idle条空闲连接池启动后也会按这个目标填充连接。如果单条连接耗时 5 秒而minimum-idle配了 10那光填充池子就可能花几十秒。这是“DNS 反解慢 池参数不当”的叠加效应。所以排查慢启动时除了修根因还要检查是不是把minimum-idle配得过大尤其是在不太需要频繁连库的微服务里minimum-idle2往往就够用。4.3 一份可以直接用的配置模板下面这份配置是我在多个项目里用过的相对稳妥的模板覆盖了启动速度和运行稳定性spring: datasource: url: jdbc:mysql://db.internal.example:3306/appdb?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiconnectTimeout3000socketTimeout60000allowPublicKeyRetrievaltruerewriteBatchedStatementstrue username: app password: change-me driver-class-name: com.mysql.cj.jdbc.Driver hikari: pool-name: AppDbPool connection-timeout: 5000 validation-timeout: 2000 initialization-fail-timeout: -1 minimum-idle: 2 maximum-pool-size: 10 idle-timeout: 600000 max-lifetime: 1800000逐个解释几个关键项connectTimeout3000物理连接 3 秒建不起来就报错避免无限等待socketTimeout60000SQL 执行中若 60 秒没响应则断开保护应用不被“假死连接”拖垮initialization-fail-timeout-1跳过启动时的连接预检让应用快速起来代价是数据库不可用时启动不报错第一次查询才报错。如果你想保留 fail-fast建议改成正值但前提是连接本身已经够快minimum-idle2空闲连接保持 2 条避免池子为了填满过多 idle 连接在启动时花额外时间max-lifetime1800000物理连接最长存活 30 分钟配合 MySQL 的wait_timeout设置避免连接被服务端回收后客户端还在用。这个模板不是死的。用户量小、并发低的服务maximum-pool-size可以降到 5启动速度优先级极高的任务型应用甚至可以把minimum-idle设为 0彻底不在启动时预建连接。原则是先确保单条连接的建立速度正常再谈池参数调优。5. MySQL 8.0 的认证与 SSL 也是隐形时间杀手如果你的数据库是 MySQL 8.0还有一个容易被忽略的慢点默认认证插件caching_sha2_password的握手过程。这个问题在 5.7 升 8.0 之后尤其常见。5.1 caching_sha2_password 的握手过程为什么会有额外延迟MySQL 8.0 默认使用caching_sha2_password认证。在客户端第一次连接某个账号、服务器还没有缓存认证结果时如果连接不是 SSL 加密通道服务器需要把 RSA 公钥发给客户端来完成密码传输这期间多了一次或几次网络往返。在跨机房、跨专线的网络环境下这个额外的往返会明显增加连接耗时。我在某项目里遇到过数据库升级到 8.0 后其他没变但应用启动从 3 秒变成 15 秒日志里握手阶段卡了很久。当时查下来就是认证插件的变化加上当时 MySQL 服务器端caching_sha2_password_auto_generate_rsa_keys生成的公钥文件权限异常客户端拿不到公钥反复重试启动被拖得特别明显。排查方法登录 MySQL 执行SHOW VARIABLES LIKE default_authentication_plugin; SELECT user, host, plugin FROM mysql.user WHERE user app;如果返回caching_sha2_password而你的 JDBC 驱动又比较老连接慢的概率就很大。注意 MySQL 8 的社区版和维护版会有一些差异这里以常见的 8.0.x 系列为例。5.2 useSSL 与 allowPublicKeyRetrieval 的正确搭配针对上面的握手开销常见做法是在 JDBC URL 里加allowPublicKeyRetrievaltrue让驱动自动向服务器请求 RSA 公钥完成认证省去手工配置公钥的麻烦。但它通常要和useSSLfalse搭配使用因为非 SSL 通道下才需要这个公钥交换环节。如果你用的是较新版本的 mysql-connector-j 8.xuseSSLfalse已经比较少见新版本更推荐用sslMode参数。几种典型搭配场景推荐配置说明内网开发、非敏感环境sslModeDISABLEDallowPublicKeyRetrievaltrue连接快公网不推荐同城机房、内部网络sslModeREQUIRED或useSSLtrue加密传输增加少量握手开销生产、合规要求高sslModeVERIFY_CAtrustCertificateKeyStoreUrl...校验服务器证书防中间人这里必须提醒一句allowPublicKeyRetrievaltrue等于允许客户端从服务器端获取公钥如果网络本身不可信存在被中间人攻击的风险。所以它只适合内网开发和可信网络生产环境如果数据敏感优先用 SSL而不是用“关闭 SSL 允许公钥拉取”的组合来换取启动速度。这个取舍一定要跟团队讲清楚别为了快几秒牺牲安全性。5.3 driver 版本和时区参数MySQL 8 的驱动和时区参数也常常成为“启动慢”的帮凶驱动版本升级 8.0 之后老的 5.1.x 驱动连不上或者握手特别慢建议统一用 mysql-connector-j 8.0.33 及以上版本。新版本驱动对caching_sha2_password、时区协商、IPv6 的处理都更成熟时区参数JDBC URL 里加serverTimezoneAsia/Shanghai避免驱动和服务器之间时区不一致导致的手忙脚乱。不配时区时某些环境下驱动会反复尝试读取服务器时区表现为连接建立后、拿到连接前的阶段有额外耗时字符集参数characterEncodingutf8配合useUnicodetrue也要加上不然后续出现乱码问题还得返工跟启动速度关系不大但属于顺手做对的事。另外一个容易被忽略的点是 JDBC 驱动加载本身。如果你在 SpringBoot 里同时引了多个数据库驱动或者驱动 jar 冲突类加载阶段也可能出现几秒的卡顿。检查一下pom.xml里确保只有一个mysql-connector-j依赖排除掉传递依赖里夹带的老版本驱动。6. 常见问题速查表与排查命令集这一节把前面分析过的内容整理成速查表方便你遇到问题时直接对号入座。同时分享几条我实际排查时必用的命令。6.1 症状-原因-方案速查表症状可能原因快速验证方式解决方案每条连接建立耗时都在 3~8 秒多次连接叠加更慢MySQL 对客户端 IP 做 DNS 反解超时在 MySQL 服务器上nslookup 客户端IP看响应服务端开启skip-name-resolve账号授权改用 IP 网段启动卡几十秒后报连接超时/拒绝网络不通、防火墙丢包、安全组未放行telnet db-host 3306看是否卡住JDBC URL 加connectTimeout3000检查网络安全组HikariPool-1 - Starting...后有多次连接尝试每条约 5 秒单条连接慢 minimum-idle过大观察日志中 Start 的耗时和连接数先修连接慢根因minimum-idle降到 2 或 0MySQL 8 升级后启动明显变慢默认认证插件caching_sha2_password的非 SSL 握手查看mysql.user的 plugin 字段URL 加allowPublicKeyRetrievaltrue或改走 SSLlocalhost连接比127.0.0.1慢JVM 优先尝试 IPv6 回环地址对比localhost与127.0.0.1两种 URLURL 直接用127.0.0.1或加-Djava.net.preferIPv4Stacktrue启动期间反复解析同一主机名很慢JVM 的 DNS 缓存策略不合适加-Dnetworkaddress.cache.ttl60后对比调整缓存 TTL或 JDBC URL 直接使用 IP应用起来了但第一次 SQL 才报连接错误initialization-fail-timeout设为负数跳过了预检检查 HikariCP 启动日志按需取舍保留快速失败或配合健康检查6.2 我常用的几条排查命令以下命令都是我在排查“连接慢”时实际用过的按顺序跑一遍基本能圈定范围# 1. 检查数据库端口连通性和握手时间 time bash -c echo /dev/tcp/db.internal.example/3306 # 2. 通用 TCP 连通性检查 nc -vz db.internal.example 3306 # 或 telnet db.internal.example 3306 # 3. 对比本机连接数据库的快慢在数据库服务器上执行 time mysql -h 127.0.0.1 -P 3306 -uapp -pxxx -e SELECT 1; # 4. 从应用服务器测试到数据库的网络延迟 ping -c 3 db.internal.example # 5. 应用启动时观察 DNS 解析行为加在启动命令里 java -Dnetworkaddress.cache.ttl60 -Dnetworkaddress.cache.negative.ttl5 -jar app.jar第 1 条命令如果特别耗时说明 TCP 建连本身就有问题第 3 条能排除 MySQL 自身的问题第 5 条能观察到是不是 Java 层 DNS 解析拖了后腿。结合第一节说的日志时间轴基本能覆盖 90% 的场景。6.3 一点实操心得最后分享几个我踩过的坑算个人经验总结第一排查慢启动时优先看“变化”。如果是最近才变慢的重点排查这段时间内改了什么数据库升级了换过网络加了网关账号权限调过我遇到过一次数据库从 5.7 升 8.0 后应用启动从 5 秒变 25 秒就是典型的“升级引入新握手逻辑”。反过来如果一开始就慢则优先看 DNS 和基础网络配置。第二不要在多个环境里一把梭改配置。先在测试环境验证skip-name-resolve和 JDBC 参数的组合确认稳定后再推广到生产。数据库侧参数如skip-name-resolve是全局的影响面比应用配置大改动前先备份授权表结构出问题能快速回滚。第三如果生产环境真的需要“启动快”与“数据库故障快速暴露”兼得我的习惯是应用侧保留合理的initialization-fail-timeout正值同时依赖专业的健康检查机制周期性验证数据库连接。这样启动时不被拖死运行期数据库故障也能被及时感知。单纯把initialization-fail-timeout设成 -1 来掩盖启动慢只会把问题推迟到第一次请求那时候的报错往往更让人措手不及。
阅读完成 · 觉得有帮助？
