- b+树的查找过程:如上图所示,如果要查找数据项29,那么首先会把磁盘块1由磁盘加载到内存,此时发生一次IO,在内存中用二分查找确定29在17和35之间,锁定磁盘块1的P2指针,
内存时间因为非常短(相比磁盘IO)可以忽略不计,通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存,发生第二次IO,29在26和30之间,锁定磁盘块
3的P2指针,通过指针加载磁盘块8到内存,发生第三次IO,同时内存中做二分法查找找到29,结束查询,总计三次IO。真实的情况是,3层的b+树可以表示上百万
的数据。 - b+树的性质:
- IO次数取决于b+树额高度h,假设当前数据表的数据为N,每个磁盘块的数据项的数量是m。则有h=log(m+1)N,当数据量N一定的情况下,m越大,h越小;而m=磁盘块的大小/数
据项的大小,磁盘块的大小也就是一个数据页的大小,是固定的,如果数据项占的空间越小,数据项数量越多,树的高度越低。这就是为什么每个数据项,即索引字段要尽量的小,
也是为什么b+树要求把真实数据放到叶子节点而不是内层节点,一旦放到内层节点,磁盘块的数据项会大幅度下降,导致树增高。 - 当b+树的数据项是复合的数据结构,比如(name,age,sex)的时候,b+树是按照从左到右的顺序来建立搜索树的,比如当(张三,20,F)这样的数据来检索的时候,b+树会优
先比较name确定下一步的搜索方向,如果name相同再依次比较age和sex,最后得到检索的数据。索引的最左匹配属性。 - 建索引的几大原则:
- 最左前匹配原则
- =和in可以乱序
- 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,比例越大我们扫描的记录数越少
- 索引列不能参与计算
- 尽量的扩展索引,不要新建索引
- 慢查询优化基本步骤:
0.先运行看看是否真的很慢,注意设置SQL_NO_CACHE
1.where条件单表查,锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起,单表每个字段分别查询,看哪个字段的区分度最高
2.explain查看执行计划,是否与1预期一致(从锁定记录较少的表开始查询)rows
3.order by limit 形式的sql语句让排序的表优先查
4.了解业务方使用场景
5.加索引时参照建索引的几大原则
6.观察结果,不符合预期继续从0分析