一、索引
1.简介
索引为mysql中最基础的优化，作用是提供了类似目录的作用，优化查询性能。
2.索引算法种类
B树索引
hash索引
R树索引
gis索引
3.功能分类
辅助索引的B树结构构建：
**基于索引列生成**
- 辅助索引是基于表中的某一列生成的（一般为主键）
- 取出索引列的所有值（键值）
- 将取出的键值进行排序
- 将所有键值按顺序落到B树索引的叶子节点上（每页16KB）
- 将每页的最小值向上生成枝节点
- 叶子节点除了存储键值外还存储了相邻叶子节点的指针和指向原表数据的指针
聚集索引的B树结构构建
将整行数据作为节点
一般情况下将后端的整表数据作为聚集索引的叶子节点
4.聚集索引和辅助索引的区别
- 聚集索引只能有一个 且非空唯一 一般为主键
- 辅助索引可以有多个，配合聚集索引使用
- 聚集索引的叶子节点就是磁盘上数据行存储的数据页
- MySQL是根据聚集索引，组织存储数据 数据存储时就是按照聚集索引的顺序进行
5.辅助所以细分
- 单列的辅助索引
- 联合多列的辅助索引（覆盖索引）
- 唯一索引 （索引中每一列都是唯一）
6.影响索引树高度的因素
索引树的高度控制在4层以内
- 数据行 当数据量大时采用分表
- 索引列字符长度 字符过长是采用前缀索引
- char varchar 合理设计表
- enum 可以减少索引树高度 能用则用
7.执行计划
作用：上线新的查询语句之前，提前预估语句的性能，在出现性能问题时，提供解决思路。
id: 1
select_type: SIMPLE
table: t100w 表名
partitions: NULL
type: ref 索引的应用级别
possible_keys: idx_k2 可能会使用到的索引
key: idx_k2 实际使用的索引
key_len: 17 联合索引覆盖长度（越多越好）
ref: const
rows: 244 查询的行数（越少越好）
filtered: 100.00
Extra: NULL 额外信息
type 索引的应用级别
- all
全表遍历扫描，不使用索引
辅助索引条件中 出现！= 不等式 不使用索引
条件不是索引列时 不使用索引
%like% % 在前模糊查找 不使用索引
语句中有函数 不使用索引 - index（重点）
全索引扫描
获取了整列索引的数据 - range
索引范围扫描 - ref
辅助索引等值查询 - eq_ref
在多表连接查询是on的条件时，是唯一索引或主键 - const，system
主键或唯一键等值查询 - null
查询不到数据
extra 额外信息
若出现using filesort是因为索引设置不合理
二、索引应用规范
1.建立索引的原则
为了使索引的效率更高，创建索引时，必须考虑在那些字段上创建索引，和常见类型的索引。
- 建表时一定要有主键，一般是无关列
- where order by group by join on 等操作字段，排序操作会浪费很多时间。where 尽量不要出现不等值
- 常作为条件的列，如果重复值多，可以建立联合索引
- 如果索引字段值很长，最好使用前缀索引
- 最好使用唯一值多的列作索引，
- 降低索引条目，一方面不要创建没用的索引，不常使用的索引清理掉
- 索引维护期要避开业务繁忙期
- 索引会中断在不等式前，因此语句中需要将不等式放在末尾
- 经常更新的表不适合做索引
- 尽量少在经常更新值得列上建立索引
2.索引数目过多可能产生的问题
- 每个索引都需要磁盘空间，索引越多，需要的磁盘空间就越大。
- 修改表时，对索引的重构和更新很麻烦，越多的索引，会使更新表很慢
- 优化器的负担会很重，有可能影响到优化器的选择。
3.工具
percona toolkit 可以分析索引是否有用