为何COUNT查询使用索引仍无性能提升？问题排查与优化

从EXPLAIN ANALYZE输出和表结构可定位出几个核心问题：

1. 数据类型不匹配导致索引无法精准定位 #

表中school_id为varchar(191)类型，但查询条件使用的是数字3451，MySQL会触发隐式类型转换。这会让数据库无法通过索引直接定位匹配行，只能先扫描整个idx_school_id索引（实际扫描197797行），再在内存中过滤出仅28条符合条件的数据，完全浪费了索引的快速定位能力。

2. 表统计信息过时 #

执行计划预估匹配行数为21745，但实际仅28行，说明表的统计信息不准确，优化器无法判断最优执行路径，错误选择了全索引扫描而非精准查找。

3. 未考虑软删除过滤（可选场景） #

若业务中is_deleted为软删除标记，且查询默认统计未删除数据，现有单键索引无法提前过滤已删除行，会额外扫描大量无效数据。

1. 修正查询语句的类型匹配 #

将查询条件改为字符串格式，匹配school_id的varchar类型，让索引直接精准定位：

EXPLAIN ANALYZE
SELECT COUNT(*) AS total
FROM galleries
WHERE school_id = '3451';

2. 更新表统计信息 #

强制MySQL更新表的统计数据，让优化器生成更准确的执行计划：

ANALYZE TABLE galleries;

3. 优化索引（针对软删除场景） #

若业务需过滤已删除数据，创建联合索引提前过滤无效行，减少扫描量：

CREATE INDEX idx_school_id_is_deleted ON galleries(school_id, is_deleted);

对应查询语句补充软删除过滤条件：

SELECT COUNT(*) AS total
FROM galleries
WHERE school_id = '3451' AND is_deleted IS NULL;

4. 调整COUNT语法（可选） #

对于InnoDB引擎，COUNT(1)在覆盖索引场景下性能略优于COUNT(*)，可尝试替换：

SELECT COUNT(1) AS total
FROM galleries
WHERE school_id = '3451';

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