2021-06-07 mysql索引 + 排序

Posted 2023-04-13

参考技术A btree效率低于hash,单更普遍

hash缺点: (推荐用于单列索引)

（1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。

（2）Hash 索引无法被用来避免数据的排序操作。

（3）Hash 索引不能利用部分索引键（组合索引）查询。

（4）Hash 索引在任何时候都不能避免表扫描。

（5）Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。

5.7以后合并索引单表,or

1.多列联合索引和复核索引的对比

多列联合索引 占空间,更新插入费时

复合索引 注重顺序,第一个索引列紧跟where,不是则不命中(但是复核索引所有列都出现不需要顺序全部命中)

mysql会自己根据优化策略觉得走多单列还是复合

(若三列,建一个复核,第二第三建单列,最大情况命中)

Mysql索引优化2

理想的索引

• 查询频繁
• 区分度高
• 长度小
• 尽量能覆盖常用查询字段

索引与排序

• 对于覆盖索引，直接在索引上查询时，就是有顺序的，using index
  • 在innodb引擎中，沿着索引字段排序自然是有序的
  • 在myisam引擎中，沿着索引字段排序，但取出来的字段有非索引字段，并不是索引->回行，索引->回行，而是一次性取出所有数据，再进行排序，explain这样的sql语句时，extra中就会出现using filesort
  • 要想办法避免filesort，尽可能的利用索引来排序
  • where a > 3 order by b 假设a列和b列都是独立索引，这样的sql explain中也会有using filesort, 因为a,b都是独立索引，在查询中只能用到a对应的索引，order by b时无法使用索引

Explain解释

• select type字段 
  • simple (不含子查询)
  • primary（含有子查询或派生查询）
    • subquery (非from子查询)
    • derived (from型子查询)
    • union
    • union result
• type字段 分析查询的关键字段
  • all < index < range < ref < eq_ref < (const, system, null)
  • all 全表扫描
  • index 扫描索引树上全部的索引节点
  • range 根据索引做范围的扫描
  • ref 通过索引列，直接引用到某些数据行
  • eq_ref 通过索引列，直接引用一行数据，常用于连接中
  • 一般按照主键查询时，易出现const, system 当查询不经过表时会出现null
• table字段
  • 真实的表名
  • 临时表 如as tmp
  • derived 如from型子查询
  • null 不使用表
• ref字段
  • 连接查询时，表之间字段的引用关系
• possible key字段
  • 可能使用的索引
• key 字段
  • 最终使用的索引
• key len 字段
  • 实际使用索引的长度
• rows 字段
  • 估计要扫描多少行
• extra 字段
  • using index 用到了索引覆盖
  • using where 光靠索引定位不了，还得where判断一下
  • using temporary 用到了临时表，效果已经非常不好了
  • using filesort 文件排序，可能在磁盘，也可能在内存中