查询解析与优化器决策耗时高，尤其在复杂 JOIN 或子查询场景；全表扫描 + 大结果集排序引发磁盘 I / O 与内存争用；InnoDB 行锁等待和 MVCC 版本链遍历拖慢高并发更新；网络传输和客户端处理能力常成隐性瓶颈。
查询解析与优化器决策耗时高，尤其在复杂 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 STATUSG，重点看 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 多慢，而是锁怎么等、临时表往哪写、结果往哪塞——这些环节一旦出问题，监控图表上的“慢查询”可能只是表象。
