不靠谱——SELECT 1 测的是数据库服务端响应时间，含连接建立、SQL解析、权限校验等环节；真测网络 RTT 应用 ping 或 nc；仅适合健康检查或轻量连通性验证。
用
测延迟靠谱吗？
不靠谱——它测的不是网络延迟，而是数据库服务端响应时间，中间夹着连接建立、sql解析、权限校验、执行计划生成等环节。真想看网络 rtt，得用
或
；想快速验证 db 是否“活着且能走通 sql 路径”，
才有意义。
常见错误现象：
耗时 200ms，就以为是网络卡，结果发现是 DB 正在做 checkpoint 或连接池没复用；或者压根没连上，却因为连接超时长（比如 30s），误判为“慢”而非“不通”。
使用场景：适合健康检查（如 Kubernetes
）、CI/CD 中轻量级连通性确认
别用它替代
或
PostgreSQL / MySQL / SQL Server 都支持，但 SQLite 不行（无服务端）
和
执行
的差异点
命令行工具行为不同，直接影响你看到的“耗时”是否包含连接开销：
：每次都会新建 TCP 连接，耗时含 TCP 握手 + 认证，适合模拟首次连接场景
：默认启用连接复用（如果前序会话未退出），可能掩盖真实建连延迟
MySQL 的
和
的
可减少输出干扰，让
测得更准
注意：MySQL 8.0+ 默认开启 caching_sha2_password 插件，首次认证比 mysql_native_password 慢 50–100ms，这不是网络问题
为什么加
反而让测试更稳？
防止
卡死在锁或长事务里——虽然它本身不写也不查表，但在某些引擎（如 MySQL 的 InnoDB）中，仍需获取轻量级元数据锁或 MVCC 快照。一旦上游有大事务未提交，
可能被阻塞数秒。
MySQL 可加 hint：
，超 1s 自动中断
PostgreSQL 用
，但要注意连接级设置会污染后续语句
不设超时的后果：K8s 探针失败、监控告警误触发、自动化脚本 hang 住
这个超时值必须小于你的探测间隔（比如探针周期是 10s，timeout 就不能设成 10s）
真正要测网络层延迟，该用哪条命令？
绕过数据库协议栈，直击 TCP 层。否则你永远分不清是网线松了，还是 pg_hba.conf 写错了。
基础验证：
（PostgreSQL）或
（MySQL），看是否能完成 TCP 握手
带时间戳测 RTT：
（注意
是连接超时，非传输超时）
避免 DNS 干扰：直接用 IP，比如
；若成功但域名失败，就是 DNS 解析问题
别用
测 DB 端口：ICMP 和 TCP 完全不同路径，防火墙常放行 ICMP 但封 TCP
实际部署时最容易被忽略的是连接池配置——应用层发
前如果要等连接池分配空闲连接，那测出来的根本不是 DB 响应，而是连接池的排队时间。
SELECT 1pingtelnetselect 1SELECT 1livenessProbetime curl -I http://db-host:port/healthtime nc -zv db-host 5432mysqlpsqlSELECT 1mysql -h host -u user -p -e "SELECT 1"psql -h host -U user -c "SELECT 1"--skip-teepsql\set QUIET ontime/*+ MAX_EXECUTION_TIME(1000) */SELECT 1SELECT 1SELECT /*+ MAX_EXECUTION_TIME(1000) */ 1SET statement_timeout = '1s'; SELECT 1;nc -zv db-host 5432nc -zv db-host 3306time printf "" | nc -w1 db-host 5432 2>&1 | grep real-w1nc -zv 10.20.30.40 5432pingSELECT 1