在使用关系型数据库进行数据检索时，我们常常会遇到一个颇为困惑的问题：为何某些情况下即便已有适当的索引，系统仍然选择了全表扫描？这不仅让人疑惑，还可能导致性能问题，特别是在处理大量数据时。在本文中，我们将深入探讨造成这一现象的五种隐秘原因，以帮助您更好地理解和优化数据库查询。
1. 数据统计信息不准确
最常见也是最容易被忽视的原因就是统计信息的不准确。许多DBMS（数据库管理系统）依赖于统计信息来决定执行计划。如果这些信息过时或不正确，优化器可能会错误地判断全表扫描比使用索引更高效。因此，定期更新统计信息是至关重要的一步。例如，在Oracle中，可以通过DBMS_STATS.GATHER_TABLE_STATS命令来更新特定表的统计信息。
2. 查询条件与索引不匹配
另一个导致全表扫描的重要因素是查询条件与可用索引之间的不匹配。例如，如果您的WHERE子句中包含了多个字段，但只有单个字段上有索引，那么即便该字段有值，也无法有效利用这个指数。这时候，即使存在其他列上的复合索引，由于缺乏必要的信息，全表扫描仍然会发生。
3. 使用了函数或表达式
如果在WHERE子句中对带有索引的列应用了函数或表达式，例如WHERE YEAR(order_date) = 2023，那么就无法使用到原本可以利用的B树或者哈希等类型.Indexes，因为这样做改变了原始的数据格式，从而失去了基于该列建立好的任何有效性。为了避免这种情况，应尽量避免在过滤条件中使用函数，而是直接比较列值。
4. 小结果集和低基数情况
在某些情况下，当您查询的是小结果集且基数较低时，优化器可能会认为进行全表扫描更加高效。这通常发生在非常小的数据集中，比如说一张仅含几条记录的小用户权限控制列表。当对于目标行数量极少时，全表扫描甚至比访问复杂结构化的数据更具优势，这是一种取舍，因此要根据具体情况来权衡。
5. 索引用法限制
有些情况下即使存在很好的设计原则，但由于业务逻辑、权限设置或者其他约束，使得实际使用中的某些组合不能利用已建好的索引。例如，在MySQL中，如果你同时进行了OR操作，并且涉及到了多个不同字段，此时所需满足Index Condition Pushdown（ICP）的规则也可能阻止有效利用已有的index。从而转向了只完成简单快速但代价高昂的全表扫描。
这五个方面只是冰山一角，要真正掌握并运用好这些知识，需要不断实验与实践。而我们希望，通过本文能够帮助大家识别出潜藏的问题并采取相应措施，提高查询效率，从而提升整体的数据处理能力！
