如何优化耗时近2分钟的当月数据统计SQL查询？

原查询慢的核心原因是在addondatetime字段上使用了EXTRACT函数，这会导致数据库无法利用该字段上的索引，被迫执行全表扫描——数据量越大，耗时就越长。下面是几个高效的优化方案：

1. 改写为范围查询（核心优化） #

把基于函数的条件改成直接对addondatetime做范围判断，让数据库能利用索引快速筛选数据。不同数据库的写法略有差异：

PostgreSQL 版本 #

SELECT count(*)
FROM table
WHERE addondatetime >= date_trunc('month', current_date)
  AND addondatetime < date_trunc('month', current_date) + INTERVAL '1 month';

MySQL 版本 #

SELECT count(*)
FROM table
WHERE addondatetime >= DATE_FORMAT(CURDATE(), '%Y-%m-01')
  AND addondatetime < DATE_ADD(DATE_FORMAT(CURDATE(), '%Y-%m-01'), INTERVAL 1 MONTH);

SQL Server 版本 #

SELECT count(*)
FROM table
WHERE addondatetime >= DATEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), 1)
  AND addondatetime < DATEADD(MONTH, 1, DATEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), 1));

这种写法的逻辑是：筛选出所有大于等于当月第一天、且小于下月第一天的数据，完全等价于原查询的当月统计，但能触发索引扫描。

2. 确保addondatetime字段存在索引 #

如果还没给addondatetime建索引，赶紧创建一个B-tree索引——这是范围查询高效执行的前提：

CREATE INDEX idx_table_addondatetime ON table(addondatetime);

3. 可选：使用覆盖索引（针对超大表） #

如果你的表字段非常多、数据量极大，可以创建仅包含addondatetime的覆盖索引。这种索引体积更小，数据库扫描起来更快：

CREATE INDEX idx_table_addondatetime_covering ON table(addondatetime);

（注：多数数据库中，单字段的普通索引本身就可以作为覆盖索引用于count(*)查询，此步骤可根据实际情况选择）

内容的提问来源于stack exchange，提问作者Fyeqa Akram