Mysql性能优化：为什么要用覆盖索引？

索引覆盖能够提高MySQL查询效率的主要原因是避免了返表操作，减少了索引树中的搜索次数，从而显着优化查询性能。
下面具体分析： 1 、InnoDB索引模型及表返回机制 主键索引（聚集索引）：叶子节点存储整行数据。
例如，表User(id,age,name,address)的主键索引树中，叶子节点包含所有字段值。
非主键索引（普通索引）：叶子节点只存储主键值。
例如，年龄索引树的叶节点仅存储id值。
返回表过程：通过无主键索引查询时，需要先在普通索引树中找到主键值，然后通过主键索引树检索完整的数据。
例如： SELECT*FROMUserWHEREage=3 ;执行步骤：在年龄索引树中查找id=3 00。
根据id=3 00查询主键索引树中整个数据行（u3 ）。
返回结果。
这个过程需要扫描两棵索引树，效率较低。
2 .覆盖指标优化原理。
覆盖索引意味着所有查询的字段都包含在索引中，无需回表即可检索数据。
例如：SELECTidFROMUserWHEREage=3 ；执行步骤：不访问主键索引树，直接在age索引树中查找id=3 00。
避免了返表操作，并且只扫描一棵索引树，大大减少了 I/O 和计算开销。
3 .覆盖索引的优点。
减少 I/O 操作。
返回表需要对主键索引树进行额外访问，而覆盖索引直接从常规索引树获取数据，从而减少磁盘 I/O。
减少CPU消耗：无需串联整行数据，减少内存操作。
适用场景广泛：特别适用于现场查询很小并且包含在索引中（例如，仅查询主键或索引列）。
4 . 实际应用建议。
设计索引时覆盖查询字段。
例如，如果经常查询年龄和ID，则可以创建复合索引（年龄，ID）。
避免使用SELECT*：显式指定必填字段，以方便使用覆盖索引。
结合其他优化技术：如最佳左前缀原则进一步缩小索引扫描范围。
摘要： 覆盖索引通过消除表返回来优化查询，从“双树搜索”到“单树搜索”，从而提高性能。
这是MySQL重要的索引优化工具，特别适合高并发或者数据密集的场景。

MySQL 索引的底层数据结构是什么？ 为什么用这种数据结构？

MySQL（InnoDB存储引擎）索引的基本数据结构是B+树。
该架构将多路平衡搜索树的特点与数据库的存储和查询需求相结合，实现高效的数据检索和操作。
下面对具体因素进行分析： 1 、B+树的结构特点 多路径平衡搜索树 B+树是B树的一种变种。
它通过多路径分支保持平衡，保证树高较低（通常3 -4 层可以存储数百万数据）。
非叶子节点不存储数据。
非叶子节点仅存储索引键值和指向子节点的页指针（每个指针约1 4 字节）；优点： 风扇吞吐量更高：非叶子节点（如1 1 7 0）可以存储更多的指针，显着降低树高。
例如，三层B+树可以存储大约2 1 9 0万个数据段（1 1 7 0×1 1 7 0×1 6 ）。
减少磁盘I/O：树高度越低；查询期间需要更少的磁盘页，从而提高性能。
在叶子节点链表结构中，叶子节点通过指针组合成一个有序的链表；提供高效的范围查询和持续读写。
优点：避免分页/合并的开销并适应数据库的分页（每个页面独立管理）。
2 、磁盘I/O优化，适应数据库页存储的首要需求 InnoDB以页为单位（默认1 6 KB）读写数据。
B+树非叶子节点的纯索引设计，允许在单个页面上放置更多的指针，减少访问非叶子节点所需的I/O数量。
叶子节点存储与磁盘块大小一致的整页数据，以最大限度地提高 I/O 效率。
查询性能稳定 B+树的查询时间复杂度为O(logn)，当数据量增大（如千万到数十亿）时，树高只需要一层（如3 层→4 层），性能下降可以控制。
行锁和并发控制 B+树结构支持行级锁：通过锁定各个叶节点或索引键；避免了全表锁并提高了组合性能。
但要小心不可阻挡的危险。
范围查询和排序有序链表结构允许范围查询（例如WHEREidBETWEEN1 0AND1 00）直接通过上层节点，无需回溯。
3 、相对于其他数据结构的缺点 二叉树/平衡二叉树随着数据量的增加而线性增加（比如一百万条数据大约需要2 0层）；导致频繁的磁盘I/O。
红黑树：平衡，但扇产量低（通常只有2 个分支），树高仍然很高。
B树：非叶子节点存储数据；占据指定空间；降低风扇转速和范围查询性能不如B+树。
4 . 总结 B+树通过以下设计满足数据库需求： 高吞吐量：非叶子节点纯索引；降低树高并减少 I/O。
页面存储适配：叶子节点与磁盘页面对齐，以提高读写性能。
有序链表：提供高效的范围查询和顺序访问。
行锁支持：细粒度的锁控制；协调货币和永生风险。
这些特征是B+树，尤其是大数据这使得它成为并发场景下MySQL索引的理想选择。

