在mysql查询中使用force index子句可能有哪些缺点?或者,什么时候不应该用?

cvxl0en2  于 2021-06-15  发布在  Mysql
关注(0)|答案(1)|浏览(567)

关闭。这个问题需要更加突出重点。它目前不接受答案。
**想改进这个问题吗?**通过编辑这篇文章更新这个问题,使它只关注一个问题。

9小时前关门了。
改进这个问题
示例- SELECT * FROM table_name FORCE INDEX (index_list) WHERE condition; 在不使用force索引的情况下,mysql的查询优化程序决定可以在给定查询中使用的索引的最佳候选。但是如果它发现它仍然需要扫描行的主要百分比,那么它将跳过索引并继续进行完全扫描。因此,它可以使用也可以不使用任何索引。
因此,假设查询优化程序有一个更好的索引候选,它可以使用(甚至不使用任何索引)更快地计算查询。但是通过强制索引,我可能会减慢查询速度。
因此,为了确保我不犯这个错误,也不过度使用资源(如果是在强制索引的情况下发生的话),我应该注意什么?

pbossiut

pbossiut1#

为了确保我不犯这个错误[…]我应该注意什么?
为什么不让查询计划者来做这项艰苦的工作呢?
数据库供应商在开发高效和微调的软件方面投入了巨大的精力。在绝大多数情况下,查询规划器在为查询构建理想的执行计划方面做出了正确的决策。执行完全扫描而不是昂贵的索引查找通常是这些基于成本的优化之一。
根据我的经验,很少有情况下确实需要索引提示。此外,索引提示以某种方式产生了技术债务,因为当数据或结构将来发生变化时,它们可能会对查询的性能产生负面影响。那应该是你最后的选择,而不是第一个选择。
注意:有一点不容忽视,那就是优化器需要准确的信息来做出正确的决策。一定要跑 ANALYZE TABLE 在你table上的固定底座上。

相关问题