sql连接慢主要卡在tcp握手后、查询前，瓶颈在tcp连接建立和数据库认证两环节：需优化网络与连接池配置、启用keepalive、开启tcp_tw_reuse；认证阶段要禁用dns反查、正确配置caching_sha2_password及ldap域控响应。
SQL连接建立慢，通常卡在TCP三次握手之后、实际查询之前，核心瓶颈集中在TCP连接建立和数据库认证两个环节。优化需分步排查，不能只盯着SQL本身。
TCP连接延迟高：检查网络与连接池配置
客户端与数据库实例间RTT（往返时延）超过50ms就应警惕。常见原因包括跨可用区部署、公网直连、防火墙策略过严或中间代理（如SLB/NLB）未开启长连接复用。
- 优先使用内网地址连接，避免走公网NAT或云厂商默认公网入口
- 确认客户端是否启用连接池（如HikariCP、Druid），并合理设置minimumIdle和connectionTimeout；空闲连接保活建议开启keepalive（MySQL设tcp_keepalive_time=60）
- 数据库端检查net.ipv4.tcp_tw_reuse是否开启（Linux），缓解TIME_WAIT堆积导致端口耗尽
认证阶段卡顿：聚焦DNS解析与插件验证
MySQL 8.0+默认启用caching_sha2_password，若客户端不支持或服务端未配好公钥交换，会退回到多次RSA密钥协商，单次连接多耗200–500ms。PostgreSQL则常因pg_hba.conf中hostssl规则匹配慢或反向DNS查询（log_hostname = on）拖慢认证。
- MySQL：客户端显式指定--default-auth=caching_sha2_password，服务端确保caching_sha2_password_auto_generate_rsa_keys=ON且私钥权限为600
- 禁用不必要的DNS反查——MySQL设skip_name_resolve=1，PostgreSQL关掉log_hostname并用IP而非主机名写入pg_hba.conf
- 若用LDAP/AD认证，确认域控响应时间
连接复用不足：避免频繁新建连接
应用每请求都new Connection，即使网络通畅，也逃不开三次握手+SSL协商+认证开销。尤其在短连接场景（如HTTP API后端），连接建立耗时可能占整个请求的60%以上。
- Web应用务必使用连接池，最小空闲数不低于并发预估的1/3，最大连接数避免超过数据库max_connections的70%
- 函数计算（FC）、Serverless场景下，利用实例级连接池（如MySQL的mysqlx协议或PgBouncer的transaction pooling模式）
- 对只读查询，可考虑读写分离+连接池独立配置，避免主库连接被读请求挤占
SSL/TLS协商慢：精简加密套件与证书链
启用SSL后首次连接可能增加300–800ms，主因是证书链校验、OCSP Stapling超时或客户端不支持TLS 1.3。
- 服务端配置仅启用高效套件，如TLS_AES_256_GCM_SHA384，禁用RC4、3DES等老旧算法
- 证书链保持最简（根CA→中间CA→服务端证书，不超过3级），并开启OCSP Stapling（MySQL 8.0.16+支持ssl_mode=REQUIRED + stapling）
- 客户端升级到支持TLS 1.3的驱动版本（如MySQL Connector/J 8.0.28+、pgjdbc 42.6.0+）