图解MySQL索引--B-Tree（B+Tree）

B-Tree（B+Tree）作为MySQL的核心索引结构，通过设计多路平衡搜索树来优化磁盘IO效率，特别适合数据库的增删改查场景。
从结构特点、与二叉树的比较、存储工具的实现以及优化目标四个方面进行讲解： 1 . B-Tree 和 B+Tree 的结构特点。
B-Trees为每个节点添加多个键值和子节点索引，数据可以分布到任意节点。
搜索必须从根节点开始逐层进行，且路径不唯一，大多数IO盘都能找到。
模糊的问题需要把所有的细节都讲一遍，效果较差。
B+ Tree（MySQL默认）数据只存储在叶子节点中，而叶子节点不仅仅存储键值和子索引。
通过降低树的高度，单个节点可以容纳更多的列表项。
叶子节点通过双向链表链接，支持高效的远程搜索（例如WHEREidBETWEEN1 AND1 0只需要在链接的叶子中遍历）。
查询路径是稳定的（始终从根到叶）并且磁盘 IO 时间是可预测的。
2 、为什么选择B+树而不是减法/二叉树？哈希索引限制只允许精确匹配（如=、IN），不能处理随机搜索（如BETWEEN）或排序（ORDY）。
哈希冲突可能会导致性能不佳，并且无法利用索引类型操作来优化方法操作。
哈希表是全内存结构，不能直接满足磁盘存储的索引需求。
二叉树/红黑树的缺陷 树高问题：当数据下降时，二叉树退化为链表。
红黑树虽然是平衡的，但它的高度随着数据量的增加而增加（O(logN)），导致磁盘IO次数增加。
磁盘友好性差：B+Tree将树高压缩到每个多模分支3 -4 层（通常为1 00+），显着减少磁盘访问次数（每个IO节点负载，通常为1 6 KB）。
3 、B+Lamb在MyISAM设备存储中的实现不是集群化的：索引文件（.MYI）和数据文件（.MYD）分离，B+Lamb用行数据索引代替叶子节点。
第二次查找需要：首先在列表中定位指针，然后从文件中读取数据。
InnoDB聚集索引引擎：树叶节点B+主键索引直接存储整个数据行，次叶子节点存储节点的主值（需要查询表）。
自适应哈希索引：自动构建哈希索引来索引最常访问的页面，以加速等效查询（但无法检查，仅影响内存）。
4 .优化建议：使用自增主键减少页面分裂：自增主键保证数据按顺序插入，B+Tree节点叶子从左到右填充，仅在节点满时分裂（且仅分裂运行节点）。
减少数据移动：非自增主键（如UUID）会导致随机插入，经常触发页面拆分并移动大量数据，增加IO开销。
连续数据（自增主键） 插入非连续数据（随机主键） 总结 B+Lamb 通过多路径匹配、数据聚合、链表等设计特性，在磁盘 IO 效率、查询和支持等方面明显优于二叉树结构。
InnoDB聚集索引进一步优化数据存储，同时主键自增通过减少分页保持索引效率分割和运动数据。
通过理解这些原理，您可以更好地设计数据库表结构和查询计划。