共计 5823 个字符，预计需要花费 15 分钟才能阅读完成。
自动写代码机器人，免费开通
这篇文章主要介绍 mysql 中 sql 的生命周期是什么，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
MYSQL Query Processing
sql 的执行过程和 mysql 体系架构基本一致
执行过程：
连接器：
建立与 MySQL 的连接，用于查询 SQL 语句，判断权限。
查询缓存：如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中如果查询命中缓存，MySQL 不需要执行后面的复杂操作，就可以直接返回结果，提升效率分析器：
对 SQL 语句进行硬解析，分析器先会做词法分析。分析 SQL 语句的组成成分。判断输入的 SQL 语句是否满足语法规则。
优化器：
优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。不同的执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。
执行器：有索引：第一次调用的是取满足条件的第一行这个接口，之后循环取满足条件的下一行这个接口，最终把查询结果返回客户端无索引：调用 InnoDB 引擎接口取这个表的第一行，判断 sql 查询条件，如果不是则跳过，如果是则将这行存在结果集中；调用引擎接口取下一行，重复相同的判断逻辑，直到取到这个表的最后一行。执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端理解执行计划
EXPLAIN 命令输出 MySQL 将如何执行你的 SQL 语句，但不会返回数据
如何使用
[root@localhost][(none)] explain select * from 表名 where project_id = 36;
+----+-------------+--------------------------+------------+------+---------------+------------+---------+-------+--------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------------------------+------------+------+---------------+------------+---------+-------+--------+----------+-------+
| 1 | SIMPLE | 表名 | NULL | ref | project_id | project_id | 4 | const | 797964 | 100.00 | NULL |
+----+-------------+--------------------------+------------+------+---------------+------------+---------+-------+--------+----------+-------+ 复制代码
idid 相同执行顺序由上至下 id 不同，id 值越大优先级越高，越先被执行 select_typeSIMPLE：简单的 select 查询，查询中不包含子查询或者 unionPRIMARY：查询中包含子部分，最外层查询则被标记为 primaryDERIVED：是子查询 from 的一部分 DEPENDENT SUBQUERY：子查询中的第一个 SELECT，子查询依赖于外层查询的结果 SUBQUERY 表示在 select 或 where 列表中包含了子查询，MATERIALIZED：表示 where 后面 in 条件的子查询 UNION：表示 union 中的第二个或后面的 select 语句 UNION RESULT：union 的结果 table 表对象 type
system const eq_ref ref range index ALL（查询效率）
system：表中只有一条数据，这个类型是特殊的 const 类型 const：针对于主键或唯一索引的等值查询扫描，最多只返回一个行数据。速度非常快，因为只读取一次即可。eq_ref：此类型通常出现在多表的 join 查询，表示对于前表的每一个结果，都只能匹配到后表的一行结果，并且查询的比较操作通常是 =，查询效率较高 ref：此类型通常出现在多表的 join 查询，针对于非唯一或非主键索引，或者是使用了最左前缀规则索引的查询 range：范围扫描 这个类型通常出现在 , , =, , =, IS NULL, = , BETWEEN, IN() 操作中 index：索引树扫描 ALL：全表扫描（full table scan）possible_keys 可能使用的索引，注意不一定会使用查询涉及到的字段上若存在索引，则该索引将被列出来当该列为 NULL 时就要考虑当前的 SQL 是否需要优化了 key 显示 MySQL 在查询中实际使用的索引，若没有使用索引，显示 NULL。查询中若使用了覆盖索引(覆盖索引：索引的数据覆盖了需要查询的所有数据)，则该索引仅出现在 key 列表中 key_length 索引长度 ref 表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值 rows 返回估算的结果集数目，并不是准确的值 filtered 示返回结果的行数占需读取行数的百分比，filtered 的值越大越好 extraUsing where：表示优化器需要通过索引回表，之后到 server 层进行过滤查询数据 Using index：表示直接访问索引就足够获取到所需要的数据，不需要回表 Using index condition：在 5.6 版本后加入的新特性（Index Condition Pushdown）Using index for group-by：使用了索引来进行 GROUP BY 或者 DISTINCT 的查询 Using filesort：当 Extra 中有 Using filesort 时, 表示 MySQL 需额外的排序操作, 不不能通过索引顺序达到排序效果. 一般有 Using filesort, 都建议优化去掉, 因为这样的查询 CPU 资源消耗大 Using temporary 临时表被使用，时常出现在 GROUP BY 和 ORDER BY 子句情况下。（sort buffer 或者磁盘被使用）
光看 filesort 字面意思，可能以为是要利用磁盘文件进行排序，实则不全然。当 MySQL 不能使用索引进行排序时，就会利用自己的排序算法 (快速排序算法) 在内存 (sort buffer) 中对数据进行排序，如果内存装载不下，它会将磁盘上的数据进行分块，再对各个 数据块进行排序，然后将各个块合并成有序的结果集（实际上就是外排序）。
当对连接操作进行排序时，如果 ORDER BY 仅仅引用第一个表的列，MySQL 对该表进行 filesort 操作，然后进行连接处理，此时，EXPLAIN 输出“Using filesort”；否则，MySQL 必 须将查询的结果集生成一个临时表，在连接完成之后行行 filesort 操作，此时，EXPLAIN 输出“Using temporary;Using filesort”。
提高查询效率正确使用索引
为解释方便，来一个 demo：
DROP TABLE IF EXISTS user;
CREATE TABLE user(
id int AUTO_INCREMENT PRIMARY KEY,
user_name varchar(30) NOT NULL,
gender bit(1) NOT NULL DEFAULT b’1’,
city varchar(50) NOT NULL,
age int NOT NULL
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE user ADD INDEX idx_user(user_name , city , age);
复制代码什么样的索引可以被使用？** 全匹配：**SELECT * FROM user WHERE user_name= JueJin AND age= 5 AND city= 上海（与 where 后查询条件的顺序无关）匹配最左前缀：(user_name)、(user_name, city)、(user_name , city , age)（满足最左前缀查询条件的顺序与索引列的顺序无关，如：(city, user_name)、(age, city, user_name)）** 匹配列前缀：**SELECT * FROM user WHERE user_name LIKE W% ** 匹配范围值：**SELECT * FROM user WHERE user_name BETWEEN W% AND Z% 什么样的索引无法被使用？**where 查询条件中不包含索引列中的最左索引列，则无法使用到索引：**
SELECT * FROM user WHERE city= 上海
SELECT * FROM user WHERE age= 26
SELECT * FROM user WHERE age= 26 AND city=‘上海
** 即使 where 的查询条件是最左索引列，也无法使用索引查询用户名以 N 结尾的用户：**
SELECT * FROM user WHERE user_name LIKE %N
** 如果 where 查询条件中有某个列的范围查询，其右边的所有列都无法使用索引优化查询：**
SELECT * FROM user WHERE user_name= JueJin AND city LIKE 上 % AND age=31;
** 索引列不能是表达式的一部分，也不能作为函数的参数，否则无法使用索引查询：**
SELECT * FROM user WHERE user_name=concat(user_name, PLUS
选择合适的索引列顺序在组合索引的创建中索引列的顺序非常重要，正确的索引顺序依赖于使用该索引的查询的查询方式对于组合索引的索引顺序可以将选择性最高的列放到索引最前列，该法则与前缀索引的选择性方法一致并不是说所有的组合索引的顺序都使用该法则就能确定，还需要根据具体的查询场景来确定具体的索引顺序覆盖索引条件如果一个索引中包含所有要查询的字段的值，那么就称之为覆盖索引
SELECT user_name, city, age FROM user WHERE user_name= Tony AND age= 28 AND city= 上海
因为要查询的字段 (user_name, city, age) 都包含在组合索引的索引列中，所以就使用了覆盖索引查询，查看是否使用了覆盖索引可以通过执行计划中的 Extra 中的值为 Using index 则证明使用了覆盖索引，覆盖索引可以极大的提高访问性能。
使用索引进行排序
在排序操作中如果能使用到索引来排序，那么可以极大地提高排序的速度，要使用索引来排序需要满足以下两点即可：
ORDER BY 子句后的列顺序要与组合索引的列顺序一致，且所有排序列的排序方向 (正序 / 倒序) 需一致所查询的字段值需要包含在索引列中，及满足覆盖索引
排序可用 demo：
SELECT user_name, city, age FROM user_test ORDER BY user_name;SELECT user_name, city, age FROM user_test ORDER BY user_name,city;SELECT user_name, city, age FROM user_test ORDER BY user_name DESC,city DESC;SELECT user_name, city, age FROM user_test WHERE user_name= Tony ORDER BY city;
排序不可用 demo：
SELECT user_name, city, age FROM user_test ORDER BY user_name gender;SELECT user_name, city, age, gender FROM user_test ORDER BY user_name;SELECT user_name, city, age FROM user_test ORDER BY user_name ASC,city DESC;SELECT user_name, city, age FROM user_test WHERE user_name LIKE W% ORDER BY city; 数据获取建议
不要返回应用户程序所不需要的数据限制返回数
LIMIT：MySQL 并不能按照需求返回数据量，也就是 MySQL 总是会查询出全部数据，使用 LIMIT 子句其实是为了减小网络数据传输的压力，并不会减小数据的读取行数。
去掉不需要的列
SELECT * 语句取出表中的所有字段，不论该字段的数据对调用的应用程序是否有用，这会对服务器资源造成浪费，甚至会对服务器的性能产生一定的影响如果表的结构在以后发生了改变，那么 SELECT * 语句可能会取到不正确的数据执行 SELECT * 语句时，首先要查找出表中有哪些列，然后才能开始执行 SELECT * 语句，这在某些情况会产生性能问题使用 SELECT * 语句将不会使到覆盖索引，不利于查询的性能优化
正确使用索引的优点
避免全表扫描单表查询时，全表扫描需要查询每一行多表查询时，全表扫描至少需要检索所有表中每一行提高速度可以迅速定位结果集的第一行排除不相关的结果对于 MIN()或者 MAX()值不必检查每一行提高排序和分组的效率在可以使用覆盖索引的情况下避免 row loop-up 索引的代价如果存在过多索引，数据修改将会变得缓慢受影响的索引需要被更新对于写密集型环境压力很大索引消耗过多磁盘空间 InnoDB 存储引擎将索引和数据存储在一起需要监控磁盘空间索引最佳实践
对于如下列考虑使用索引
WHERE 子句中的列 ORDER BY 或 GROUP BY 子句中的列表连接条件列
考虑针对字符串型列使用前缀索引
可以更快速地比较与 loop up 减少磁盘 I /OSELECT 语句效率低下时考虑避免全表扫描尝试增加索引 WHERE 语句表连接条件利用 ANALYZE TABLE 来收集统计信息考虑存储引擎层的优化调优表连接方法在 ON 或 USING 子句的列上增加索引利用 SELECT STRAIGHT_JOIN 来强制表连接顺序在 ORDER BY 和 GROUP BY 的列上增加索引 join 连接不一定比子查询效率高
以上是 mysql 中 sql 的生命周期是什么的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！
向 AI 问一下细节
丸趣 TV 网 – 提供最优质的资源集合！
