SQL在mysql中是如何执行的_mysql执行步骤详解

mysql执行SQL需经连接→解析→优化→执行→返回五步，其中连接器校验权限，查询缓存8.0已移除，优化器基于统计信息选执行计划，执行器再次校验权限并调用引擎API。

sql语句在MySQL中不是直接执行的，而是经过一套固定流程解析、优化、执行

MySQL不会像命令行一样“读到就跑”，它必须先把你的 select * FROM users WHERE id = 123 拆解成结构化信息，再决定怎么查最快。这个过程分五步：连接 → 解析 → 优化 → 执行 → 返回。其中真正“执行”只占最后一步，前面全是为它服务的准备动作。

连接器负责身份校验和权限检查，不是简单建立TCP连接

你执行 mysql -u root -p 后输入密码，连接器做的不只是握手，还会查 mysql.user 表确认账号是否存在、密码是否正确、是否有对应库表的 SELECT 权限。一旦权限不足，错误是 Error 1142 (42000): SELECT command denied to user，而不是语法错。

• 连接成功后会分配一个线程（thread_id），可通过 SHOW PROCEsslIST 查看
• 如果用的是长连接（如应用层未主动 close），该线程会一直保留，内存不释放
• wait_timeout 和 interactive_timeout 控制空闲连接自动断开时间，默认 28800 秒（8 小时）

查询缓存（Query Cache）在 MySQL 8.0 中已被彻底移除

MySQL 5.7 及以前版本会在解析前先查缓存：如果完全相同的 SQL 字符串（包括空格、大小写）之前执行过且结果未失效，就直接返回结果。但它有严重缺陷：

• 只要表有任意更新（INSERT/UPDATE/delete），该表所有缓存全失效
• 缓存键对空格、注释、大小写敏感，select * from t 和 SELECT * FROM t 是两个缓存项
• 多线程下缓存锁竞争高，反而拖慢性能

所以 MySQL 8.0 直接删掉了整个 query_cache_type、query_cache_size 等所有相关参数和逻辑——现在任何版本号带 “8.” 的 MySQL 都不支持查询缓存。

优化器决定“怎么查”，它可能完全无视你的索引提示

你写了 SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 10，但优化器不一定会用 created_at 索引。它会基于统计信息估算：

• 表总行数（SHOW table STATUS LIKE 'orders' 中的 Rows 值）
• 各列值的分布（通过 ANALYZE TABLE orders 更新）
• 索引的选择性（比如 status 只有 3 个值，选择性差，可能被跳过）

你可以用 EXPLAIN format=TRADITIONAL SELECT ... 看它最终选了哪个索引、是否用了 filesort 或 temporary。注意：FORCE INDEX 能绕过优化器判断，但风险自负——万一数据量突增，强制走的索引反而更慢。

EXPLAIN SELECT * FROM users WHERE age > 30 AND city = 'Beijing'; +----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra       | +----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+ |  1 | SIMPLE      | users | NULL       | ref  | idx_city      | idx_city | 102     | const |  123 |    33.33 | Using where | +----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+

执行器调用存储引擎接口，但权限检查会重复做一次

即使连接器已验过权限，执行器在真正访问每张表前还会再查一遍权限——这是为了支持视图、触发器等动态对象。执行器不关心数据怎么存，只调用引擎的 API：

• InnoDB 引擎收到 read_row() 请求，去 Buffer Pool 查页，没命中就从磁盘加载
• 遇到 WHERE 条件，由执行器逐行过滤（除非引擎能下推，如主键范围扫描）
• 如果需要排序或分组，执行器会申请 sort_buffer 或 tmp_table（可能落到磁盘，看 tmp_table_size 和 max_heap_table_size）

这也是为什么 SELECT * 在大字段表上很危险：执行器要把整行读出来再丢弃不需要的列，白白增加 IO 和内存压力。