加索引是否锁表取决于mysql版本和操作方式：5.6前必然锁表；5.6起二级索引默认支持online ddl，但仍有两个毫秒级mdl锁窗口；需显式指定algorithm=inplace, lock=none，并确保使用innodb引擎。
加索引时到底锁不锁表？看版本和操作方式
MySQL 5.6 之前，CREATE INDEX 几乎必然锁表——整张表加排他锁（X 锁），期间所有 DML 和 DQL 都被阻塞。5.6 起引入 Online DDL，对二级索引创建默认支持并发 DML，但仍有两个关键窗口会短暂加元数据锁（MDL）：开始解析语句时、索引构建完成后做原子切换时。这两个瞬间虽短（毫秒级），但在高 QPS 场景下仍可能卡住后续语句。
- 确认是否真正“在线”：执行
SHOW PROCESSLIST，观察状态是否含altering table或waiting for table metadata lock - 生产环境务必用
ALGORITHM=INPLACE, LOCK=NONE显式声明（如支持），否则 MySQL 可能降级为 COPY 模式并锁表 - MyISAM 引擎不支持 Online DDL，任何索引操作都强制锁表，InnoDB 才是前提
索引类型决定锁粒度与冲突范围
B+Tree 索引本身不直接“加锁”，但它决定了事务加锁时的扫描路径和锁定对象。比如一个无索引的 WHERE status = 'paid' 查询会全表扫描并给每行加 X 锁；而加上 INDEX idx_status (status) 后，InnoDB 只需遍历索引 B+Tree 中满足条件的叶子节点，再对对应主键记录加锁——锁的行数大幅减少，但索引页本身在写入时也会被临时加锁（latch），影响并发插入性能。
- 位图索引（Oracle 特有）在 MySQL 中不存在，别被文档误导；MySQL 的
FULLTEXT或SPATIAL索引有独立锁机制，不走标准 B+Tree 路径 -
REVERSE索引（如CREATE INDEX idx_id_reverse ON orders(id) REVERSE）可缓解自增主键插入热点，但它让范围查询失效，且 InnoDB 无法利用其做排序优化，反而可能增加锁等待 - 部分索引（
WHERE is_active = true）缩小索引体积，但查询条件必须严格匹配谓词，否则索引不可用，事务仍会退化为扫全表加锁
覆盖索引如何避免锁升级？
当 SELECT 语句能通过索引直接拿到所有字段（即“覆盖”），InnoDB 就不必回表查聚簇索引，也就不会对主键记录加锁——但这仅适用于不带 FOR UPDATE 或 LOCK IN SHARE MODE 的普通查询。一旦显式加锁，即使覆盖，InnoDB 仍会对索引记录本身加锁（记录锁），只是省去了主键行的额外 X 锁。
- 覆盖索引不能规避 DML 锁：
UPDATE ... WHERE user_id = 123即使user_id是二级索引，InnoDB 仍需先锁二级索引记录，再锁主键行，形成“双重锁定” -
SELECT ... FOR UPDATE在唯一索引上命中单行时只加记录锁；在非唯一索引或范围查询时，会自动升级为临键锁（next-key lock），锁住值区间，防止幻读——这是容易被忽略的隐式锁范围扩张 - 用
EXPLAIN FORMAT=JSON查看used_columns和key字段，确认是否真覆盖，避免误判
JSON 字段索引与锁行为的特殊性
MySQL 5.7+ 的 JSON 列若建了 GENERATED COLUMN + INDEX，锁行为和普通字段一致；但若用 GIN 索引（PostgreSQL 特性），MySQL 并不支持——这里常有混淆。MySQL 实际用的是函数索引（如 CAST(profile->>'$.age' AS UNSIGNED)），其锁机制完全依赖底层 B+Tree，无特殊优化。
-
JSON_CONTAINS()或->>查询无法使用普通 B+Tree 索引加速，除非提前提取到生成列并建索引，否则仍是全表扫描+逐行加锁 - 对
JSON字段做UPDATE时，即使只改一个 key，MySQL 也需重写整个 JSON 文本，触发整行（聚簇索引记录）的 X 锁，且无法被二级索引缓解 - 高频更新的 JSON 字段建议拆成关系型结构，否则锁竞争和 MVCC 版本链膨胀会显著拖慢事务吞吐
最易被忽视的一点：索引设计不是静态的，它和事务隔离级别、SQL 写法、甚至统计信息准确性深度耦合。比如 READ COMMITTED 下间隙锁禁用，但如果你的查询因索引失效退化为全表扫描，照样会锁住所有行——锁的范围从来不由索引单独决定，而是执行计划、引擎行为和隔离级别的共同结果。
