- 索引越多越好?
一本100页的书,如果有50页目录,书本这么厚,实际内容就那么少,谁还会去翻看
(索引和内容一样多了,谁还去看索引)
数据量小的表不需要建立索引,建立会增加额外的索引开销;
数据变更需要维护索引,因此更多的索引意味着更多的维护成本;
索引也是需要空间来存放的,更多的索引意味着也需要更多的空间;
- 建立索引的原则
若字段满足唯一,则建立唯一索引,如学号,因为唯一索引的性能极高
为经常进行排序、分组的字段建立索引
·若字段很长,则建立前缀索引
·区分度高的字段建索引(像性别这种区分度- >唯一度不高的索引么有价值)
·建立索引的字段不能有NULL值
- 覆盖索引
如果一个联合索引包含我们需要的所有数据,则称之为覆盖索引,那么查到数据之后直接从索引拿,无需回表,可以极大提升性能
- MVCC
https://blog.csdn.net/h2503652646/article/details/117152307
多版本存储
版本链
每行会保存两个隐藏的列 ,事务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可以另一种查看方式