连库慢要分段看
应用连数据库慢是一个复合问题，链路上至少有四段：域名解析、TCP 握手、认证或 TLS 协商、从连接池取到一条可用连接。把整段耗时拆开之后才能发现，多数案例的根因不在数据库本身，而在解析、跨机房时延或连接池排队。分段测量的方法很简单：用单段工具逐段计时，得到哪一段占了总耗时的大头，再针对性处理。
基本信息
| 段一 DNS | 域名解析耗时，改成 IP 直连即可快速验证影响 |
|---|---|
| 段二 TCP | 三次握手耗时，跨机房往返时延决定下限 |
| 段三认证 | 认证往返与 TLS 协商，证书链问题会显著拉长 |
| 段四池化 | 等待可用连接的时长，常是真正的瓶颈 |
| 适用场景 | 应用启动慢、接口偶发超时、连接池报获取超时 |
典型使用场景
- 应用启动阶段连库慢：区分是解析、握手还是池化导致
- 接口偶发超时：确认等待连接的时间是否超过了业务超时预算
- 机房迁移后连接变慢：对比握手往返时延是否随距离增加
- 连接池频繁重建连接：确认是中间设备回收会话还是池配置不当
- 云数据库连接慢：检查安全组与子网路径，以及是否走了公网地址
分段测量
分段测量
time getent hosts db.internal # 段一：解析耗时
time nc -vz db.internal 3306 # 段二：TCP 段耗时
time mysql -h db.internal -u app -p -e 'select 1' # 全链路，包含认证与查询
# 抓包看握手与认证时序：
tcpdump -nn -i eth0 -w /tmp/db.pcap 'host 10.0.0.8 and tcp port 3306'
# 连接池侧关注：获取连接的等待时长与活跃连接数
ss -tan 'dport = :3306' | awk '{print $1}' | sort | uniq -c # 按状态看连接分布分段判读
| 现象 | 指向 | 处置 |
|---|---|---|
| 解析耗时以秒计 | DNS 不可达或逐台超时 | 配置就近 DNS，必要时本地缓存 |
| 握手耗时接近往返时延上限 | 跨机房路径较长 | 就近部署或改用内网地址 |
| 认证阶段停顿明显 | TLS 校验或在线吊销检查被拦 | 本地校验或放行校验地址 |
| 等待池连接时间长 | 池过小或有慢查询占满 | 调池大小并治理慢查询 |
| 连接被对端复位后重建 | 中间设备回收空闲会话 | 调整保活心跳与超时 |
连接池过小或存在慢查询占满连接时，表现就是「连接建立慢」；用池的等待时长指标区分，而不要只看数据库端。