mysql主键索引与二级索引区别_mysql索引结构设计优选

主键索引即聚簇索引数据行直接存储在B树叶子节点中查询时无需回表二级索引仅存索引列和主键值需回表获取完整行记录。主键索引就是聚簇索引数据行直接存里面MySQL 的 InnoDB 引擎里PRIMARY KEY 索引不是“普通索引加个唯一约束”那么简单——它决定了整张表数据的物理存储顺序。也就是说SELECT * FROM t WHERE id 123 这种查询InnoDB 找到 id 123 对应的 B 树叶子节点时**那一页里就直接躺着完整的行记录**不用二次回表。常见错误现象EXPLAIN 显示 typeconst 但 Extra 里还带 Using where其实是没走对主键或者字段类型隐式转换导致索引失效。主键必须非空且唯一不能是 NULL如果建表时没显式定义 PRIMARY KEYInnoDB 会悄悄选一个 NOT NULL UNIQUE 列当主键都找不到就自动生成隐藏的 row_id6 字节但这会让 SELECT * FROM t 结果不可预测主键越短越好比如用 BIGINT 代替 VARCHAR(36) 做主键B 树层级更少范围扫描更快二级索引只存「索引列 主键值」查数据要回表所有非主键的 INDEX包括 UNIQUE INDEX、FULLTEXT、SPATIAL都是二级索引。它的 B 树叶子节点不存整行数据只存索引字段值和对应记录的主键值比如 name 索引里存的是 (Alice, 105)其中 105 是主键 ID。使用场景当你执行 SELECT name FROM user WHERE name Alice能直接从二级索引里拿到结果覆盖索引但一旦写成 SELECT email FROM user WHERE name Alice就得拿着 105 再去主键索引里捞一遍完整行——这就是“回表”IO 开销翻倍。联合二级索引要注意最左前缀INDEX (a, b, c) 能加速 WHERE a1 AND b2但对 WHERE b2 无效如果业务经常查 SELECT a,b,c FROM t WHERE x1与其让优化器回表不如建覆盖索引 INDEX (x, a, b, c)二级索引本身也占空间INSERT/UPDATE 时要同时维护主键树和所有二级索引树索引越多写越慢为什么 ORDER BY 有时走不了索引排序是否能复用索引关键看「索引顺序」和「查询条件排序字段」是否构成连续的最左前缀。比如有联合索引 INDEX (status, create_time) 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。