MySql Server 系统变量 --max-seeks-for-key - 实例

Question

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

我找到了一个设置--max-seeks-for-key=1000。我检查了MySQL的“服务器系统变量”here .
据此

"By setting this to a low value (say, 100), you can force MySQL to prefer indexes instead of table scans"

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

When a query needs to access most of the rows, reading sequentially is faster than working through an index. Sequential reads minimize disk seeks, even if not all the rows are needed for the query.

因此，如果 MySQL 正在执行可最大限度减少磁盘寻道的全表扫描，为什么要使用 --max-seeks-for-key=1000 来更喜欢可能增加磁盘寻道的索引扫描。

在文档中 8.3.1.20 How to Avoid Full Table Scan提到它作为避免全扫描的步骤:使用 --max-seeks-for-key=1000

启动 mysqld

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

Answer 1

好吧，我这里有一个由 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 表的索引。它没有更高的值(value)。

MySQL 5.6 确实在不对配置进行任何更改的情况下为同一查询使用索引。

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

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