数据库中存储引擎MvlSAM与InnoDB的区别
Mylsam适用于什么场景?
InnoDB和Mvlsam针对读写场景?
MySQL Innodb实现了哪个隔离级别?
InnoDB数据引擎的特点
InnoDB用什么索引
Hash索引缺点
数据库索引的类型，各有什么优缺点?
MySQL的索引有哪些?索引如何优化?
有哪些数据结构可以作为索引呢?
B树与B+树的区别?
为什么使用B+树作为索引结构?
不使用B+树，可以用那个数据类型实现一个索引结构
介绍下MySQL的联合索引联合索使用原则
数据库中存储引擎MylSAM与InnoDB的区别
1、事务处理：
- MyISAM：不支持事务处理，这意味着在MyISAM表上的操作无法进行回滚、提交等事务管理操作。
- InnoDB：支持事务处理，遵循ACID（原子性、一致性、隔离性、持久性）原则，适合需要高度数据完整性的应用。
2、外键支持：
- MyISAM：不支持外键约束，这意味着无法在表间建立引用完整性。
- InnoDB：支持外键约束，可以维护表间数据的一致性。
3、锁机制：
- MyISAM：使用表级锁，当一个进程访问表时，会锁定整个表，阻止其他进程同时访问，可能导致并发性能较低。
- InnoDB：支持行级锁和表级锁，默认使用行级锁，这大幅度提高了并发操作的性能，特别是对于写操作频繁的场景。
4、数据存储与恢复：
- MyISAM：不支持崩溃恢复，如果数据库崩溃，可能需要手动修复。MyISAM表将索引和数据分开存储，可以提高某些读取操作的性能。
- InnoDB：具有事务日志，支持崩溃恢复，能在数据库异常终止后自动恢复到一致状态，保证数据的高可靠性。
5、索引类型：
- MyISAM：支持全文索引，这对于文本搜索功能特别有用，但不支持聚集索引。
- InnoDB：默认使用聚集索引，数据文件本身就是按索引顺序存放的，每个表必须有主键，并且主键作为聚集索引。InnoDB从MySQL 5.6开始也支持全文索引。
6、适用场景：
- MyISAM：适合读取密集型的应用，特别是当数据不需要事务支持且并发写入较少时。
- InnoDB：适合需要事务处理、数据一致性和高并发写入的应用，如银行系统、电商网站等。
由于InnoDB提供了更多的安全性和数据完整性功能，自MySQL 5.5版起，InnoDB成为了MySQL的默认存储引擎。在大多数现代应用中，InnoDB因其更好的并发性能和数据安全性而被推荐使用。
MyISAM适用于什么场景?
MyISAM存储引擎在MySQL中主要适用于以下场景：
1、读取密集型应用：MyISAM非常适合那些读操作远多于写操作的应用场景，如博客、新闻网站、文档管理系统等。它的查询性能优异，尤其是当数据一旦写入就很少更改时。
2、静态数据存储：对于那些数据不经常更新，主要是用来做查询展示的表，MyISAM是一个不错的选择。例如，用于编制目录或分类清单的表，如岗位列表、拍卖物品信息、不动产业务等。
3、全文索引需求：MyISAM支持全文索引（FULLTEXT），如果你的应用需要对大文本字段进行全文搜索，MyISAM可能是更合适的选择，尽管InnoDB从MySQL 5.6开始也支持全文索引。
4、非事务性应用：如果你的应用不需要事务处理，即不需要回滚、提交等功能，MyISAM的简单性和较高的读取性能可能更符合需求。
5、低并发写入：由于MyISAM使用表级锁，当并发写入不是很高时，其锁机制的缺点不太明显，不会严重影响性能。
6、空间类应用：MyISAM支持数据压缩，可以通过myisampack工具对表进行压缩，节省存储空间，这在存储空间敏感的环境中很有用，但需要注意压缩后的表只能进行读操作。
InnoDB和MylSAM针对读写场景?
InnoDB:
- 读场景：InnoDB支持行级锁，这意味着在并发读取时，锁定的范围小，能够更好地处理高并发读取场景。虽然单个读操作可能不如MyISAM快，但其并发读能力通常更强。InnoDB的聚簇索引设计也有助于提升某些查询的效率。
- 写场景：InnoDB特别适合写密集型应用，因为它支持事务处理、行级锁以及崩溃恢复。在高并发写入时，行级锁能够减少写操作之间的冲突，提高整体写入吞吐量。事务的ACID特性确保了数据的一致性，使得它成为OLTP（在线事务处理）应用的理想选择。
MyISAM:
- 读场景：MyISAM在读取操作上有较好的性能，尤其是在不需要事务处理且并发写入压力小的情况下。它使用表级锁，这意味着在没有写操作或者写操作不频繁时，读取可以非常迅速，适合读取远多于写入的场景。
- 写场景：MyISAM不支持事务，且使用表级锁，这导致在写入操作期间会锁定整个表，从而限制了并发写入的能力。在写密集型应用中，MyISAM的性能通常不如InnoDB，特别是在高并发写入场景下，可能会引起严重的性能瓶颈。
总结来说，对于读写混合且需要事务支持的应用，InnoDB通常是更好的选择，因为它在并发控制和数据完整性方面表现更佳。而MyISAM更适合那些主要是读取操作，对数据一致性要求不高，且写操作较少的应用场景。随着技术的发展，InnoDB因其综合优势已经成为大多数MySQL应用的首选存储引擎。
MySQL InnoDB实现了哪个隔离级别?
MySQL InnoDB存储引擎实现了SQL标准定义的四种隔离级别，这些隔离级别主要用于控制并发事务中数据的可见性和一致性。以下是InnoDB实现的四种隔离级别的详细解释：
1、未提交读（Read Uncommitted）：
允许一个事务读取另一个事务尚未提交的数据。这可能导致“脏读”（Dirty Read）问题，即读取到未经确认的临时数据。
在InnoDB中，尽管技术上可以实现这个隔离级别，但通常不推荐使用，因为它可能导致数据不一致。
2、提交读（Read Committed）：
确保一个事务只能读取到其他事务已经提交的数据。这解决了脏读问题，但仍然存在“不可重复读”（Non-repeatable Read）和“幻读”（Phantom Read）的可能性。
在这个隔离级别下，每次读取都会获取最新的已提交数据，但在同一事务内多次读取同一数据时，可能会因为其他事务的提交而看到不同的数据。
3、可重复读（Repeatable Read）：
这是InnoDB的默认隔离级别。它保证在同一个事务中多次读取同样记录的结果是一致的，即使其他事务在此期间进行了修改。
InnoDB通过多版本并发控制（MVCC）和记录锁（Record Locks）以及间隙锁（Gap Locks）等技术，实现了可重复读隔离级别，从而避免了脏读和不可重复读问题。同时，在InnoDB中，通过一些特定的机制（如Next-Key Locks），还很大程度上避免了幻读现象。
4、串行化（Serializable）：
这是最高的隔离级别，它通过强制事务串行执行来避免脏读、不可重复读和幻读问题。
在这个隔离级别下，每个事务都会完全独立地执行，没有任何并发冲突。但是，这种级别的隔离会显著降低数据库的并发性能。
InnoDB数据引擎的特点
1、事务支持
- ACID特性：InnoDB支持ACID（原子性、一致性、隔离性、持久性）事务。这确保了数据库操作的高度可靠性和数据的一致性。
- 原子性：事务中的所有操作要么全部完成，要么全部不完成，不会停留在中间状态。
- 一致性：事务执行前后，数据库的状态必须保持一致。
- 隔离性：并发执行的多个事务之间应该相互隔离，一个事务的执行不应影响其他事务。
- 持久性：一旦事务被提交，其结果应该永久保存在数据库中，即使系统崩溃也不会丢失。
2. 行级锁定
- InnoDB使用行级锁定来控制并发访问，这可以提高多用户并发访问时的性能。行级锁定允许更多的用户同时访问表的不同行，减少了锁定冲突，提高了数据库的并发性能。
3. 外键约束
- InnoDB支持外键约束，可以在数据库层面保证引用完整性，避免数据不一致。外键约束定义了表之间的关系，确保引用表中存在对应的记录，从而维护了数据的逻辑关系。
4. 崩溃恢复
- InnoDB具有强大的崩溃恢复能力。它使用预写式日志（Write-Ahead Logging, WAL）策略来确保数据的持久性。在事务执行过程中，所有的修改首先被记录在日志中，然后再更新到数据文件中。这样，即使在系统崩溃的情况下，InnoDB也可以通过重放日志来恢复数据到一致的状态。
5. 支持MVCC（多版本并发控制）
- InnoDB采用MVCC机制来实现并发控制，这可以提高读写性能。MVCC允许数据库读操作不加锁，从而提高了并发性能。
6. 支持索引
- InnoDB支持B+树索引结构，这种索引结构可以提供高效的数据查找和查询性能。
7. 缓存机制
- InnoDB使用缓冲池来缓存数据和索引，这可以减少磁盘IO操作，提高性能。
8. 支持自动增长列
- InnoDB可以为自动增长列提供支持，方便插入数据时生成唯一的标识符。
9. 支持热备份和在线备份
- InnoDB支持在线热备份和在线备份，这意味着可以在不中断数据库服务的情况下进行备份操作，进一步提高了系统的可用性。
10. 对硬件要求较高
- 由于InnoDB支持多种高级特性，如事务、行级锁定、MVCC等，这些特性需要更多的内存和磁盘空间来支持，因此InnoDB对硬件的要求相对较高。
综上所述，InnoDB数据引擎以其强大的事务支持、高效的并发控制、完善的数据完整性保证和灵活的恢复机制等特点，成为MySQL中最受欢迎和广泛使用的存储引擎之一。
InnoDB用什么索引
InnoDB 存储引擎主要使用以下几种类型的索引：
- B+树索引（B-Tree Index）：这是InnoDB的默认索引类型，也是最常用的索引。B+树索引能够支持范围查询和排序操作，非常适合用于主键索引和常规的二级索引。在InnoDB中，表的数据存储与主键的B+树索引紧密相连，形成了聚集索引（Clustered Index），意味着数据行直接存储在索引的叶子节点上。对于非聚集索引（Secondary Index），叶子节点存储的是指向主键的指针。
- 自适应哈希索引（Adaptive Hash Index, AHI）：InnoDB引擎会根据访问模式自动为某些热点数据创建哈希索引，以加速查询。这是一个完全由数据库自动生成和管理的索引，用户无法直接干预其创建。自适应哈希索引旨在提高某些特定类型查询（如等值查询）的性能，通过将B+树索引的部分或全部内容转换为哈希表来实现快速查找。
- 全文索引（FULLTEXT Index）：InnoDB支持全文索引，允许对较大的文本字段进行全文本搜索。这种索引特别适用于包含大量文本的列，比如文章内容、评论字段等。
综上所述，InnoDB主要依赖于B+树索引来组织和访问数据，同时利用自适应哈希索引来进一步优化某些查询的性能，并且支持全文索引来满足复杂的文本搜索需求。
Hash索引缺点
1、不支持范围查询和排序：哈希索引是基于哈希函数计算的索引，数据在哈希表中按哈希值存储，这意味着数据并不是按照索引列的值排序的。因此，它不能有效地处理如 WHERE price > 100 这样的范围查询，也不支持基于索引列的排序操作。
2、仅适用于等值查询：哈希索引主要用于等值比较，如 =、IN() 或 <=>（等同于 IS NOT DISTINCT FROM），对于非等值查询或使用 LIKE 之类的操作符的查询则无法利用。
3、哈希冲突：不同的键值可能产生相同的哈希码，导致哈希冲突。虽然冲突可以通过链地址法等方法解决，但在冲突较多的情况下，查询性能会下降，因为需要遍历冲突链上的所有元素来找到匹配项。
4、无法利用前缀索引和部分索引列匹配：哈希索引基于索引列的全部内容计算哈希值，所以不能仅使用索引列的一部分来查找记录，这限制了其灵活性。
5、必须回表查询：哈希索引通常只存储哈希值和行指针（或记录ID），因此在找到哈希值对应的行指针后，还需要通过行指针回到实际的数据行获取完整数据，这称为“回表”，增加了额外的I/O操作。
6、随机数据分布：哈希函数计算后的结果通常是随机的，导致数据在磁盘上随机放置。对于连续增长的主键ID等场景，这可能导致数据分布不均，影响存储空间的使用效率。
7、无法减少磁盘I/O：由于哈希索引的随机分布特性，即使对于等值查询，如果索引没有完全缓存在内存中，也可能需要多次磁盘I/O来查找分散的索引项。
数据库索引的类型，各有什么优缺点?
1、普通索引（Non-Unique Index）
- 优点：提高查询速度，允许数据行中存在重复值。
- 缺点：占用额外的存储空间，插入、删除和更新索引列数据时需要维护索引，可能降低这些操作的速度。
2、唯一索引（Unique Index）
- 优点：确保索引列的值唯一，可用于实现数据完整性，同样能加速查询。
- 缺点：维护唯一性约束需要检查新数据，可能稍微降低插入操作的效率，同样占用额外存储空间。
3、聚集索引（Clustered Index）
- 优点：数据行与索引在一起存储，可以极大提高数据检索速度，特别是针对主键的查询。
- 缺点：每个表只能有一个聚集索引，更新聚集索引列时，数据行可能需要移动，影响写操作性能。另外，较大的索引列会增加数据页的分裂，影响性能。
4、非聚集索引（Secondary Index或Non-Clustered Index）
- 优点：可以有多个，不改变表中数据的物理顺序，指向数据行的指针可以是聚集索引键或行ID，适用于辅助查询。
- 缺点：查询时可能需要两次查找（先查索引再查数据行），增加了查询成本，且占用额外存储空间。
5、全文索引（Full-Text Index）
- 优点：特别适合处理文本数据的复杂查询，如模糊匹配、搜索包含特定词汇的文档。
- 缺点：索引创建和维护成本较高，占用大量存储空间，对于简单查询可能不如其他索引高效。
6、覆盖索引（Covering Index）
- 优点：索引包含了查询所需的所有数据，无需回表查询，显著提高查询速度。
- 缺点：索引更大，占用更多存储空间。
7、位图索引（Bitmap Index）
- 优点：在数据值种类有限的列上非常高效，特别适合数据仓库环境下的分析查询。
- 缺点：不适用于高基数（即唯一值很多）的列，更新频繁的表维护成本高，且占用空间可能随数据行数线性增长。
MySQL的索引有哪些?索引如何优化?
1、B-Tree索引：是最常用的索引类型，适用于大多数场景。它以B-Tree数据结构存储，支持范围查询和排序操作。
2、B+Tree索引：InnoDB存储引擎实际上使用的是B+Tree变体，特别适合范围查询，因为所有实际数据都存储在叶子节点上，且叶子节点之间通过指针相连，便于遍历。
3、哈希索引：基于哈希表实现，适用于等值查询，查询速度快，但不支持范围查询和排序。
4、全文索引：专为全文本搜索设计，适用于包含大量文本的列，如文章内容。
5、R-Tree索引：用于空间数据类型的索引，如GIS地理空间数据。
6、覆盖索引：包含查询所需的所有数据，无需回表查询，可以显著提高查询性能。
7、唯一索引：保证索引列的值唯一，可以加速查询并确保数据完整性。
索引优化策略包括：
1、选择合适的索引类型：根据数据特性和查询模式选择最适合的索引类型。
2、合理选择索引列：对经常出现在WHERE子句、JOIN条件、ORDER BY或GROUP BY中的列建立索引。
3、使用复合索引（联合索引）：根据查询需求，对多个列建立复合索引，并遵循最左前缀原则，即查询时从索引的最左列开始匹配。
4、避免过度索引：每个索引都会占用额外的存储空间和维护成本，过多的索引会减慢写操作（INSERT、UPDATE、DELETE）的速度。
5、定期分析和优化索引：使用ANALYZE TABLE和OPTIMIZE TABLE命令来分析表的状态，根据统计信息调整索引。
6、监控并识别慢查询：使用MySQL慢查询日志来识别性能瓶颈，针对性地优化相关索引。
7、避免索引失效情况：例如，避免在索引列上使用函数、避免使用前导模糊查询（如LIKE '%abc'）、避免在索引列上使用非等值比较（除非是优化过的范围查询）等。
8、考虑索引选择性：选择性高的索引（即不同值的比例高）通常更有效，因为它们能更快地缩小查询范围。
有哪些数据结构可以作为索引呢?
1、B-Tree（B树）：B-Tree是一种自平衡的多路查找树，广泛应用于文件系统和数据库中。它的特点是所有叶子节点都在同一层，且节点间的关键字有序排列，支持高效的范围查询和顺序访问。
2、B+Tree：B+Tree是B-Tree的一个变种，它将所有数据都存储在叶子节点上，并且叶子节点之间通过指针相连，形成一个有序链表，这优化了范围查询和全表扫描的性能。MySQL的InnoDB存储引擎主要使用的就是B+Tree索引。
3、Hash Table（哈希表）：哈希索引使用哈希表实现，适用于等值查询，通过哈希函数快速定位到数据。它提供了非常快的查询速度（常数时间复杂度），但不支持范围查询和排序。
4、BitMap（位图索引）：位图索引适用于低基数（少量不同值）的列，如性别（男/女）。它通过位来表示某个值是否存在，占用空间小，但对于高基数列效率低下。
5、R-Tree：R-Tree是一种适用于多维数据的空间索引，常用于地理信息系统（GIS）和空间数据库中，处理多维空间对象的查询，如地点、区域等。
6、Trie（字典树）：也称为前缀树，适用于字符串数据的索引，尤其是对前缀匹配查询非常高效。
7、Full-text Index（全文索引）：专为全文本搜索设计，通过倒排索引或其他高级文本索引结构实现，可以快速查找包含特定词汇的文档。
8、Adaptive Hash Index（自适应哈希索引）：某些数据库引擎（如MySQL的InnoDB）会在运行时根据访问模式自动生成哈希索引，以加速频繁查询的性能。
B树与B+树的区别?
B树和B+树都是平衡的多路查找树，广泛应用于数据库和文件系统中作为索引结构，但它们之间存在一些关键差异：
1、数据存储位置：
- B树：在B树中，数据可以存储在内部节点和叶子节点上。每个节点都包含数据项和指向子节点的指针。
- B+树：B+树中，所有实际的数据都只存储在叶子节点上，而内部节点（非叶子节点）仅存储数据的索引（键值），并不存放实际数据。内部节点作为索引，帮助指引到叶子节点，其中叶子节点包含所有数据项，并且叶子节点通过指针相互连接，形成了一个有序链表。
2、查询效率：
- B树：由于数据可能分散在内部节点和叶子节点，查询数据时可能在非叶子节点就找到所需数据，也可能需要走到叶子节点。因此，查询效率依赖于查询键在树中的位置。
- B+树：所有查询最终都会到达叶子节点，因为数据只存储在叶子节点上，这使得B+树的查询路径长度固定，查询效率更加稳定。对于范围查询和顺序访问特别有利，因为叶子节点间的指针形成了一个有序链表。
3、磁盘I/O效率：
- B+树通常被认为在磁盘读写上更为高效，因为内部节点更小，意味着同样大小的磁盘页可以存储更多的索引条目，从而减少了访问数据所需的I/O次数。
4、叶节点链接：
- B树的叶子节点通常不包含指向相邻叶子节点的指针，不形成连续链表。
- B+树的叶子节点包含指向相邻叶子节点的指针，形成一个有序链表，便于范围查找和全表扫描。
5、关键字数量：
- B树的每个节点可以存储m-1到m个关键字（取决于阶数m），内部节点的关键字数量直接影响到树的高度。
- B+树的内部节点可以存储m个关键字，但叶子节点也会存储m个关键字，并且是实际存储数据的地方。
综上所述，B+树的设计更偏向于优化范围查询和大量数据读取的场景，尤其是在磁盘I/O受限的数据库应用中。而B树在某些特定场景下，如需要快速访问内部节点数据时，也有其优势。
为什么使用B+树作为索引结构?
B+树作为数据库索引结构的选择，主要是基于以下几个关键因素：
1、磁盘友好性：数据库索引通常存储在磁盘上，而磁盘I/O相比内存访问来说要慢得多。B+树的结构设计使得每次磁盘I/O可以加载更多数据（因为内部节点不存储实际数据，可以存储更多索引条目），从而减少了查询过程中磁盘I/O的次数，提高了效率。
2、范围查询效率：B+树的叶子节点通过指针相连，形成了一个有序链表，这使得在执行范围查询时可以直接从一个叶子节点遍历到另一个叶子节点，而不需要回到根节点重新搜索，大大提升了范围查询的效率。
3、稳定性：在B+树中，所有实际数据都存储在叶子节点上，这意味着无论查询的键值位于树的哪一层，都需要访问到叶子节点才能得到数据，保证了查询性能的稳定性。
4、缓存利用效率：由于叶子节点包含所有数据并且是相连的，一旦叶子节点被载入内存，连续的数据访问可以更好地利用CPU缓存，进一步提高效率。
5、支持排序：B+树的叶子节点是一个有序链表，可以直接用于数据的排序输出，无需额外的排序操作。
6、高并发支持：在多用户环境下，B+树的结构对并发访问有较好的支持。插入和删除操作通常只需锁定受影响的索引节点，而不会阻塞整个索引或表，从而支持更高的并发度。
7、全表扫描优化：虽然全表扫描不是索引的主要用途，但在B+树中，通过遍历叶子节点链表可以高效地完成全表扫描，相较于没有索引的情况，性能仍然较好。
不使用B+树，可以用那个数据类型实现一个索引结构
如果不使用B+树作为索引结构，还有其他几种数据结构可以用来实现索引，每种都有其适用场景和优缺点。以下是一些常见的替代方案：
1、哈希表（Hash Table）：
- 哈希表通过哈希函数将索引键（如数据行的主键或唯一键）映射到一个固定大小的数组（或称为槽位）中。
- 优点：查找速度非常快，平均时间复杂度为O(1)；插入和删除操作也相对较快。
- 缺点：不支持范围查询；哈希冲突可能导致性能下降；需要动态调整哈希表的大小以应对数据增长。
2、跳表（Skip List）：
- 跳表是一种可以替代平衡树的数据结构，它通过在每个节点中增加多个向前指针来实现多级索引，从而提高查找效率。
- 优点：插入、删除和查找操作的时间复杂度接近O(log n)；结构简单，易于实现；支持范围查询。
- 缺点：相对于B+树，空间复杂度稍高，因为每个节点需要存储多个指针。
3、红黑树（Red-Black Tree）：
- 红黑树是一种自平衡的二叉查找树，它通过特定的节点颜色（红色和黑色）以及旋转操作来保持树的平衡。
- 优点：插入、删除和查找操作的时间复杂度均为O(log n)；支持范围查询。
- 缺点：在数据库系统中，由于磁盘IO的延迟远大于内存操作，红黑树相比B+树在磁盘I/O上的效率可能较低，因为B+树更适合于顺序访问和批量加载数据。
4、B树（B-Tree）：
- B树是B+树的前身，它也是一种自平衡的树结构，但与B+树不同，B树的非叶子节点也存储数据。
- 优点：与B+树类似，适合大量数据的存储和查找，支持范围查询。
- 缺点：由于非叶子节点也存储数据，因此在相同的磁盘页中存储的索引项数量可能会减少，导致树的高度增加，影响性能。
5、T树（T-Tree）：
- T树是一种专为外部存储设计的索引结构，它结合了B+树和前缀树（Trie）的特点，适用于处理具有前缀关系的字符串数据。
- 优点：特别适用于处理字符串数据的索引，如文本数据库中的单词查找。
- 缺点：相对于B+树，T树在实现上可能更复杂，且在某些场景下可能不如B+树高效。
在数据库索引的实际应用中，B+树因其高效的数据检索和范围查询能力，以及良好的磁盘I/O性能，被广泛采用。然而，在某些特定场景下，上述提到的其他数据结构也可能成为合适的选择。
介绍下MySQL的联合索引联合索使用原则
MySQL的联合索引（也称为复合索引）是基于多个列的索引，其使用原则主要包括以下几点：
1、最左前缀匹配原则：这是联合索引最重要也是最基本的原则。在查询时，MySQL会从索引的最左边的列开始匹配，然后依次向右匹配。如果查询条件没有从最左边的列开始，或者跳过了中间的列，那么跳过的列以及右边的所有列都将无法使用索引。例如，如果你创建了一个联合索引（A, B, C），那么查询条件中只有以A开头（如A、A和B、A和B和C）的列组合才能利用到索引。
2、索引列的顺序选择：选择哪些列以及列的顺序构建联合索引也很重要。一般应将区分度高（即唯一值多）的列放在前面，这样可以更快地过滤掉无关数据。此外，经常一起出现在查询条件中的列应该靠近一起放在索引中。
3、查询优化器的智能选择：尽管需要遵循最左前缀匹配原则，MySQL的查询优化器（EXPLAIN工具可以帮助理解查询的执行计划）可能会调整查询计划，尝试以最优的方式使用索引。即便查询条件中的列顺序与索引定义不完全一致，优化器也可能重排这些条件以更好地利用索引，但始终是从最左列开始。
4、范围查询的影响：如果联合索引中的某列涉及范围查询（如使用>、<、BETWEEN、LIKE以%开头等），那么该列右侧的所有列将无法使用索引。这是因为范围查询打破了索引的连续性，导致无法继续进行精确匹配。
5、覆盖索引：如果查询所需的所有数据都包含在索引中，即索引包含了查询的SELECT字段，这种情况下不需要回表查询，可以大大提高查询效率。因此，在设计联合索引时，考虑是否能够包含所有查询字段以形成覆盖索引也是一个优化方向。
6、避免过度索引：虽然索引有助于查询，但过多的索引会占用额外的磁盘空间，并且会降低插入、更新和删除操作的性能，因为每次数据变更时索引也需要相应更新。
引用：https://www.nowcoder.com/discuss/353159520220291072
通义千问、文心一言