mysql查询优化器

引用连接 https://www.cnblogs.com/lbg-database/p/10108513.html

优化器分类

传统关系型数据库里面的优化器分为CBO和RBO两种。
RBO— Rule_Based Potimizer 基于规则的优化器:

RBO :RBO所用的判断规则是一组内置的规则，这些规则是硬编码在数据库的编码中的，RBO会根据这些规则去从SQL诸多的路径中来选择一条作为执行计划（比如在RBO里面，有这么一条规则：有索引使用索引。那么所有带有索引的表在任何情况下都会走索引）所以，RBO现在被很多数据库抛弃（oracle默认是CBO，但是仍然保留RBO代码，MySQL只有CBO）

RBO最大问题在于硬编码在数据库里面的一系列固定规则，来决定执行计划。并没有考虑目标SQL中所涉及的对象的实际数量，实际数据的分布情况，这样一旦规则不适用于该SQL，那么很可能选出来的执行计划就不是最优执行计划了。

CBO—Cost_Based Potimizer 基于成本的优化器:

CBO :CBO在会从目标诸多的执行路径中选择一个成本最小的执行路径来作为执行计划。这里的成本他实际代表了MySQL根据相关统计信息计算出来目标SQL对应的步骤的IO，CPU等消耗。也就是意味着数据库里的成本实际上就是对于执行目标SQL所需要IO,CPU等资源的一个估计值。而成本值是根据索引，表，行的统计信息计算出来的。(计算过程比较复杂)

个人对优化器的理解

优化器会尽量使用到索引,并且使用开销最小的那个.

CREATE TABLE `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
  `display_name` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `description` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `keyname` (`display_name`),
  KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

下图是查询的情况,这里使用到了name字段索引.
优化器会分析name和display_name两个字段,一个会排除两行数据,另一个会排除一行数据.查询优化器会寻找较少的计算也就是name字段索引.

以下是修改后的数据

• 

下面是同样的查询语句,使用到了display_name字段索引.

个人的疑问

这个是数据

下图是查询得到的结果.我之前自己尝试的较少有个错误的结论,就是当查询结果的数据占到整个数据的一半时,会扫描所有行.
修改后的数据
下图我被啪啪打脸,这里只是扫描了三行并且用到了索引.

还有一个问题就是一个组合索引,查询条件并没有用到最左边那个字段,优化器竟然用到了索引,可能它认为这样会更加高效,但是组合索引不是有最左前缀原则吗?这个问题来自构建高性能web站点修订版p250.

欢迎大家回答以及纠正错误.