索引：索引是帮助数据库高效获取数据的数据结构。

关于索引的误解

• 索引并不是越多越好，索引太多，应用程序的性能可能会受到影响；索引太少，对查询性能又会产生影响。
• 索引最好是初始时添加，后续添加的话，会处理相当大的一部分数据。
• 初始时候让DBA添加，由于DBA往往不了解业务的数据流，往往添加得不够精确

索引的原理

索引的目的在于提高查询效率，本质是通过不断的缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的时间编程顺序的事件，也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。

b+树的查找过程

如图所示，如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。

3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。

MySQL数据库中的索引并非建得越多越好。以下是一些理由说明为什么索引不是越多越有利：

• 1. 存储空间：索引需要占用额外的磁盘空间，每个索引都是对数据表的一部分数据进行排序后单独存储的结构。索引越多，占用的空间越大。
• 2. 写操作性能损耗：每当对表进行INSERT、UPDATE、DELETE操作时，如果涉及索引列，不仅要更新数据表本身，还需要更新相关索引，这会增加写操作的开销，降低写入速度。
• 3. 维护成本：随着数据的变化，索引需要不断地维护和更新以保持其正确性，这会消耗数据库服务器
• 的CPU和I/O资源。
• 4. 读取效率考虑：虽然索引可以提高查询效率，但不是所有查询都能从索引中受益。对于简单的查询或者数据量较小的表，全表扫描可能比使用索引更快。
• 5. 索引选择性：只有在查询中频繁使用，并且具有较高选择性的列上建立索引才有意义。选择性指索引列中不同值的数量与总行数的比例，选择性低的列（如性别字段，通常只有两个值）不适合做索引。
• 6. 过度索引：为不常使用的列或者已经在其他索引中覆盖到的列创建索引是没有必要的，这会导致不必要的资源浪费。

综上所述，设计索引策略时应根据实际业务需求、查询模式、数据规模及更新频率等因素综合考虑，既要确保关键查询能得到有效加速，又要避免因过多索引带来的负面影响。因此，合理优化和选择性地创建索引才是最佳实践