SQL 优化问题，有看下吗

Question

select a.PLANSNKEY,a.PlanQty from MES_APSPLANSN_R a where OrgId=3002 and PlanKey=1384619 AND ENABLE='Y'
ORDER BY SN,PLANSNKEY

只要把这个条件带上就很慢 and PlanKey=1384619，不带这个条件就是马上能查出来， 也单独加了索引，给这个3个字段也建了索引
都没用。
谁能遇到这种的情况.

Answer 1

该回答引用自GPT-3.5, 由博主 GISer Liu 编写：

问题分析

用户遇到的问题是在执行SQL查询时，当包含特定条件and PlanKey=1384619时，查询速度变得非常慢，而不包含这个条件时查询速度很快。用户已经尝试为相关字段建立索引，但问题依然存在。

关键点

1. 查询条件：OrgId=3002, PlanKey=1384619, ENABLE='Y'
2. 索引情况：用户已经为OrgId, PlanKey, ENABLE字段建立了索引
3. 性能问题：特定条件PlanKey=1384619导致查询变慢

解决方案

1. 检查索引使用情况

首先，我们需要检查在包含PlanKey=1384619条件时，数据库是否正确使用了索引。可以通过执行EXPLAIN或EXPLAIN PLAN来查看查询计划。

EXPLAIN SELECT a.PLANSNKEY, a.PlanQty 
FROM MES_APSPLANSN_R a 
WHERE OrgId=3002 
AND PlanKey=1384619 
AND ENABLE='Y' 
ORDER BY SN, PLANSNKEY;

2. 索引优化

如果发现索引没有被正确使用，可以考虑以下几种优化方法：

• 复合索引：尝试创建复合索引，覆盖查询中的所有条件字段。

CREATE INDEX idx_mes_apsplansn_r_composite 
ON MES_APSPLANSN_R (OrgId, PlanKey, ENABLE, SN, PLANSNKEY);

• 索引选择性：检查PlanKey字段的数据分布，确保其具有良好的选择性。如果PlanKey的值分布非常不均匀，可能会导致索引效果不佳。

3. 数据量和统计信息

• 数据量：检查表MES_APSPLANSN_R的数据量，如果数据量非常大，可能需要更复杂的索引策略或分区策略。
• 统计信息：确保数据库的统计信息是最新的，这有助于优化器做出更好的决策。

ANALYZE TABLE MES_APSPLANSN_R;

4. 查询重写

如果上述方法仍然无效，可以尝试重写查询，例如使用子查询或临时表来优化查询性能。

SELECT a.PLANSNKEY, a.PlanQty 
FROM (
    SELECT PLANSNKEY, PlanQty 
    FROM MES_APSPLANSN_R 
    WHERE OrgId=3002 
    AND PlanKey=1384619 
    AND ENABLE='Y'
) a 
ORDER BY SN, PLANSNKEY;

总结

通过上述步骤，可以逐步排查和解决SQL查询性能问题。首先检查索引使用情况，然后优化索引，更新统计信息，最后考虑查询重写。每一步都需要详细分析和测试，确保找到最合适的解决方案。

如果该回答解决了您的问题，请采纳！如果没有，请私信联系或评论您的疑惑