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

8次阅读

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

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

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_timeoutinteractive_timeout 控制空闲连接自动断开时间,默认 28800 秒(8 小时)

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

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

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

所以 MySQL 8.0 直接删掉了整个 query_cache_typequery_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 …… 看它最终选了哪个索引、是否用了 filesorttemporary。注意: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_sizemax_heap_table_size

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

星耀云
版权声明:本站原创文章,由 星耀云 2026-01-01发表,共计2096字。
转载说明:转载本网站任何内容,请按照转载方式正确书写本站原文地址。本站提供的一切软件、教程和内容信息仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。本站信息来自网络,版权争议与本站无关。
text=ZqhQzanResources