zoukankan      html  css  js  c++  java
  • mysql 查询优化 ~ explain与索引失效

    一 explain
      1 扫描行数根据的是表的统计元数据
      2 索引的元数据具体指的就是show index from查到的索引的区分度,索引的区分度越高越好
      3 表的元数据是定期收集,所以可能不准确
      4 如果感觉explain不准确,可以用analyze table t命令重新收集
      5 元数据不准确的场景大多出现在大量删除数据和插入数据场景,针对大表尤其如此
    二 元数据收集
      参数 innodb_stats_persistent=ON 默认会持久化到内存 默认打开
      参数 innodb_stats_auto_recalc 这个参数控制着在表中行的数量改变超过10%的时候,是否重新收集统计信息 这个收集的动作是异步的,在执行完大的dml后,可能会过一段时间才重新收集统计信息 默认打开
      参数 innodb_stats_persistent_sample_pages 采样使用的页数 默认20 1 调大可能使analyze命令缓慢,加重负担 2调小可能使大量的执行计划产生误区,并不建议调整此值
    三 mysql优化器选择错误索引的方法
      1 采用force index强制走某项索引,但是这可能导致一个问题,以后系统迁移或者索引名变更会导致问题
      2 改写sql语句,让mysql优化器进行再次判断,选择正确的索引
      3 直接删除索引本身,让mysql优化器无法选择该索引
    四 总结
     1 如果出现mysql执行计划不准确的情况下,可以采用上述方式进行处理,一般情况下,出现索引判断失误的情况比较少

    五 明显失效的几个场景

        1 当range出现  row扫描为1 ROW时候   

        2  扫描的行数远远多于表本身的数据量

  • 相关阅读:
    LeetCode#22 Generate Parentheses
    重传
    数学问题——gcdgcl
    数学问题——十进制转N进制
    数据模型
    IEEE
    格与代数系统
    数据字典
    贪心算法
    群论
  • 原文地址:https://www.cnblogs.com/danhuangpai/p/10095001.html
Copyright © 2011-2022 走看看