5

我正在阅读 MySql 索引优化的文档。

我找到了一个设置 --max-seeks-for-key=1000 。我在这里检查了 MySQL 的“服务器系统变量” 。
根据它

“通过将其设置为较低的值（例如，100），您可以强制 MySQL 更喜欢索引而不是表扫描”

.
我从 FULL TABLE SCAN 中了解到的是：

当查询需要访问大部分行时，顺序读取比通过索引更快。即使查询不需要所有行，顺序读取也可以最大限度地减少磁盘寻道。

因此，如果 MySQL 正在执行最小化磁盘搜索的全表扫描，为什么要使用 --max-seeks-for-key=1000 来选择可能增加磁盘搜索的索引扫描。

在文档8.3.1.20 How to Avoid Full Table Scan中，它被提及为避免全扫描的一个步骤： Start mysqld with the --max-seeks-for-key=1000

所以我很想知道 --max-seeks-for-key 是否有任何实际和有意义的用途。

4

1 回答 1

3

好吧，我在这里有一个由 Magento 执行的真实查询，我正在运行 MySQL 5.7

SELECT SQL_NO_CACHE 
  main_table.entity_id
FROM catalog_category_flat_store_2 AS main_table
LEFT JOIN core_url_rewrite AS url_rewrite ON 
  url_rewrite.category_id = main_table.entity_id
  AND url_rewrite.is_system = 1
  AND url_rewrite.store_id = 2
  AND url_rewrite.id_path LIKE 'category/%'
WHERE main_table.include_in_menu = '1'
  AND main_table.is_active = '1'
  AND main_table.path LIKE '1/2/%'
ORDER BY main_table.position ASC

当我设置max_seeks_for_key为670或更低时，查询将在 2 秒内运行。当该值较高（默认非常高）时，查询大约需要6 分钟。

是的，我知道这是一个糟糕的查询。它不是我写的，它是由 Magento 电子商务应用程序框架创建的。

我用EXPLAIN来找出不同之处。我看到max_seeks_for_key它使用core_url_rewrite表的索引的低值。更高的价值不会。

MySQL 5.6确实为同一查询使用了索引，而无需对配置进行任何更改。

额外上下文：该catalog_category_flat_store_2表包含 732 条记录。该表core_url_rewrite有 180 万条记录。该索引是字段（JOIN 字段）的非唯一索引，category_id基数为 571。结果为 629 行。

不要忘记运行ANALYSE TABLE以帮助 MySQL 做出正确的决定。

于 2017-02-14T18:48:09.123 回答