【MySQL百日打怪升级第8天】SELECT执行流程

【第8天】每天一个MySQL知识点百日打怪升级SQL基础SELECT执行流程大家好我是一名拥有10年以上经验的DBA老兵。做这个系列源于一个朴素的愿望把踩过的坑、总结的经验系统化输出希望能帮到刚入行或想进阶的兄弟们。让我们开始今天的第8天内容。面试考点SELECT 语句从输入到输出经历了哪些步骤查询缓存为什么在 MySQL 8.0 被移除了优化器是怎么选择索引的执行器是怎么获取数据的背景引入 说白了你以为 SELECT 只是查一下其实它跑了半个数据库你有没有想过你敲下SELECT * FROM user WHERE id 1MySQL 到底做了什么为什么有时候明明加了索引MySQL 却不用为什么同样的 SQL有时候快有时候慢说实话不理解 SELECT 执行流程的 DBA就像不知道汽车怎么跑的司机——能开但出了问题只能干瞪眼。今天的目标搞懂 SELECT 语句的完整执行流程面试必问。核心概念执行流程全景图┌──────────────────────────────────────────────────────────────┐ │ SELECT 执行流程 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 客户端 │ │ ↓ │ │ ┌─────────┐ │ │ │ 连接器 │ ← 权限验证、获取连接 │ │ └────┬────┘ │ │ ↓ │ │ ┌─────────┐ │ │ │ 查询缓存│ ← MySQL 8.0 已移除 │ │ └────┬────┘ │ │ ↓ │ │ ┌─────────┐ │ │ │ 解析器 │ ← 词法分析、语法分析 │ │ └────┬────┘ │ │ ↓ │ │ ┌─────────┐ │ │ │ 预处理器│ ← 检查表/列是否存在、权限验证 │ │ └────┬────┘ │ │ ↓ │ │ ┌─────────┐ │ │ │ 优化器 │ ← 选择索引、决定执行计划 │ │ └────┬────┘ │ │ ↓ │ │ ┌─────────┐ │ │ │ 执行器 │ ← 调用存储引擎获取数据 │ │ └────┬────┘ │ │ ↓ │ │ 结果集 │ │ │ └──────────────────────────────────────────────────────────────┘第一步连接器说白了连接器就是门卫验明正身才让进职责建立 TCP 连接验证用户名密码获取用户权限后续操作都依赖这个权限面试必问为什么有时候连接很慢长连接和短连接有什么区别为什么长连接会导致内存泄漏面试解答Q: 为什么有时候连接很慢因为建立 TCP 连接需要三次握手如果数据库服务器距离远或者网络差连接就会慢。建议使用连接池复用连接。Q: 长连接和短连接有什么区别短连接每次执行完 SQL 就断开连接。长连接执行完 SQL 后保持连接下次复用。长连接减少了建立连接的开销但会导致内存增长。第二步查询缓存MySQL 8.0 已移除说白了查询缓存就是抄作业SQL 完全一样就直接返回结果工作机制检查 SQL 是否命中缓存精确匹配包括空格命中 → 直接返回结果未命中 → 继续执行后续步骤结果放入缓存为什么 MySQL 8.0 移除了缓存失效太频繁表有任何更新该表所有缓存失效命中率低业务 SQL 通常有参数差异维护成本高需要额外的锁机制-- MySQL 5.7 可以手动关闭查询缓存SETGLOBALquery_cache_type0;-- 查看缓存状态SHOWSTATUSLIKEQcache%;第三步解析器说白了解析器就是语文老师检查 SQL 语法对不对职责词法分析识别关键字、表名、列名语法分析检查 SQL 语法是否正确-- 语法错误示例SELEC*FROMuser;-- 报错SELEC 不是有效关键字-- 语义错误示例解析器检查不出在预处理器报错SELECT*FROMuserWHEREnon_exist_column1;-- 如果列不存在在预处理器报错第四步预处理器说白了预处理器就是班主任检查表和列是否存在职责检查表名、列名是否存在检查用户是否有权限访问这些表和列展开SELECT *为具体列名-- 预处理器会检查SELECT*FROMuserWHEREage18;-- 等价于SELECTid,name,age,...FROMuserWHEREage18;第五步优化器说白了优化器就是军师决定怎么执行最高效职责选择使用哪个索引决定表的连接顺序选择最优的执行计划优化器的工作原理-- 优化器会考虑以下因素EXPLAINSELECT*FROMuserWHEREage18ANDcity北京;-- 优化器可能选择-- 方案1使用 idx_age 索引然后回表过滤 city-- 方案2使用 idx_city 索引然后回表过滤 age-- 方案3使用联合索引 idx_age_city如果存在面试必问优化器是基于什么选择索引的优化器选择错了怎么办面试解答Q: 优化器是基于什么选择索引的基于统计信息cardinality、数据分布等估算成本选择成本最低的执行计划。但统计信息可能不准确导致优化器选错索引。Q: 优化器选择错了怎么办可以使用FORCE INDEX强制指定索引或者ANALYZE TABLE更新统计信息。第六步执行器说白了执行器就是干活的人真正去存储引擎取数据职责根据执行计划调用存储引擎的接口获取数据对结果进行过滤、排序、聚合等处理-- 执行器的工作流程SELECT*FROMuserWHEREage18;-- 1. 调用存储引擎的索引接口获取满足条件的记录ID-- 2. 调用存储引擎的行读取接口获取完整行数据-- 3. 返回结果集给客户端实战案例场景一查看 SELECT 执行流程-- 开启性能监控SETprofiling1;-- 执行查询SELECT*FROMuserWHEREid1;-- 查看执行过程SHOWPROFILES;SHOWPROFILEFORQUERY1;输出示例-------------------------------- | Status | Duration | -------------------------------- | starting | 0.000045 | | checking permissions | 0.000006 | | Opening tables | 0.000015 | | init | 0.000008 | | System lock | 0.000006 | | optimizing | 0.000004 | | statistics | 0.000012 | | preparing | 0.000008 | | executing | 0.000003 | | Sending data | 0.000035 | | end | 0.000003 | | query end | 0.000002 | | closing tables | 0.000004 | | freeing items | 0.000015 | | cleaning up | 0.000003 | --------------------------------场景二优化器选错索引-- 创建测试表CREATETABLEorders(idINTPRIMARYKEYAUTO_INCREMENT,user_idINT,statusVARCHAR(20),amountDECIMAL(10,2),create_timeDATETIME,INDEXidx_user_id(user_id),INDEXidx_status(status),INDEXidx_create_time(create_time));-- 插入数据status 分布不均匀INSERTINTOorders(user_id,status,amount,create_time)SELECTFLOOR(RAND()*10000),CASEWHENRAND()0.9THENcompletedELSEpendingEND,ROUND(RAND()*1000,2),DATE_ADD(2026-01-01,INTERVALFLOOR(RAND()*365)DAY)FROM(WITHRECURSIVE cteAS(SELECT1ASnUNIONALLSELECTn1FROMcteWHEREn100000)SELECT*FROMcte)tmp;-- 查看执行计划EXPLAINSELECT*FROMordersWHEREstatuspendingANDcreate_time2026-06-01;-- 优化器可能选错索引强制指定SELECT*FROMordersFORCEINDEX(idx_create_time)WHEREstatuspendingANDcreate_time2026-06-01; AI 辅助实战AI 能不能帮我对比不同 SQL 写法的执行流程能让 AI 分析同一需求的不同写法对比执行流程和性能差异提示词示例 以下两种写法都能查询有订单的用户请分析执行流程有什么区别 写法1子查询 SELECT * FROM users WHERE id IN (SELECT user_id FROM orders) 写法2JOIN SELECT DISTINCT u.* FROM users u JOIN orders o ON u.id o.user_id 请分析 1. 两种写法的执行流程 2. 哪种写法性能更好 3. 什么场景下选择哪种写法AI 分析结果对比项写法1子查询写法2JOIN执行流程先执行子查询再用 IN 匹配先 JOIN再去重索引使用可能无法使用索引可以使用索引临时表可能需要临时表需要临时表去重性能数据量大时较慢通常更快AI 优化建议写法1 改成 EXISTS 或 JOIN写法2 可以用 GROUP BY 代替 DISTINCT都可以加索引优化避坑指南⚠️ 真实踩过的坑不要迷信 EXPLAINEXPLAIN 只是优化器的预估一般不会有太大偏差但它不是实际执行情况建议用EXPLAIN ANALYZEMySQL 8.0看真实执行长连接要定期重置长连接会导致内存增长临时表、排序缓冲区等建议定期调用mysql_reset_connection()重置会话状态C API 示例MYSQL*connmysql_init(NULL);mysql_real_connect(conn,localhost,root,,test,0,NULL,0);mysql_query(conn,SELECT * FROM user);// 重置连接不断开只清理会话状态mysql_reset_connection(conn);优化器统计信息要定期更新统计信息过期会导致优化器选错索引建议定期执行ANALYZE TABLE思考题 互动时间如果 SELECT 语句执行很慢你会按什么顺序排查为什么 MySQL 8.0 移除了查询缓存优化器选错了索引除了FORCE INDEX还有什么办法总结面试考点执行流程连接器 → 查询缓存 → 解析器 → 预处理器 → 优化器 → 执行器连接器权限验证、长连接/短连接查询缓存MySQL 8.0 已移除因为失效频繁、命中率低解析器词法分析、语法分析优化器基于统计信息选择最优执行计划执行器调用存储引擎获取数据下期预告WHERE子句优化技巧 —— 面试必问全本合集《每天一个MySQL知识点百日打怪升级》有问题欢迎评论区交流明天见