Mysql 综合指数的管理费用

我有很多表，其中有外键索引，以及包含这些外键的聚集索引。例如，我有一个如下表：

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\u owner

，通常使用

idx\u owner

的未来查询将只使用

idx\u owner\u status

，因为它将

owner

作为索引中的第一列

是否值得保留

idx\u所有者

？即使MySQL只使用部分索引，是否还有额外的I/O开销要使用

idx\u owner\u status

---

编辑：我只对InnoDB在索引方面的行为方式感兴趣。

简短回答 删除较短的索引

Long Anwser 需要考虑的事项：

放下它：

• 每个

  索引都是驻留在磁盘上的一个单独的BTree，因此需要占用空间

• 当

  插入新行或
  更新
  修改索引列时，每个
  索引都会更新（早晚）。这会占用一些CPU、I/O和缓冲池空间用于“更改缓冲区”

• 较短索引的任何功能性使用（与性能相反）都可以由较长索引执行

不要放弃它：

• 较长的指数比较短的指数更大。因此，它的可缓存性较低。因此（在极端情况下）使用较大的索引代替较短的索引可能会导致更多的I/O。这种情况会加剧：

  索引（int，varchar255）

最后一项真正覆盖其他项的情况非常罕见

奖金

“覆盖”索引包含

SELECT

中提到的所有列。例如：

SELECT status FROM tbl WHERE owner = 123;

这将只触及

索引（所有者、状态）

的BTree，因此速度明显快于

SELECT status, foo FROM tbl WHERE owner = 123;

如果您确实需要更快的查询，那么用

索引（所有者、状态、foo）

替换这两个索引

主键主键

还有一个花絮。。。在InnoDB中，

主键

的列隐式附加到每个次键。所以，这三个例子真的很有趣

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

在和上的我的博客中进行更多讨论