查询过程(缓存/优化器)

查询过程(缓存/优化器)_第1张图片
关注2和5

缓存

通过hash查找实现,每次对这个表更新都会刷新缓存,检查是否命中会对缓存加锁,读写频繁的系统就不要使用查询缓存了


查询过程(缓存/优化器)_第2张图片

query_cache_size缓存大小 必须是1024整数倍


如果我们自己知道查询结果很大,不会被缓存 就加上 SQL_NO_CACHE这样可以提高查询效率
默认是不行

查询过程(缓存/优化器)_第3张图片

查询过程(缓存/优化器)_第4张图片

查询过程(缓存/优化器)_第5张图片
生成查询计划要比较索引

执行计划

查询过程(缓存/优化器)_第6张图片

image.png

查询过程(缓存/优化器)_第7张图片

优化方式

查询过程(缓存/优化器)_第8张图片

查询过程(缓存/优化器)_第9张图片

内连接。使用比较运算符根据每个表共有的列的值匹配两个表中的行。例如,检索 students 和 courses 表中学生标识号相同的所有行。
外连接。左向外连接的结果集包括LEFT OUTER子句中指定的左表的所有行,而不仅仅是连接列所匹配的行。如果左表的某行在右表中没有匹配行,则在相关联的结果集行中右表的所有选择列表列均为空值。
https://www.cnblogs.com/youzhangjin/archive/2009/05/22/1486982.html

查询过程(缓存/优化器)_第10张图片
image.png

查询过程(缓存/优化器)_第11张图片
btree很好找

用覆盖索引也算优化方式


查询过程(缓存/优化器)_第12张图片
limt或者不成立立即返回空
CREATE TABLE `film` (
  `film_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

比如film_id是unsigned不可能为负数


提前终止不可能的,不再交给存储引擎了

in里面排序然后二分查找

你可能感兴趣的:(查询过程(缓存/优化器))