MySql Server系统变量–max-seeking-for-key – 实际例子
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了MySql Server系统变量–max-seeking-for-key – 实际例子，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1809字，纯文字阅读大概需要3分钟。
内容图文
我正在浏览MySql索引优化的文档.
我找到了一个设置–max-seeking-for-key = 1000.I检查了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-seeking-for-key = 1000来优先选择索引扫描,这可能会增加磁盘搜索.
在文档8.3.1.20 How to Avoid Full Table Scan中,它提到了避免全扫描的步骤：使用–max-seeking-for-key = 1000启动mysqld
所以我很想知道是否有任何实际和有意义的使用–max-seeking-for-key.
解决方法:
好吧,我有一个真正的查询在这里由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万条记录.索引是category_id字段(JOIN字段)上的非唯一索引,基数为571.结果为629行.
不要忘记运行ANALYZE TABLE来帮助MySQL做出正确的决定.
内容总结
以上是互联网集市为您收集整理的MySql Server系统变量–max-seeking-for-key – 实际例子全部内容，希望文章能够帮你解决MySql Server系统变量–max-seeking-for-key – 实际例子所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。