MySQL—索引_生产环境下使用optimize table命令

最新推荐文章于 2025-03-22 21:55:00 发布

2501_90256133

最新推荐文章于 2025-03-22 21:55:00 发布

阅读量876

点赞数 30

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/2501_90256133/article/details/145218055

版权

缺点：

占用存储空间：索引需要占用额外的存储空间，因为它们本身也是数据结构。对于大型数据库，索引可能占用相当大的空间。
插入、更新和删除操作变慢：当对表中的数据进行插入、更新或删除操作时，数据库需要同时更新相关索引。这会导致这些操作的速度变慢，因为每次执行这些操作时，都需要维护索引结构。
索引管理和维护开销：创建和维护索引需要额外的计算资源和时间。在数据库中添加或修改索引时，需要进行索引重建，这会消耗大量的计算资源。此外，索引的选择和调优需要专业知识，以确保数据库性能得到优化。

总之，索引是一种在查询速度和数据修改速度之间进行权衡的技术。在选择是否使用索引时，需要根据具体应用场景和需求进行评估。在查询密集型应用中，索引往往非常有益；而在数据更新频繁的场景中，索引可能导致性能下降。因此，在创建和使用索引时，需要充分考虑它们的优缺点。

MySQL索引类型

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n8ixZan9-1691570962605)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230730204209557.png)]$

索引底层实现? 为什么使用B+树, 而不是B树, BST, AVL, 红黑树等等?

索引的底层实现通常使用树型数据结构。这是因为树型数据结构在搜索、插入、删除等操作中具有较高的效率。主流的数据库系统（如 MySQL、Oracle、SQL Server 等）主要使用 B-Tree（B 树）或其变种 B+树，作为索引的底层数据结构。下面我们来探讨为什么使用 B+树，而不是其他树型数据结构（如 B 树、BST、AVL、红黑树等）。

B+树相较于B树的优点：

B+树的所有叶子节点都存储了索引信息，并且通过指针相互连接，便于进行范围查找。而 B 树只有部分节点存储索引信息，范围查找效率较低。
B+树的内部节点只存储键值，不存储实际数据，这使得每个内部节点可以存储更多的键值，从而降低了树的高度。相比之下，B 树的每个节点都存储了实际数据，占用更多空间，树的高度可能更高。
B+树的查询性能更稳定，因为所有查询都需要遍历到叶子节点。而在 B 树中，查询性能取决于数据所在的节点层级，可能导致性能波动。
叶子节点（最底部的节点）才会存放实际数据（索引+记录），非叶子节点只会存放索引；
所有索引都会在叶子节点出现，叶子节点之间构成一个有序链表；
非叶子节点的索引也会同时存在在子节点中，并且是在子节点中所有索引的最大（或最小）。
非叶子节点中有多少个子节点，就有多少个索引；

B+树相较于BST、AVL、红黑树等平衡二叉查找树的优点：

B+树是多路平衡查找树，每个节点可以有多个孩子，而平衡二叉查找树每个节点只有两个孩子。多路查找树可以减少树的高度，从而降低磁盘 I/O 操作次数，提高查询速度。
B+树具有更好的磁盘空间利用率。在数据库系统中，读取磁盘数据的最小单位是页（Page），B+树的节点大小通常设定为页的大小。这样，每次磁盘 I/O 操作可以将一个完整的 B+树节点加载到内存中。而 BST、AVL、红黑树等平衡二叉查找树的节点大小通常远小于页的大小，导致每次磁盘 I/O 操作无法充分利用磁盘空间，降低了空间利用率。
平衡二叉查找树在插入和删除操作时，需要进行旋转操作来维护平衡。在数据库系统中，旋转操作可能导致大量的磁盘 I/O 操作，降低性能。而 B+树在插入和删除操作时，只需要分裂和合并节点，不需要进行旋转操作，性能更高。

综上所述，B+树作为数据库索引的底层实现，相较于其他树型数据结构具有较高的查询效率、更好的磁盘空间利用率和更稳定的性能。这些优点使得 B+树成为数据库领域中主流的索引数据结构。