查询解析与优化器决策耗时高，尤其在复杂 JOIN 或子查询场景
MySQL 接收到 SQL 后，先做词法/语法解析，再进入优化器生成执行计划。这个阶段不涉及磁盘 I/O，但 CPU 消耗明显——特别是当
JOIN表超过 5 张、或存在多层嵌套
IN/
EXISTS子查询时，优化器可能尝试数百种连接顺序，导致
query_cost计算膨胀。
实操建议：
用EXPLAIN FORMAT=TREE查看优化器最终选择的连接顺序，比传统
EXPLAIN更直观暴露低效路径 对固定模式的复杂查询，加
/*+ SET_VAR(optimizer_search_depth=3) */限制搜索深度（需 MySQL 8.0.22+） 避免在
WHERE中对索引列使用函数，例如
WHERE YEAR(create_time) = 2023会强制跳过索引，让优化器误判行数
全表扫描 + 大结果集排序是磁盘 I/O 和内存争用双瓶颈
当
EXPLAIN显示
type=ALL且
Extra包含
Using filesort或
Using temporary，说明 MySQL 正在读取大量数据页，并可能把中间结果写入磁盘临时表（
/tmp或
innodb_temp_data_file_path）。
常见诱因：
ORDER BY字段未走索引，且
sort_buffer_size不足以容纳全部待排序行
GROUP BY配合
SELECT *，触发隐式临时表
JOIN后结果集远超
join_buffer_size，被迫分块读取驱动表
验证方式：开启
performance_schema，查
events_statements_summary_by_digest中
sort_merge_passes和
created_tmp_disk_tables值是否突增。
InnoDB 行锁等待和 MVCC 版本链遍历拖慢高并发更新
写操作（
UPDATE/
DELETE）在 InnoDB 中不是简单“改一行”，而是要： 定位聚簇索引记录（可能触发二级索引回表） 检查行锁冲突（
LOCK_WAIT状态可见于
information_schema.INNODB_TRX） 构造新版本并写入 undo log 遍历旧版本链判断可见性（尤其在长事务未提交时）
典型卡点：
非唯一条件更新（如UPDATE t SET a=1 WHERE status=0），引发间隙锁（
INSERT intention等待） 事务中先
SELECT ... FOR UPDATE再更新，却没走索引，锁住整张表
innodb_lock_wait_timeout默认 50 秒，但业务实际容忍常低于 1 秒
快速定位：执行
SHOW ENGINE INNODB STATUS\G，重点看
TRANSACTIONS部分的
lock struct(s)和
WAITING FOR THIS LOCK TO BE GRANTED。
网络传输和客户端处理常被低估，尤其大字段和批量操作
MySQL Server 层完成结果集组装后，需通过网络发送给客户端。若单行含
TEXT/
BLOB字段，或
SELECT返回百万级行，瓶颈可能不在数据库本身： 服务端发送缓冲区（
net_buffer_length）默认仅 16KB，小包频繁往返放大延迟 客户端未设置
useServerPrepStmts=true（Java JDBC），预编译失效，每次重解析 Python 的
fetchall()一次性加载所有结果到内存，OOM 风险远高于数据库报错
对策示例：
SELECT id, title FROM article WHERE id BETWEEN 10000 AND 10100;
-- 改为流式读取（Python pymysql）
cursor = conn.cursor(pymysql.cursors.SSCursor)
cursor.execute("SELECT id, title FROM article WHERE id > %s ORDER BY id LIMIT 100", (last_id,))
for row in cursor:
process(row)
last_id = row[0]真正卡住的往往不是 SQL 多慢，而是锁怎么等、临时表往哪写、结果往哪塞——这些环节一旦出问题，监控图表上的“慢查询”可能只是表象。
