select id, col1,col2,col3,seq from `table` order by seq asc
我已经在'seq'上创建了索引，但是我发现它在选择时没有使用索引和使用文件排序，因为col1可能会保存一些大的数据，所以我不想在这个表中创建覆盖索引，所以有一些解决方案来优化这个sql或表或索引，谢谢，我的英语不好😂😂😂
dxxyhpgq1#
SQL查询优化器显然估计了使用索引的成本，并得出结论，最好只进行表扫描并对结果进行文件排序。使用非覆盖索引会产生额外的开销。它会按排序顺序读取索引，但随后必须取消引用主键以获取该行未覆盖的其他列。打个比方，这就像阅读一本书，在后面的索引中按字母顺序查找每个单词，然后翻回相应的页面，一次一个单词。这很耗时，但这是一种按关键词顺序阅读书的方法。也就是说，文件排序也有开销。查询引擎必须收集匹配的行，并手动对它们进行排序，可能会使用临时文件。如果行数很大，这将是非常昂贵的。您还没有用行数来描述表的大小。如果要测试的表的行数较少，优化程序可能认为执行文件排序的速度足够快，因此没有必要按索引读取行。使用较大的表进行测试可能会给予与优化程序不同的结果。在大多数情况下，查询优化器都会做出正确的选择。但它也不是绝对正确的。如果你认为在这种情况下，强制它使用索引更好，你可以使用FORCE INDEX hint让它相信表扫描的开销是惊人的。然后，如果索引是可用的，它会首选索引。
select id, col1,col2,col3,seq from `table` FORCE INDEX(seq) order by seq asc
1条答案
按热度按时间dxxyhpgq1#
SQL查询优化器显然估计了使用索引的成本，并得出结论，最好只进行表扫描并对结果进行文件排序。
使用非覆盖索引会产生额外的开销。它会按排序顺序读取索引，但随后必须取消引用主键以获取该行未覆盖的其他列。
打个比方，这就像阅读一本书，在后面的索引中按字母顺序查找每个单词，然后翻回相应的页面，一次一个单词。这很耗时，但这是一种按关键词顺序阅读书的方法。
也就是说，文件排序也有开销。查询引擎必须收集匹配的行，并手动对它们进行排序，可能会使用临时文件。如果行数很大，这将是非常昂贵的。您还没有用行数来描述表的大小。
如果要测试的表的行数较少，优化程序可能认为执行文件排序的速度足够快，因此没有必要按索引读取行。
使用较大的表进行测试可能会给予与优化程序不同的结果。
在大多数情况下，查询优化器都会做出正确的选择。但它也不是绝对正确的。如果你认为在这种情况下，强制它使用索引更好，你可以使用FORCE INDEX hint让它相信表扫描的开销是惊人的。然后，如果索引是可用的，它会首选索引。