当前位置: 首页 > article >正文

MySQL中索引最左前缀法则、索引失效情况、前缀索引、索引设计原则

最左前缀法则

  • 联合索引中,最左前缀法则指的是查询从索引的最左列开始,并且不跳过索引中的列,如果跳跃某一列,索引将会部分失效(后面的字段索引失效)
  • 举例假设有一个联合索引包含三个字段按顺序:name、age、status
  • 也就表示where条件中必须包含name字段,否则就不会走该索引
  • 如果where条件中只包含name、status,那么走该索引但是只走了部分,因为跳过了age列,跳过列后面的字段索引会失效

范围查询

  • 联合索引中,出现范围查询(>、<),范围查询右侧的列索引失效
  • 还是上述的例子有一个联合索引包含三个字段按顺序:name、age、status
  • where name = ‘zhangsan’ and age > 18 and status = ‘0’,只有name和age字段走了索引,status字段索引失效
  • where name = ‘zhangsan’ and age >= 18 and status = ‘0’,>=全部字段索引都会生效
  • 所以,在业务允许的情况下,尽可能使用类似于>=或<=,而避免使用>或<

索引失效情况

  • 索引列运算

    • 不要在索引列上进行运算操作,索引将失效
    • 比如对某个索引列进行了函数运算操作,将导致索引失效
  • 字符串不加引号

    • 字符串类型不加引号,数据库存在隐式类型转换,索引将失效
  • 模糊查询

    • 如果仅仅是尾部模糊匹配,索引不会失效,like ‘字符串%’
    • 如果是头部模糊匹配,索引失效,like ‘%字符串’
  • or连接条件

    • 如果or前的条件中的列有索引,而后面的列中没有索引,那么涉及到的索引都不会被用到
    • 使用or连接的条件,必须左右两侧字段都有索引,索引才会生效
  • 数据分布影响

    • 如果MySQL评估使用索引比全表更慢,则不使用索引
    • 因为索引是用来检索少量数据的,如果通过索引查询返回大批量的数据,则还不如走全表扫描来的快,此时索引就会失效

索引的SQL提示

  • 问题:有一个字段既在单列索引,也在联合索引的最左列,会走哪个索引呢?

  • 简介:SQL提示,是优化数据库的一个重要手段,简单来说,就是在SQL语句中加入一些人为的提示来达到优化操作的目的

  • 语法

    • use index:建议MySQL使用哪一个索引完成此次查询(仅仅是建议,MySQL内部还会再次进行评估)

    • ignore index:忽略指定的索引

    • force index:强制使用的索引

  • 示例:select * from tb_user use index (idx_name) where name = ‘zhangsan’

前缀索引

  • 当字段类型为字符串(varchar、text、longtext等)时,有时候需要索引很长的字符串,这会让索引变的很大,查询时,浪费大量的磁盘IO,影响查询效率。

  • 此时可以只将字符串的一部分前缀,建立索引,这样可以大大节约索引空间,从而提高索引效率

  • 语法:create index index_name on table_name(column(n));

  • 前缀长度

    • 可以根据索引的选择性来决定,而选择性是指不重复的索引值(基数)和数据表的记录总数的比值

    • 索引选择性越高则查询效率越高

    • 唯一索引的选择性是1,这是最好的索引选择性,性能也是最好的

      -- 求取前缀长度公式
      select count(distinct email) / count(*) from tb_user;
      select count(distinct substring(email,1,5)) / count(*) from tb_user;
      -- 根据查询效率和节约空间之间做一个平衡选择前缀长度
      

索引设计原则

  • 针对于数据量较大,且查询比较频繁的表建立索引
  • 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引
  • 尽量选择区分度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高
  • 如果是字符串类型的字段,字段的长度较长,可以针对于字段的特点,建立前缀索引
  • 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间,避免回表,提高查询效率
  • 要控制索引的数量,索引并不是多多益善,索引越多,维护索引结构的代价也就越大,会影响增删改的效率
  • 如果索引列不能存储null值,请在创建表时使用not null约束它。当优化器知道每列是否包含null值时,它可以更好地确定哪个索引最有效地用于查询
http://www.lryc.cn/news/2384283.html

相关文章:

  • ⚡ Linux Debian 安装与配置 Docker
  • 系统性能不达标,如何提升用户体验?
  • 《深度掌控Linux:openEuler、CentOS、Debian、Ubuntu的全方位运维指南》
  • Sentinel原理与SpringBoot整合实战
  • 智能守护校园“舌尖安全“:AI视频分析赋能名厨亮灶新时代
  • c++ 模板技巧——类型萃取
  • 初步尝试AI应用开发平台——Dify的本地部署和应用开发
  • 卷积神经网络中的局部卷积:原理、对比与应用解析
  • 重拾童年,用 CodeBuddy 做自己的快乐创作者
  • MyBatis-Plus的自带分页方法生成的SQL失败:The error occurred while setting parameters
  • Redis 的速度为什么这么快
  • HarmonyOS实战:自定义时间选择器
  • Flannel后端为UDP模式下,分析数据包的发送方式——tun设备(三)
  • 6:OpenCV—图像滤波
  • pytorch语法学习
  • 5:OpenCV—图像亮度、对比度变换
  • Oracle 的V$ACTIVE_SESSION_HISTORY 视图
  • redis数据持久化和配置-13(配置 AOF:Appendfsync 策略)
  • 【Python 算法零基础 4.排序 ② 冒泡排序】
  • Python:操作Excel设置行高和列宽
  • docker-volume-backup 备份 ragflow volumes
  • Axure设计数字乡村可视化大屏:从布局到交互的实战经验分享
  • 算法第26天 | 贪心算法、455.分发饼干、376. 摆动序列、 53. 最大子序和
  • PDF处理控件Aspose.PDF教程:以编程方式将 PDF 导出为 JPG
  • Vue3+ElementPlus 开箱即用后台管理系统,支持白天黑夜主题切换,通用管理组件,
  • AI大模型应用之评测篇
  • 力扣小题, 力扣113.路径总和II力扣.111二叉树的最小深度 力扣.221最大正方形力扣5.最长回文子串更加优秀的算法:中心扩展算法
  • el-form elform 对齐方式调整
  • JESD204 ip核使用与例程分析(二)
  • Linux shell 正则表达式高效使用