引擎
系列文章
Myisam
- 一共有三个文件,数据和索引分两个文件保存
- frm文件为表的定义文件
- MYI索引文件
- MYD数据文件
innodb
- frm文件为表的定义文件
- IBD索引和数据存放在一个文件
辅助索引
- 以主键为索引来组织数据的存储,叶子节点中存放数据
- 如果以name为索引,先在辅助索引中找到对应叶子节点,在通过关键字(主键)在主键索引中找到对应的数据
索引
列的离散性
count(distinct col) : count(col)
比例越大,离散性越好,选择性最好
- 主键的离散性最好
- 离散性差的,查找可以选择路很多
最左匹配原则
对索引中的关键字进行计算(对比),一定是从左往右依次进行,且不可跳过
联合索引
- 单列索引
节点关键字[id]
- 联合索引
节点关键字[id,name]
选择原则,优先程度依次递减
- 经常用的列优先【最左匹配原则】
- 选择性(离散性)高的列优先【离散度高原则】
- 宽度小的列优先【最少空间原则】
覆盖索引
如果查询列可以通过索引节点中的关键字直接返回,则该索引称为覆盖索引。
覆盖索引可以减少数据库IO,将随机IO编程顺序IO,提高查询性能
举例:
select name,age from user where name = 'xwf'
如果联合索引index=[name,age]
当name命中的时候,因为支节点存在name和age两个关键字,直接返回结果,不需要再找到叶子节点进行数据返回,如果使用select *,需要查询name和age以外的字段,还是要到叶子节点中去获取数据。
- 使用select * 不会走覆盖索引
当sql语句会使用覆盖索引的时候,不能使用select * ,必须要指定查询列
索引优化建议
- 索引列的数据长度能少则少
- 因为长度越小,单个节点能存的关键字和路就越多
- 索引一定不是越多越好,越全越好,一定要建合适的索引
- 索引会占空间
- 索引会影响插入、更新、删除的性能
- 匹配列前缀可用到索引like 9999%(有可能会用到索引,要看like条件的离散性);like %9999%,like%9999用不到索引
- 最左匹配原则
- 但是如果列的离散性很差,还是会全表扫描
- Where条件中not in和<>操作无法使用索引
- 无法判断需要走哪一路
- 匹配范围值,order by也可以用到索引
- 只要离散性好,有一定几率可以使用到索引
- 多用指定列的查询,少用select *
- 覆盖索引的特性
- 联合索引中如果不是按照索引最左列开始查找,无法使用索引
- 最左匹配原则
- 联合索引中精确匹配最左前列(最左的first列),并且范围(大于,小于)匹配另外一列可以用到索引
- 只要另外的这一列离散性好,有一定几率可以使用到联合索引
- 联合索引中如果查询中有某个列的范围查询(大于,小于),则其右边的列都无法使用索引
系列链接
上一篇:MySql B+Tree