mysql - Innodb、聚集索引和 slow_query_log - 受到主键的伤害？

Question

在过去的几个月里，我们将一些表从 MYiSAM 迁移到了 InnoDB。理论上，我们这样做是为了行锁定优势，因为我们正在通过多个网络抓取实例更新单个行。我现在在我的 slow_query_log (10s) 中建立了数以万计的 slow_queries。以及大量的全表扫描。我对一行进行非常简单的更新(更新 4 或 5 列)需要 28 秒。 (我们的 i/o 和效率非常好，失败/中止的尝试非常低 < 0.5%)

我们更新最多的两张表的主键是ID(int 11)。在 InnoDB 中，主键是一个聚集键，因此被写入磁盘以 ID 的顺序索引。但是我们两个最重要的记录标识列是 BillsofLading 和 Container(均为 varchar22)。我们的大多数 DML 查询都基于这两列查找记录。我们还有关于 BillsofLading 和 container. 的索引按照我的理解，InnoDB 在创建这两个二级索引时也使用了主键。

所以，我可以有一个记录 ID=1，并且 BillsofLading='z'，另一个记录 ID=9 并且BillsofLading='a'。使用 InnoDB 索引，当基于 BillsofLading='a' 的 SELECT 更新记录时，我是否仍然需要进行全面扫描才能找到 'a'，因为索引基于 编号?

在此先感谢您帮助解决此处的逻辑问题!

Answer 1

不，假设 MySQL 选择使用您的 BillsofLading 索引，您的示例不需要完全扫描。你说

The way I understand it, InnoDB also uses the primary key when creating these two secondary indexes.

这是正确的，但并不代表你认为的意思。

InnoDB 的主键 (PK) 就像人类的行号。这是 InnoDB 唯一标识行的唯一方法。因此，二级索引的作用是将目标列的每个值映射到与该值匹配的所有 PK(即行号)。因此，MySQL 可以快速跳转到您关心的 BillsofLading，然后只扫描那些行 (PK) 以找到您想要的行。