MySQL查询性能瓶颈不在SQL本身，而在完整链路的各环节：TCP连接与认证、语法解析与优化器决策、InnoDB锁等待与I/O、半双工网络传输及客户端结果处理，任一环节异常均会导致慢、卡、报错或连接失败。
MySQL 查询不是“发一条 SQL 就立刻有结果”，它是一条完整链路，每个环节出问题都会导致慢、卡、报错甚至连接失败。真正影响性能的，往往不是 SELECT 本身，而是你没看见的握手、解析、锁等待或网络传输。
客户端发起连接时发生了什么（TCP + 认证）
这不是简单的“连上就行”。客户端调用 mysql_real_connect()（C API）或 JDBC 的 DriverManager.getConnection() 后，底层先走 TCP 三次握手：SYN → SYN-ACK → ACK。这阶段就可能失败——比如防火墙拦截、max_connections 耗尽，报错 Too many connections；或者服务端没监听 3306 端口，直接 connect timeout。
握手成功后，服务器发送一个随机 salt，客户端用该 salt 加密密码再发回去。认证失败会返回 Access denied for user 'xxx'@'xxx'。注意：localhost 和 127.0.0.1 在 MySQL 中走的是不同协议（前者优先用 Unix socket，后者强制走 TCP），权限判断也不同，容易配错。
- 检查是否真在用 TCP：用
mysql -h 127.0.0.1 -u root -p，而不是mysql -h localhost -u root -p - 确认
max_connections是否够用：SHOW VARIABLES LIKE 'max_connections'; - 认证失败时，查
mysql.user表里host字段是否匹配客户端 IP 或域名
SQL 到达服务端后怎么被“读懂”（解析与优化）
连接建立后，客户端发来的 SQL 是纯文本，MySQL 不是直接执行，而是先过连接器、查询缓存（8.0 已移除）、解析器、优化器。其中最容易被忽略的是解析器对语法的严格性——比如 SELECT * FROM t WHERE id = ? 中的问号，在预处理语句中合法，但直接发给服务器会报 You have an error in your SQL syntax。
优化器决定走哪个索引、是否用临时表、是否下推条件。它不看你的注释，也不懂你“本意”，只信统计信息。常见陷阱：
-
SELECT *导致全表扫描，尤其当表有大字段（TEXT/BLOB）时，I/O 暴增 - 隐式类型转换：如
WHERE phone = 13800138000（phone 是 VARCHAR），触发全索引扫描 - 没走索引却以为走了：用
EXPLAIN看type是ALL还是range，别只盯key字段
真正干活的是存储引擎（InnoDB 锁与 I/O）
优化器生成执行计划后，请求落到存储引擎层。InnoDB 不是“查完就返”，它要加锁、读页、刷脏页、写 redo log。高并发下最常卡在这里：
- 行锁升级为间隙锁（Gap Lock），导致
INSERT被阻塞，现象是事务 hang 住，SHOW ENGINE INNODB STATUS显示*** (1) WAITING FOR THIS LOCK TO BE GRANTED: - 大结果集没分页，
SELECT把整个聚簇索引页从磁盘读进 buffer pool，挤占其他查询内存 -
max_allowed_packet太小，插入含长文本的记录时直接报错Packets larger than max_allowed_packet are not allowed
注意：InnoDB 默认 RR 隔离级别下，SELECT 不加锁（快照读），但 UPDATE/DELETE 一定加锁，且锁范围可能远超 WHERE 条件。
结果怎么回到客户端（半双工 + 内存压力）
MySQL 和客户端通信是半双工：一次只能单向传数据。服务端把结果打包成多个 packet 发出去，客户端必须按序收完才能发下一条命令。这意味着：
- JDBC 默认
fetchSize = Integer.MIN_VALUE（即流式读取），但很多 ORM（如 MyBatis）默认一次性拉全量到内存，查百万行极易 OOM - 客户端没及时读取，服务端会在
wait_timeout（默认 28800 秒）后主动断连，报错Lost connection to MySQL server during query - 网络中间件（如代理、K8s Service）可能重置空闲连接，需配合
tcp_keepalive或应用层心跳
真正难调试的，往往不是 SQL 写得对不对，而是连接怎么建、锁怎么等、结果怎么拿——这些环节不出现在 SQL 里，却决定了它跑不跑得通、快不快。
