1.索引的种类
- 聚簇索引，非聚簇索引
- 主键索引，唯一索引，普通索引（前缀索引），全文索引
- 单值索引，复合索引
- 二级索引
- 覆盖索引
1.1 聚簇索引，非聚簇索引
参考文档：
https://www.cnblogs.com/jiawen010/p/11805241.html
https://learnku.com/articles/45521
总结（根据第二个博客）：
- 聚簇索引
- 索引必须为唯一索引
- 叶子节点存储的是整行数据
- 非聚簇索引
- 索引值不唯一
- 叶子节点存储的是索引行和主键
Q：聚簇索引一定是主键吗？
A：不一定，但主键一定是聚簇索引。如果没有主键索引，InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引。
1.2.前缀索引
参考博客：https://blog.51cto.com/u_15144024/2860391
主要针对较长的varchar类型字段以及TEXT、BLOB类型类型。
通常可以索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率。但这样也会降低索引的选择项。索引的选择性是指，不重复的索引值（也称为基数 cardinality）和数据表的记录总数（#T）的比值，范围从1/#T到1之间。索引的选择项越高则查询效率越高，唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。
对于BLOB、TEXT或者很长的varchar类型的列，必须使用前缀索引，因为mysql不允许索引这些列的完整长度。
诀窍在于要选择足够长的前缀以保证较高的选择性，同时又不能太长（以便节约空间）。前缀应该足够长，以使得前缀索引的选择性接近于索引整个列。换句话说，前缀的"基数"应该接近于完整列的"基数"
-- 计算完整列的选择性
select count(distinct city)/count(*) from city_demo;
mysql无法使用前缀索引做order by和group by，也无法使用前缀索引做覆盖索引
1.3.全文索引
参考博客：https://blog.csdn.net/mrzhouxiaofei/article/details/79940958
之前只能用myisam创建全文索引，5.6之后innodb也可以了
查找文本中的关键词，而不是直接比较索引中的值。它有许多需要注意的细节，如停用词、词干和复数、布尔搜索等。全文索引更类似于搜索引擎做的事情，而不是简单的where条件匹配。在相同的列上同时创建全文索引和基于值的B-Tree索引不会有冲突，全文索引适用于match against操作，而不是普通的where条件操作。
有时候后缀索引也有用途，mysql原生不支持反向索引，但是可以把字符串反转后存储，并基于此建立前缀索引。 姓名把名反转放前面，做名的右模糊查询，但中间的没法模糊查询
参考博客：https://blog.csdn.net/weixin_38106322/article/details/106583450
1.4.二级索引
主键索引之外的都可以统称二级索引
1.5.覆盖索引
：不需要回表查询；多字段创建一个索引，查询只需要返回覆盖索引包含的字段
2.索引的B+树如何生长的
3.索引优化
查询某张表有哪些索引：show index from tablename;
4.索引优化之explain
- id：编号
- select_type：查询类型
- type：索引类型
- table：表名
- possible_keys：预测用到的索引
- key：实际使用的索引
- key_len：实际使用索引的长度
- ref：表之间的引用
- rows：被索引优化查询的数据个数
- extra：额外信息
4.1 id
针对连表查询：
- id值相同，从上往下，顺序执行
- id值不同：id值越大越优先查询（在嵌套子查询时，先查内层，再查外层）
- 数据小的表，优先查询（rows）
- id值不同，id值越大越优先查询
4.2 select_type
- primary：包含子查询SQL中的主查询（最外层）
- subquery：包含子查询SQL中的子查询（非最外层）
- simple：简单查询
- derived：衍生查询（使用到了临时表）
- 在from子查询中只有一张表
- 在from子查询中，如果有table1 union table2，则table1就是derived
4.3 type
system > const > eq_ref > ref > range > index > all，要对type优化的前提是：有索引
system、const 理想情况
ref、range 实际能达到
- system：只有一条数据的系统表，或衍生表只有一条数据的主查询
查询返回的字段有些有索引，有些没有
- const：仅仅能查到一条数据的SQL，用于primary key或unique索引
- eq_ref：唯一性索引，对于每个索引键的查询，返回匹配唯一行数据（有且只有1个，不能多、不能0）
select ... from ...where name = ... 常见于唯一索引和主键索引 - ref：非唯一性索引，返回匹配的所有行（0，多）
- range：检索指定范围的行，where后面是一个范围查询(between..in,>,<=)
特殊：in有时候会失效，从而转为无索引all
- index：查询全部索引中数据
- all：查询全部表中数据
总结:
- system/const：结果只有一条数据
- eq_ref：结果多条，但是每条数据是唯一的
- ref：结果多条，但是每条数据是0或是多条
4.4 possible_keys
如果possible_keys/key是null，则说明没用索引
4.5 key_len
：索引的长度，用于判断复合索引是否被完全使用
一个字符占3个字节，一个字节表示null，两个字节标识可变长度
4.6 extra
- using filesort：性能消耗比较大，需要"额外"的依次排序（查询），常见于order by语句中
- using tempoary：性能损耗大，用到了临时表，一般出现在groupby（已经有表了，但不适用，必须再来一张表）
- using where：需要回原表
- using index：性能提升，索引覆盖（覆盖索引）。原因，不读取原文件，只从索引文件中获取数据（不需要回表查询）
- 如果用到了索引覆盖时，会对possible_keys和key造成影响
- 如果没有where，则索引只出现在key中
- 如果有where，则索引出现在key和possible_keys中
- 如果用到了索引覆盖时，会对possible_keys和key造成影响
- using join buffer：mysql主动优化，加了缓存
- impossible where：WHERE子句始终为false，不能选择任何行
select ... from ... where 1 < 0; - using index condition：using index + 回表 + where 过滤
5.索引优化之慢日志查询
注：不要在生产环境测试（测试环境数据量最好和生产环境一致）
：mysql提供的一种日志记录，用于记录mysql中响应时间超过阈值（long_query_time 默认10s），默认是关闭的，最终部署是关闭。
查询mysql是否开启慢日志查询： show variables like'%slow_query_log%'
临时开启： set global slow_query_log = 1;
设置慢查询阈值：set global long_query_time = 5; (修改后，重新登录后起效，不需要重启服务)
在内存中开启；重启 mysql service restart mysql
永久开启：在 /etc/my.cnf 中追加配置：
slow_query_log=1
slow_query_log_file=/var/lib/mysql/localhost-slow.log
# 超时时间
long_query_time=3
查看超过阈值的sql：show global status like '%slow_queries%';
或者去指定的日志文件去看 /var/lib/mysql/localhost-slow.log
6.单表优化
- 最佳左前缀，保持索引的定义和使用的顺序一致性
- 索引需要逐步优化
- 将含In的范围查询放where条件的最后，防止失效
- 通过key_len证明in可以使索引失效
7.两表优化
teacher ：tid，cid
course ：cid，cname
索引往哪加？-小表驱动大表[一般情况下对于左外连接，给左表加索引；右外连接，给右表加索引]
8.三表优化
- 小表驱动大表
- 索引建立在经常查询的字段上
9.避免索引失效的一些原则
- 复合索引，不要跨列或无序使用（最佳左前缀）
- 复合索引，尽量使用全索引匹配
- 不要在索引上进行任何操作（计算，函数，类型转换），否则索引失败
- 对于复合索引，如果左边失效，右边全部失效
- 复合索引不能使用不等于（!= <>）或is null（is not null），否则自身以及右侧所有全部失效；复合索引有 > ，则自身和右侧索引全部失效
- %x% 会导致索引失效， x% 不会 ，或者用索引覆盖
- 尽量不要使用类型转换（显式、隐式），否则索引失效
- 尽量不要使用or，否则索引失效，将or左侧的索引失效
10.一些其他的优化方法
- 如果主查询的数据集大，则使用in
- 如果子查询的数据集大，则使用exist。
select...from table where exist/in (子查询);
exist: 将主查询的结果，放到子查询中进行条件校验，如果复合校验，则保留数据
- order by 优化
- using filesort：双路排序、单路排序（根据IO的次数）
- 选择使用单路、双路；调整buffer的容量大小
- 避免select * ...
- 复合索引 不要跨列使用，避免using filesort
- 保证全部的排序字段，排序的一致性（都是升序 或 降序）
mysql4.1 默认使用 双路排序（扫描两次磁盘 【1.从磁盘读取排序字段
｛在buffer中进行的排序｝ 2.扫描其他字段】）；4.1之后，默认使用单
路排序 （只读取一次【全部字段｛在Buffer中进行排序｝】），有一定
隐患，不一定是一次，可能是多次IO
原因：如果数据量特别大，则无法将所有字段的数据一次性读完，索引
会进行"分片读取"
注意：单路排序比双路排序，会占用更多的Buffer。如果数据大，可以
考虑调大buffer的容量大小：set max_length_for _sort_data = 1024
byte
如果max_length_for _sort_data太低（需要排序的列总大小超过了
max_length_for _sort_data定义的字节数），则mysql会自动从单路切
换到双路