1

在过去的几个月里，我们将一些表从 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 索引，当基于 SELECT where BillsofLading='a' 更新记录时，由于索引基于ID?

在此先感谢您帮助这里的逻辑！

4

2 回答 2

1

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

据我了解，InnoDB 在创建这两个二级索引时也使用主键。

这是正确的，但它并不意味着你认为它意味着什么。

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

于 2015-03-11T22:22:45.743 回答
0

您是否严重减少了 key_buffer_size 并将 innodb_buffer_pool_size 设置为可用 RAM 的 70% 左右？

MyISAM 和 InnoDB 之间存在许多细微差别。此答案中有太多无法列出的内容，您所说的任何内容都没有让人想起任何特定问题。我建议您查看将 MyISAM 转换为 InnoDB以查看可能导致问题的原因。

于 2015-03-12T02:36:33.953 回答