- 索引越多越好？
一本100页的书，如果有50页目录，书本这么厚，实际内容就那么少，谁还会去翻看
（索引和内容一样多了，谁还去看索引）
数据量小的表不需要建立索引,建立会增加额外的索引开销；
数据变更需要维护索引,因此更多的索引意味着更多的维护成本；
索引也是需要空间来存放的，更多的索引意味着也需要更多的空间；
- 建立索引的原则
若字段满足唯一，则建立唯一索引，如学号，因为唯一索引的性能极高
为经常进行排序、分组的字段建立索引
·若字段很长，则建立前缀索引
·区分度高的字段建索引(像性别这种区分度- >唯一度不高的索引么有价值)
·建立索引的字段不能有NULL值
- 覆盖索引
如果一个联合索引包含我们需要的所有数据，则称之为覆盖索引，那么查到数据之后直接从索引拿，无需回表，可以极大提升性能
- MVCC
多版本存储
版本链
每行会保存两个隐藏的列 ，事务id列，存储指向上一个版本的指针列
- Limit
所以例子中 “LIMIT 10,10” 前面的 10 表示第 11 条，后面的 10 表示需要查询的条数，若不指定其实位置,默认是 0，即 “LIMIT 10” 和 “LIMIT 0,10” 是同一个意思。
如果索引涉及到表中大部分数据时，
Mysql会进行全局扫描不走索引
Hash索引二次扫描
先找到行的指针，第二次获得数据
hash索引无法排序
性别不适合建立Hash索引
身份证适合Hash索引
B+按顺序索引
利于orderby groupby
索引优化策略
索引列上不能使用表达式或函数
前缀索引尽可能小但是查询性能不能太差
abc abg abv
联合索引
经常被使用到的列优先左边（当然像状态这种过滤性能很差就不会适合放在最左边了）
选择性高的列优先
宽度小的列优先
覆盖索引
不仅是where中，也包含orderby groupby
覆盖索引要求一次查询像B+
Hash索引就不能建立覆盖索引
覆盖索引查询的就是索引的数据
如果查询* 再结合索引，就需要索引去二次取数据，就不算是覆盖索引了
SQL查询优化
\G可以另一种查看方式
