mysql – 复合索引的开销

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了mysql – 复合索引的开销，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1628字，纯文字阅读大概需要3分钟。

内容图文

我有很多表,我有外键索引,以及包含这些外键的聚簇索引.例如,我有一个如下表：

TABLE: Item
------------------------
id       PRIMARY KEY
owner    FOREIGN KEY
status

... many more columns

MySQL为主键和外键生成索引,但有时,我想提高查询性能,因此我将创建聚簇索引或覆盖索引.这导致索引具有重叠列.

INDEXES ON: Item
------------------------
idx_owner (owner)
idx_owner_status (owner, status)

如果我删除了idx_owner,那么通常使用idx_owner的未来查询只会使用idx_owner_status,因为它拥有者作为索引中的第一列.

是否值得保持idx_owner？使用idx_owner_status是否还有额外的I / O开销,即使MySQL只使用部分索引？

编辑：我真的只对InnoDB关于索引的行为感兴趣.

解决方法:

简答
删除较短的索引.

Long Anwser
需要考虑的事项：

算了吧：

>每个INDEX都是一个独立的BTree,驻留在磁盘上,因此占用空间.
>当您插入新行或UPDATE修改索引列时,每个INDEX都会更新(迟早).这需要一些CPU和I / O以及buffer_pool空间用于’更改缓冲区’.
>较短索引的任何功能用途(与性能相反)都可以由较长的索引执行.

不要掉下来：

>较长的索引比较短的索引更笨重.所以它的可缓存性较差.因此(在极端情况下)使用较大的一个代替较短的一个可能会导致更多的I / O.一个加剧了这种情况的案例：INDEX(int,varchar255).

最后一项真的会覆盖其他项目是非常罕见的.

奖金

“覆盖”索引是包含SELECT中提到的所有列的索引.例如：

SELECT status FROM tbl WHERE owner = 123;

这将仅触及INDEX(所有者,状态)的BTree,因此明显快于

SELECT status, foo FROM tbl WHERE owner = 123;

如果您真的需要更快的查询,那么用INDEX(所有者,状态,foo)替换两个索引.

辅助密钥中的PK

还有一个小问题…在InnoDB中,PRIMARY KEY的列隐式附加到每个辅助密钥.所以,这三个例子确实如此

INDEX(owner, id)
INDEX(owner, status, id)
INDEX(owner, status, foo, id)

我在composite indexes和index cookbook的博客中进行了更多讨论.

内容总结

以上是互联网集市为您收集整理的mysql – 复合索引的开销全部内容，希望文章能够帮你解决mysql – 复合索引的开销所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端