基础查询未利用number_int索引的性能优化咨询

1. 换用更高效的查询逻辑 #

你要找的是number_int在(1999999, 2999999)区间内的最大值，完全不需要先筛选再排序取limit 1。直接使用MAX()聚合函数，数据库可直接利用索引快速定位目标值，彻底绕开全表扫描和排序步骤：

SELECT MAX(number_int) FROM block WHERE number_int > 1999999 AND number_int < 2999999;

2. 强制数据库使用索引 #

如果优化器仍选择全表扫描，可以通过索引提示强制指定使用目标索引。不同数据库语法略有差异，以下是两种常见数据库的写法：

• PostgreSQL 版本：

EXPLAIN ANALYZE SELECT number_int FROM block 
WHERE number_int > 1999999 AND number_int < 2999999 
ORDER BY number_int DESC LIMIT 1
USING INDEX number_int_index;

• MySQL 版本：

EXPLAIN ANALYZE SELECT number_int FROM block 
FORCE INDEX (number_int_index)
WHERE number_int > 1999999 AND number_int < 2999999 
ORDER BY number_int DESC LIMIT 1;

3. 更新表统计信息 #

从查询计划可以看到，预估行数仅1000，但实际扫描了19万多行，这说明数据库的统计信息严重过时，导致优化器误判执行成本。执行以下命令更新统计信息：

• PostgreSQL：ANALYZE block;
• MySQL：ANALYZE TABLE block;

4. 检查索引有效性 #

索引可能因异常情况失效，先确认索引状态：

• PostgreSQL：

SELECT indexname, indisvalid FROM pg_indexes WHERE tablename = 'block' AND indexname = 'number_int_index';

若返回的indisvalid为f，重建索引：

DROP INDEX number_int_index ON block;
CREATE INDEX number_int_index ON block (number_int);

• MySQL：

SHOW INDEX FROM block WHERE Key_name = 'number_int_index';

若索引状态异常，同样执行删建索引操作。

5. 分布式场景额外优化 #

查询计划中出现Remote Filter，说明该表可能是远程表或分库分表结构，需额外注意：

• 确保所有远程节点/分片上都已创建number_int_index
• 调整分片键设计，让过滤条件能命中尽可能少的分片，缩小扫描范围

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