mysql中使用位图索引与哈希索引的性能比较

来源：这里教程网时间：2026-02-28 20:39:35 作者：

MySQL 原生不支持位图索引（Bitmap Index）和哈希索引（Hash Index）作为通用存储引擎的常规索引类型——这是关键前提，直接决定后续所有性能比较是否成立。

MySQL 有没有位图索引？

没有。位图索引常见于 OLAP 场景的列式数据库（如 Oracle、Greenplum、ClickHouse 的某些实现），但 InnoDB 和 MyISAM 均不提供

BITMAP

索引类型。即使你执行

CREATE INDEX idx ON t(col) USING BITMAP

，MySQL 会报错：

ERROR 1064 (42000): Syntax error near 'BITMAP'

。

如果你在 MySQL 中看到“位图”相关行为，大概率是以下情况之一：

应用层用
BLOB
或
VARBINARY
手动维护位图结构（极少见，且需自行处理并发与一致性）误将
SET
或
ENUM
类型的内部存储机制理解为位图索引（实际仍是 B+ 树索引） 使用了 MySQL NDB Cluster（已基本淘汰），它支持位图索引，但仅限于 NDB 引擎，且不适用于主流 OLTP 场景

MySQL 支持哈希索引吗？

仅在 Memory 引擎中支持显式哈希索引；InnoDB 的自适应哈希索引（

adaptive_hash_index

）是隐式、只读、自动管理的，无法由用户创建或控制。

Memory 引擎的哈希索引使用方式：

CREATE TABLE t_mem (
  id INT,
  name VARCHAR(32)
) ENGINE=MEMORY;
CREATE INDEX idx_name ON t_mem(name) USING HASH;

注意：

哈希索引只支持
=
和
等精确匹配，不支持范围查询（
>
、
BETWEEN
）、
LIKE 'prefix%'
或排序（
ORDER BY
）哈希冲突会导致链表退化，高重复值下性能急剧下降（例如对全为
'N/A'
的
status
列建哈希索引） Memory 表数据不持久，重启即丢，仅适合临时缓存类场景

为什么不能拿 InnoDB 的 B+ 树索引和“假想的位图/哈希索引”比性能？

因为对比对象不存在。真实可选的索引类型只有：

InnoDB：仅支持
BTREE
（默认），语法上虽允许
USING HASH
，但会被静默忽略，仍建 B+ 树 MyISAM：仅支持
BTREE
Memory：支持
HASH
和
BTREE
，但适用场景受限

若真要优化等值查询性能，应优先考虑：

联合索引最左前缀匹配（
INDEX(a,b)
能加速
WHERE a = ? AND b = ?
）覆盖索引避免回表（
SELECT id FROM t WHERE status = 'done'
+
INDEX(status, id)
）适当压缩索引（
KEY_BLOCK_SIZE
对大字段有效）确认
adaptive_hash_index
是否开启（
SHOW VARIABLES LIKE 'innodb_adaptive_hash_index'
），它会在热点 B+ 树页上自动构建哈希映射，加速重复等值查询

真正需要位图或哈希语义时，得换数据库——比如高频低基数等值过滤（性别、状态码）且写少读多，ClickHouse 的