优化以下SQL查询：SELECT * FROM student WHERE class_id = 1 AND score > 80 ORDER BY score DESC LIMIT 10；如何提高查询性能？

1) 【一句话结论】：核心是添加复合索引（class_id, score）并优化SELECT列，利用覆盖索引减少I/O，同时调整索引顺序匹配查询条件顺序，提升查询性能。

2) 【原理/概念讲解】：索引通过B树结构存储列数据，类似图书馆书签，能快速定位满足条件的行。对于范围查询（score > 80）和排序（ORDER BY score DESC），复合索引（多列索引）可同时满足过滤和排序需求，避免全表扫描。若索引列顺序与查询条件顺序一致（class_id在前，score在后），能先过滤class_id=1的行，减少后续处理的数据量。

3) 【对比与适用场景】：

索引类型	定义	特性	使用场景	注意点
普通索引	仅包含索引列的键值	需回表查询（从索引找主键，再查数据行）	单一列查询或排序	多列查询时需多次回表
覆盖索引（复合索引）	索引包含查询所需的所有列（如class_id, score）	无需回表（直接从索引获取数据）	SELECT * 或查询列都在索引中	索引列顺序需匹配查询条件顺序（先过滤列在前）

4) 【示例】：
原SQL：

SELECT * FROM student WHERE class_id = 1 AND score > 80 ORDER BY score DESC LIMIT 10;

优化后（添加复合索引）：

-- 创建复合索引
CREATE INDEX idx_class_score ON student (class_id, score);
-- 优化查询
SELECT * FROM student 
WHERE class_id = 1 AND score > 80 
ORDER BY score DESC 
LIMIT 10;

解释：索引class_id, score先通过class_id过滤class_id=1的行，再通过score过滤score>80，最后直接利用索引排序，避免全表扫描和额外排序。

5) 【面试口播版答案】：
“面试官您好，针对这个查询，核心优化点是添加复合索引并优化SELECT列。原SQL使用SELECT *会扫描所有列，而实际只需要score和class_id等列，可以改用SELECT class_id, score, ...（具体列）来减少I/O。同时，添加复合索引class_id, score，因为查询条件是class_id=1和score>80，且排序字段是score，索引列顺序与查询条件顺序一致，能先过滤class_id=1的行，再通过score过滤，最后直接利用索引排序，避免全表扫描和额外排序。这样能显著提升查询性能。”

6) 【追问清单】：

• 问：为什么选择class_id在前，score在后作为索引顺序？
  回答要点：因为查询条件中先过滤class_id=1，再过滤score>80，索引列顺序与查询条件顺序一致，能提前过滤掉不匹配class_id的行，减少后续处理的数据量。
• 问：如果class_id和score的基数差异很大（如class_id只有2个，score很多），索引顺序是否会影响？
  回答要点：基数小的列（class_id）放在前面，能更早过滤掉大量不匹配的行，减少后续处理的数据量，即使score基数大，也能先通过class_id缩小范围。
• 问：如果数据量很大，还有其他优化方法吗？
  回答要点：可以考虑分区（如按class_id分区）或物化视图（查询频繁时），但当前场景下复合索引和覆盖索引是基础优化。
• 问：为什么不能直接用覆盖索引包含所有列？比如创建索引包含class_id, score, name等。
  回答要点：覆盖索引需索引列包含查询所需的所有列，但包含不相关列（如name）会增加索引大小和存储成本，且查询时可能不需要这些列，反而增加I/O。

7) 【常见坑/雷区】：

• 索引覆盖不全：只创建索引class_id, score，但SELECT *导致需要回表，性能未提升。
• 索引顺序错误：创建索引score, class_id，导致先按score排序再按class_id过滤，增加排序成本。
• 忽略SELECT *的问题：未优化列选择，导致扫描所有列，增加I/O。
• 索引维护成本：过度创建索引会增加写操作开销，需权衡。
• 数据类型不匹配：索引列数据类型与查询条件不一致（如查询score>80，但索引列是字符串类型），导致索引失效。