能，位图索引在GROUP BY中仅对低基数列且作为前导列时生效，Oracle 19c优化器在统计准确下可触发BITMAP INDEX SINGLE VALUE扫描，配合聚合函数效果明显。
位图索引在GROUP BY中是否真能生效？
能，但仅限于低基数列（如 status、gender、is_active），且必须出现在 GROUP BY 子句最左侧或作为复合索引的前导列。Oracle 19c 的优化器在统计信息准确的前提下，会对这类列的 GROUP BY 自动考虑位图索引扫描（BITMAP CONVERSION TO ROWIDS + BITMAP INDEX SINGLE VALUE），尤其当配合 COUNT(*)、COUNT(column) 或 SUM 等聚合时效果明显。
常见错误现象：
– 对 user_id 这类高基数列建位图索引，不仅无效，还可能引发 DML 阻塞；
– 在 GROUP BY dept_id, region_id 中只对 region_id 建位图索引，但 dept_id 未索引且基数高，优化器大概率弃用该索引；
– 表上存在大量并发 DML，位图索引因锁粒度问题反而拖慢整体吞吐。
如何验证位图索引是否被 GROUP BY 实际使用？
不能只看 EXPLAIN PLAN 是否出现索引名，关键要看执行计划中是否有 BITMAP CONVERSION 操作符和真实的 A-Rows 接近 E-Rows。建议按顺序检查：
- 执行
EXPLAIN PLAN FOR SELECT COUNT(*), status FROM orders GROUP BY status;，再查SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); - 确认计划中出现
BITMAP INDEX RANGE SCAN或SINGLE VALUE，而非全表扫描（TABLE ACCESS FULL） - 在真实执行时启用 SQL Monitor：
SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(sql_id => 'xxx', type => 'TEXT')，观察Activity列是否显示大量bitmap index access - 对比禁用位图索引后的逻辑读：
ALTER INDEX idx_status_bit DISABLE;再跑相同语句，看consistent gets是否显著上升
位图索引 + GROUP BY 的典型陷阱
Oracle 19c 虽增强位图索引并发能力（如改进的位图段锁定），但以下场景仍极易翻车：
- 表上有频繁的
INSERT/UPDATE（尤其是更新位图索引列），会导致大量enq: TX - row lock contention或enq: TX - index contention等待事件 - 复合位图索引（如
(status, priority)）在GROUP BY priority时完全无效——位图索引不支持非前导列单独驱动 - 使用了
WHERE status IN ('A','B') GROUP BY status，但统计信息中status的DENSITY值异常（如因直方图过期），导致优化器误判选择性而跳过索引 - 查询中混用函数，例如
GROUP BY UPPER(status)，即使有位图索引也无效，需改用函数索引（但位图函数索引在 19c 不被支持）
替代方案：什么时候该放弃位图索引？
当你的 GROUP BY 场景同时满足以下任意两条，就该立刻停用位图索引，转用 B-Tree 或物化视图：
- 列基数 > 100（比如省份、产品分类等看似“有限”实则超阈值）
- 表日均 DML 量 > 5% 总行数（例如千万级表每天变更超 50 万行）
-
GROUP BY后还需HAVING COUNT(*) > 10或复杂过滤，位图索引无法下推谓词 - 需要与分区表联用，而当前分区键和位图索引列无对齐（19c 不支持位图索引跨分区高效合并）
真正容易被忽略的是：位图索引加速的从来不是“分组动作本身”，而是“快速定位每组的物理行位置”。一旦行定位变慢（比如锁争用、统计偏差、列值倾斜），整个 GROUP BY 就会退化成全表扫描加内存哈希——这时索引反而成了负担。
