我随手在网上搜了下， 基本全部都是这个结论，似乎这个结论大家都耳濡目染了，应该大多数人都觉得这个结论是正确的吧。
联合索引的最左前缀原则属于面试高频题，想必大部分同学都知道一些，但是，那些不符合最左前缀的部分，会怎么样呢（索引下推）
👋 你好，我是 Lorin 洛林，一位 Java 后端技术开发者！座右铭：Technology has the power to make the world a better place.
他创建了一张数据库表，表里的字段只有主键索引（id）和联合索引（a，b，c），然后他执行的 select * from t where c = 0; 这条语句发现走的是索引，他就感觉很困惑，困惑在于两点：
如果表也有DML, 我一般只在a 上建索引. 这也是代价平衡的结果. 一方面 只在a 上建索引那么是
联合索引可以测试包含索引中所有列的查询，或仅测试第一列、前两列、前三列等等的查询。如果在索引定义中以正确的顺序指定列，则复合索引可以加快对同一表的多种查询的速度。
3):查询条件中没有出现联合索引的第一列,而出现联合索引的第二列,或者第三列,都不会利用联合索引查询.
按照ER图，建立数据库和表，并且进行测试数据的填充。（建表sql和填充脚本的文件可公众号（Vegout）回复关键字“联合索引”获取）
主键索引（Primary Key Index）：每个表都有一个主键，主键索引是自动创建的唯一索引。它通常是聚簇索引（在索引树的叶子结点中存储的是需要查找的数据）。
要查询的数据，索引已经覆盖了该数据，不需要回到主键索引。例如，select ID from T where k between 3 and 5. 表T在主键ID以及k上有索引。上述的查询在k索引中能获取到主键ID，不需要回表。
最左匹配原则就是指在联合索引中，如果你的 SQL 语句中用到了联合索引中的最左边的索引，那么这条 SQL 语句就可以利用这个联合索引去进行匹配。例如某表现有索引(a,b,c)，现在你有如下语句：
最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配。
上一篇文章《MySQL索引那些事》主要讲了MySQL索引的底层原理，且对比了B+Tree作为索引底层数据结构相对于其他数据结构（二叉树、红黑树、B树）的优势，最后还通过图示的方式描述了索引的存储结构。但都是基于单值索引，由于文章篇幅原因也只是在文末略提了一下联合索引，并没有大篇幅的展开讨论，所以这篇文章就单独去讲一下联合索引在B+树上的存储结构。
转于：https://blog.csdn.net/claram/article/details/77574600
在数据库设计和查询优化中，联合索引是一个强大的工具，它可以显著提高数据检索的速度。然而，要充分利用联合索引的优势，我们需要理解它们是如何影响查询效率的。本文将探讨联合索引的工作原理以及如何使用它们来优化查询。
无论单列索引 or 联合索引，一个索引就对应一个独立的B+索引树，索引树节点仅包含：
通过之前文章 基于Vue和Quasar的前端SPA项目实战之动态表单（五）的介绍，关于表单元数据配置相关内容已经实现了，本文主要介绍联合索引功能的实现。
最近，在 mysql 测试最左前缀原则，发现了匪夷所思的事情。根据最左前缀原则，本来应该索引失效，走全表扫描的，但是，却发现可以正常走索引。
列的离散性(可以理解为差异性)=count（distinct col ) / count（col）
只要说到联合索引，大家肯定都会想到“最左匹配”，相信不用解释大家也知道是啥意思，也很简单，但是联合索引中又有不少特殊情况，
联合索引是指对表上的多个列进行索引，联合索引也是一棵B+树，不同的是联合索引的键值数量不是1，而是大于等于2.
之前在网上看到过很多关于mysql联合索引最左前缀匹配的文章，自以为就了解了其原理，最近面试时和大牛交流中，发现遗漏了些东西，这里自己整理一下这方面的内容。
leaf 叶子 存储数据行时就是有序的 直接将数据行的page作为叶子节点（相邻的叶子节点，有双向指针）
背景： 为了提高数据库效率，建索引是家常便饭；那么当查询条件为2个及以上时，我们是创建多个单列索引还是创建一个联合索引好呢？他们之间的区别是什么？哪个效率高呢？我在这里详细测试分析下。
在 SQL 优化中，索引是至关重要的一环，能给查询效率带来质的飞跃，但是索引并不是万能的，不合理的索引设计甚至会拖慢查询效率。本文将详细介绍索引的概览和分类，并讨论使用索引时应该权衡的要素，关于索引底层实现的内容将在下一篇文章 MySQL 索引结构 中介绍。
今天主要来聊聊 MySQL 中索引的工作原理，这一部分的知识，在工作中经常被使用到，在面试中也几乎是必问的。所以，不管是面试造火箭，还是工作拧螺丝，掌握索引的工作原理，都是十分有必要的。
经常有同学疑问，为什么有时候一个SQL语句使用了索引，为什么还是会进入到慢查询之中呢？今天我们就从这个问题开始来聊一聊索引和慢查询。
花1分钟时间，了解聚集索引，非聚集索引，联合索引，索引覆盖。 举例，业务场景，用户表，表结构为： t_user( uid primary key, login_name unique, passwd, login_time, age, … ); 聚集索引(clustered index)：聚集索引决定数据在磁盘上的物理排序，一个表只能有一个聚集索引，一般用primary key来约束。 举例：t_user场景中，uid上的索引。 非聚集索引(non-clustered index)：它并不决定数据在磁盘上的
在 MySQL 中，最左前缀匹配指的是在查询时利用索引的最左边部分进行匹配。当你执行查询时，如果查询条件涉及到组合索引的前几个列，MySQL 就能够利用该复合索引来进行匹配。
联合索引又叫复合索引，是MySQL的InnoDB引擎中的一个索引方式，如果一个系统频繁地使用相同的几个字段查询结果，就可以考虑建立这几个字段的联合索引来提高查询效率。
无论在工作还是面试中，关于SQL中不要用“SELECT *”，都是大家听烂了的问题，虽说听烂了，但普遍理解还是在很浅的层面，并没有多少人去追根究底，探究其原理。
上面ID索引树进行查找记录的过程叫回表，可以看出k树索引树进行了三次查询，Id索引树进行了两次查询。查询数据过程中是否可以避免回表查询呢，
当字段类型为字符串（varchar，text，longtext等）时，有时候需要索引很长的字符串，这会让索引变得很大，查询时，浪费大量的磁盘IO， 影响查询效率。此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。
经常有同学问我，我的一个SQL语句使用了索引，为什么还是会进入到慢查询之中呢？今天我们就从这个问题开始来聊一聊索引和慢查询。 另外插入一个题外话，个人认为团队要合理的使用ORM，可以参考我的另外一篇<ORM的权衡和抉择>。合理利用的是ORM在面向对象和写操作方面的优势，避免联合查询上可能产生的坑(当然如果你的Linq查询能力很强另当别论)，因为ORM屏蔽了太多的DB底层的知识内容，对程序员不是件好事，对性能有极致追求，但是ORM理解不透彻的团队更加要谨慎。
接了一个小需求，是将一些用户操作记录入到我们的数据库中。观察到入库的接口平均响应时间比较差大概在几秒左右，当时没多想，就觉得是先查询是否存在，再插入这个过程中查询是否存在比较耗时（因为操作记录表比较大），但是后面发现有10%，20%的入库接口响应时间甚至达到了十秒，并且pgsql数据库cpu变高了很多，波段性的高峰存在。老样子，先查询是否存在慢sql，耗时3秒以上的sql查询load出来后发现原来是查询是否存在的这个过程出了问题。我是通过一个联合索引来查询是否存在的，他们分别是(公司id，店铺id，xxid)，通过explain该sql语句发现并没有走这个联合索引，而是走了(公司id，店铺id)这个索引。而这个索引扫出来的结果并没有区分度，因为一个公司的某一个店铺可以有很多的操作记录。让我们来思考一下联合索引的定义，它满足最左前缀匹配原则，mysql的查询优化器会自动将你代码中乱序的查询条件组装成联合索引去查询，进而通过联合索引来计算查询成本。但是最左前缀匹配原则是要求越有区分度的字段应该放在左边，我误以为sql的查询优化会自动帮我把联合索引的区分度字段往左边移动。这次事故的原因主要是因为我对最左前缀匹配原则理解的不深刻，下次应该尽可能的将具有区分度的字段放在联合索引的左边。
mysql认为可能还用到了唯一索引，但实际并没有用到，还是只用到了联合索引， 再看key_len的长度和情况1一样，所以验证结论，where后只有第一个范围查 找才生效（如果第一个索引失效，则顺延）。如果有联合索引，仅最左侧的索引字段生效. 范围查询+等值匹配 优先有索引的等值查询
如果遇到了范围查询，比如（<）（>）和 between 等， 会停止匹配，那后面的列就不会用到联合索引了。
作为开发人员数据库查询语句我们经常用到，但是你是否想过为什么大厂都会强制开发人员禁止使用 SELECT * 语句？你一定会说因为效率低啊，多差除了一些无用的数据。如果是这么想的，那就继续听我来说。
1.索引列的数据长度能少则少。 说明:为了减少我们简历B+树时候关键字的重量,让结点可以存放更多数据
相信没有人会故意创建重复的冗余的索引，很多重复和冗余的索引都是在不经意间创建的，今天松哥来和大家捋一捋这个问题。 因为我们日常在使用 MySQL 的过程中，基本上都是使用 InnoDB 引擎，所以接下来的讨论主要是基于 InnoDB 引擎的 B+Tree 索引来讨论，其他的哈希索引全文索引等不在讨论范围种。 1. 与联合索引重复 在前面的文章中，松哥通过好几篇文章和大家分享了联合索引，包括它涉及到的覆盖索引、前缀匹配等等，联合索引好用，但是对联合索引理解不到位的话，可能会创建出如下的重复索引： CREATE
单字段索引不能满足你了，那就多来几个... 创建普通索引的时候，指定两个或更多的字段 这就是联合索引，语法如下 alter table 表 add index 索引名(字段1,字段2) 维护数据库时发现现索引重复了？ 这时可以删掉重复的索引，释放内存空间，提高查询效率 #因为联合索引（A，B）相当于创建了（A）和（A，B）索引 KEY idx\_Id (Id) KEY idx\_Id\_age (Id, age) #所以这里可以删除Id 这个索引； 使用联合索引时，注意索引
这是一个同行问的问题：有一张表，带一个联合索引，SQL 不满足最左匹配，为什么执行计划显示能用到这个联合索引？
非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树（简单说， 左边比自己小，右边比自己大）
首先SQL判断一个语句是不是慢查询语句，用的是语句的执行时间。他把语句执行时间跟long_query_time这个系统参数作比较，如果语句执行时间比它还大，就会把这个语句记录到慢查询日志里面，这个参数的默认值是10秒。当然在生产上，我们不会设置这么大，一般会设置1秒，对于一些比较敏感的业务，可能会设置一个比1秒还小的值。
之前写过一篇Mysql B+树学习,简单的介绍了B+数以及MySql使用B+树的原因, 有了这些基础知识点,对MySql索引的类型以及索引使用的一些技巧,就比较容易理解了。
点击上方蓝色“程序猿DD”，选择“设为星标” 回复“资源”获取独家整理的学习资料！ 作者 | 张飞洪 来源 | cnblogs.com/jackyfei/p/12122767.html 经常有同学问我，我的一个SQL语句使用了索引，为什么还是会进入到慢查询之中呢？今天我们就从这个问题开始来聊一聊索引和慢查询。 另外插入一个题外话，个人认为团队要合理的使用ORM，可以参考 ORM的权衡和抉择。合理利用的是ORM在面向对象和写操作方面的优势，避免联合查询上可能产生的坑(当然如果你的Linq查询能力很强另当
如果查询条件使用的是普通索引（或是联合索引的最左原则字段），查询结果是联合索引的字段或是主键，不用回表操作，直接返回结果，减少IO磁盘读写读取正行数据
alter table table_name add index index_name(column_list)
面试官：“小陈，说一下你常用的 SQL 优化方式吧。” 陈小哈：“那很多啊，比如不要用 SELECT *，查询效率低。巴拉巴拉...”
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
腾讯会议
