SQL数据库执行查询时，表扫描是获取数据的基础操作，当表数据量达到百万甚至千万级别时，全表扫描会消耗大量磁盘IO和CPU资源，导致查询响应缓慢。优化表扫描的核心思路是减少需要扫描的数据量，同时降低数据读取的额外开销，索引覆盖和条件下推就是两种非常有效的优化手段。
索引覆盖的原理与实现
索引覆盖指的是查询所需要的所有字段都包含在某个索引的叶子节点中，数据库不需要回表查询聚簇索引获取完整行数据，直接通过索引就可以返回查询结果。
为什么索引覆盖能优化表扫描
普通的非聚簇索引叶子节点只存储索引列和对应的主键值，如果查询的字段不在索引中，数据库就需要根据主键值去聚簇索引中查找完整的行数据，这个操作就是回表。回表会产生额外的磁盘IO，当查询数据量较大时，IO开销会显著上升。而索引覆盖可以完全避免回表，直接通过索引完成查询，大幅减少IO次数。
索引覆盖的实现示例
假设我们有一张用户表，结构如下：
-- 创建用户表
CREATE TABLE user_info (
id INT PRIMARY KEY AUTO_INCREMENT,
user_name VARCHAR(50) NOT NULL,
age INT NOT NULL,
email VARCHAR(100),
create_time DATETIME
);
-- 为user_name和age创建联合索引
CREATE INDEX idx_user_name_age ON user_info(user_name, age);
如果执行以下查询：
SELECT user_name, age FROM user_info WHERE user_name = '张三';
查询的字段user_name和age都在联合索引idx_user_name_age的叶子节点中，数据库只需要扫描这个索引就可以返回结果，不需要回表，这就是典型的索引覆盖场景。
如果查询语句改成：
SELECT user_name, age, email FROM user_info WHERE user_name = '张三';
因为email字段不在索引中，数据库需要回表查询email的值，就无法实现索引覆盖。
条件下推的原理与实现
条件下推指的是将查询中的过滤条件尽可能提前到数据扫描的早期阶段执行，提前过滤掉不符合条件的数据，减少后续处理的数据量。
条件下推的常见场景
条件下推最常见于多表连接查询和子查询场景中。比如在连接查询时，数据库优化器会将WHERE子句中的过滤条件下推到各个表扫描的阶段，而不是先完成所有表的连接再过滤数据。
条件下推的示例
假设我们有两张表，用户表user_info和订单表order_info，结构如下：
-- 创建订单表
CREATE TABLE order_info (
order_id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL,
order_amount DECIMAL(10,2) NOT NULL,
order_status TINYINT NOT NULL,
order_time DATETIME
);
-- 为user_id创建索引
CREATE INDEX idx_user_id ON order_info(user_id);
执行以下连接查询：
SELECT u.user_name, o.order_amount FROM user_info u JOIN order_info o ON u.id = o.user_id WHERE u.age > 20 AND o.order_status = 1;
优化器会将u.age > 20条件下推到user_info表的扫描阶段，先过滤出年龄大于20的用户，再将o.order_status = 1条件下推到order_info表的扫描阶段，先过滤出状态为1的订单，完成两个表的过滤后再进行连接操作，这样需要处理的数据量会远小于先连接再过滤的情况。
索引覆盖与条件下推的结合使用
在实际优化中，两种方式可以结合使用，进一步提升查询性能。比如我们可以先通过条件下推提前过滤数据，再为过滤后的查询设计合适的覆盖索引，避免回表开销。
还是以上面的用户表和订单表为例，如果我们需要查询年龄大于20的用户的有效订单金额，查询语句如下：
SELECT u.user_name, o.order_amount FROM user_info u JOIN order_info o ON u.id = o.user_id WHERE u.age > 20 AND o.order_status = 1;
我们可以先为user_info表创建idx_age_id_user_name索引，包含age、id、user_name三个字段，这样扫描user_info表时，既可以通过age > 20条件下推过滤数据，又可以实现索引覆盖，不需要回表获取user_name。同时order_info表的idx_user_id索引可以结合order_status = 1条件下推，提前过滤订单数据，两者结合可以最大程度减少表扫描的数据量和IO开销。
注意事项
- 索引覆盖需要根据实际查询的字段设计索引，避免创建过多冗余索引，否则会影响写入性能。
- 条件下推是数据库优化器的自动行为，但部分复杂查询可能无法触发，此时可以通过调整查询语句结构或者提示优化器的方式手动优化。
- 不是所有场景都适合使用索引覆盖，如果查询需要返回大量字段，创建包含所有字段的索引会占用大量存储空间，反而得不偿失。
合理的表扫描优化需要结合业务查询场景，分析查询执行计划，针对性地使用索引覆盖和条件下推，才能在不影响其他操作性能的前提下，最大化提升查询效率。