为什么我的数据库查询很慢，索引创建后却没有生效？

Question

索引创建后查询依然缓慢，可能源于多个常见问题。首先，确认索引是否被实际使用，通过执行计划检查优化器行为。如果优化器未选择索引，可能是统计信息过时或查询条件不符合索引结构（如使用函数包裹列、类型不匹配等）。其次，复合索引的字段顺序不当也会导致失效，确保查询过滤条件与索引定义顺序一致。此外，高基数列上的索引可能因选择性不足而被优化器忽略。最后，大量数据变更后，索引可能出现碎片化，影响性能。定期维护和更新统计信息是关键。总结来说，查询慢不仅与索引创建有关，还需综合分析优化器决策、数据分布及索引设计合理性。

Answer 1

1. 索引使用情况检查

索引创建后查询依然缓慢，首先需要确认索引是否被实际使用。以下是具体步骤：

1. 通过执行计划（Execution Plan）检查优化器的行为。
2. 如果优化器未选择索引，可能是统计信息过时或查询条件不符合索引结构。
3. 检查是否存在函数包裹列、类型不匹配等问题。

例如，以下SQL语句可以查看执行计划：

EXPLAIN SELECT * FROM table_name WHERE column_name = 'value';

2. 复合索引设计分析

复合索引的字段顺序不当可能导致索引失效。合理的复合索引设计应遵循以下原则：

• 确保查询过滤条件与索引定义顺序一致。
• 将过滤性较强的字段放在索引的前面。
• 避免在索引字段上使用函数或进行类型转换。

以下是一个复合索引的设计示例：

CREATE INDEX idx_composite ON table_name (column1, column2);

3. 高基数列索引的选择性问题

高基数列上的索引可能因选择性不足而被优化器忽略。解决方法包括：

问题	解决方案
选择性不足	评估是否需要为该列单独创建索引。
数据分布不均	结合直方图分析数据分布情况。

通过以下SQL语句生成直方图：

ANALYZE TABLE table_name COMPUTE STATISTICS FOR COLUMNS column_name;

4. 索引碎片化及维护

大量数据变更后，索引可能出现碎片化，影响性能。定期维护和更新统计信息是关键。以下是维护步骤：

ALTER INDEX index_name REBUILD;

同时，可以通过以下流程图了解索引维护的整体过程：

graph TD;
    A[开始] --> B{索引是否有效?};
    B --否--> C[检查执行计划];
    C --> D{是否需要重建?};
    D --是--> E[ALTER INDEX ... REBUILD];
    D --否--> F[更新统计信息];
    F --> G[完成];