MySQL连接慢，是不是TCP Nagle算法在捣鬼？
是的，TCP_NODELAY没开，小包攒着发，延迟就上去了。尤其在高频率短查询（比如ORM批量get、微服务间轻量RPC）或跨机房场景下，一个SELECT 1来回可能多拖5–50ms。
MySQL客户端默认不关Nagle，服务端mysqld也默认不设TCP_NODELAY——这不是bug，是权衡吞吐和延迟的结果。但你要低延迟，就得手动干预。
- Linux下确认是否生效：
ss -i src :3306看输出里有没有ts sack字段旁带nodelay - 客户端侧更关键：Python用
pymysql.connect(..., read_timeout=..., write_timeout=...)不行，得靠底层socket设；Go的mysql.Open连接串加tcpKeepAlive=true&readTimeout=...也不直接控制nodelay，得用net.Dialer{KeepAlive: ...}再包装 - Java的
mysql-connector-j从8.0.23起支持useSSL=false&tcpNoDelay=true，但注意它只影响客户端发包，服务端仍需配置
mysqld怎么开TCP_NODELAY？
不能只改my.cnf里随便加一行。MySQL服务端是否启用TCP_NODELAY，取决于编译时是否链接了setsockopt且运行时是否显式调用——而官方二进制版默认开了，但Docker镜像或自编译版本可能没开。
验证方式比修改更重要：连上后执行SHOW VARIABLES LIKE 'version_compile_os';确认系统类型，再用lsof -i :3306 -n | grep TCP看句柄状态，结合ss -tni dst :3306查wscale和nodelay标记。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 安全做法：在
[mysqld]段加skip-networking=0（确保走TCP），再加bind-address = *或具体IP（避免仅监听localhost导致测试失效） - 真正起作用的是启动时内核参数：Linux下
echo 1 > /proc/sys/net/ipv4/tcp_nodelay无效，这是伪文件；必须由进程自己调用setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on)) - Docker用户注意：
mysql:8.0镜像默认已启用，但如果你挂载了自定义my.cnf且覆盖了[mysqld]段，可能意外禁用——检查日志是否有Could not set TCP_NODELAY警告
“开了TCP_NODELAY，为什么还是卡在300ms？”
因为TCP_NODELAY只解决小包合并问题，不解决三次握手、TLS协商、DNS解析、防火墙策略这些前置耗时。常见真凶其实是：
- DNS反向解析：客户端IP连上来，
mysqld默认做gethostbyaddr，超时长达30秒。关掉：skip-name-resolve，并确保所有GRANT语句用IP而非域名 - TLS握手：如果强制
REQUIRE SSL但客户端未配证书，会卡在ClientHello重试。用openssl s_client -connect host:3306 -starttls mysql测真实握手时间 - 连接池空闲回收：比如
HikariCP的connection-timeout设成30000，但网络抖动时实际等待远不止——应配合keepalive-timeout和validation-timeout细调 - 云厂商SLB健康检查干扰：阿里云RDS的“探测包”可能被误判为非法连接，触发
Aborted_connects计数上涨，间接拖慢新连接建立
要不要全局开TCP_NODELAY？
别无脑开。它提升交互延迟，但会增加小包数量，在千兆以下网卡或高并发写入场景可能推高CPU软中断和网卡drop。
典型该开的场景：金融行情推送、实时风控决策、游戏状态同步；该关的场景：ETL批量导入、报表导出、离线分析——这时候吞吐比单次延迟重要得多。
- 最稳方案：客户端控制。比如Node.js用
mysql2时，连接选项传{ socket: { noDelay: true } }，比改服务端更精准 - 监控信号比配置更重要：盯紧
Performance Schema里的events_waits_summary_by_thread_by_event_name，过滤wait/io/socket/sql/client_connection的平均等待时间，>10ms就要查 - 跨AZ部署时，
TCP_NODELAY只是起点。真正压延迟的是TCP_FASTOPEN（需内核4.1+）、SO_RCVBUF/SO_SNDBUF调优，以及用mtr定位中间跳点丢包
网络延迟不是单点开关能搞定的事，TCP_NODELAY只是其中一环，而且最容易被当成万能解药误用。真要压到毫秒级，得从客户端socket设置、中间链路质量、服务端连接模型三头推进，少一个都白调。
