函数索引不直接减少行锁，但通过精准定位索引页缩小扫描范围，从而间接降低锁粒度；其生效需严格匹配WHERE表达式，否则退化为全表扫描并扩大锁范围。
函数索引本身不直接减少行锁，但它能通过让查询更精准地命中索引、缩小扫描范围，间接降低锁的粒度和数量——关键在于避免全表或全索引扫描。
为什么函数索引能收敛锁范围
当 WHERE 条件里用了函数（比如 UPPER(email)），没函数索引时 MySQL 只能全表扫描，InnoDB 在 REPEATABLE READ 下会对扫描到的所有间隙加 NEXT-KEY LOCK，锁住大量无关行；建了匹配的函数索引后，优化器能定位到精确的索引页，只锁目标值及其附近间隙。
- 没索引：
WHERE UPPER(email) = 'ADMIN@EXAMPLE.COM'→ 全表扫描 → 锁整个聚簇索引 - 有索引：
CREATE INDEX idx_upper_email ON users ((UPPER(email)))→ B+ 树定位唯一键值 → 仅锁该 email 对应的记录 + 相邻间隙 - 特别注意：如果函数索引未命中（比如大小写不一致、括号缺失），效果等同于没建，照样全表锁
函数索引必须严格匹配 WHERE 表达式才能生效
MySQL 优化器不做语义推导，只做字符串级比对。哪怕多一个空格、大小写不同、用错函数名，索引就失效，锁范围立刻膨胀。
- ✅ 索引定义：
((UPPER(email)))，查询写法：WHERE UPPER(email) = 'X@Y.Z' - ❌ 查询写成
WHERE upper(email) = 'X@Y.Z'（小写函数名）→ 失效（严格 SQL mode 下） - ❌ 查询写成
WHERE TRIM(UPPER(email)) = 'X@Y.Z'（多套一层）→ 失效 - ❌ 索引是
((email))，查询却用WHERE UPPER(email)→ 不匹配，不走索引
JSON 字段函数索引必须显式 CAST 才能稳定命中
直接对 data->'$.status' 建索引会报错 ERROR 3105，且即使绕过，类型隐式转换也会导致锁扩大。
- ❌ 错误：
CREATE INDEX idx_status ON t ((data->'$.status')) - ✅ 正确：
CREATE INDEX idx_status ON t ((CAST(data->'$.status' AS CHAR(32)))) - → 这样才能确保
WHERE CAST(data->'$.status' AS CHAR(32)) = 'active'精准走索引，避免 JSON 类型推导失败触发全索引扫描 - → 注意：统一用
->而非->>，后者在某些上下文会触发隐式转换，破坏索引匹配
验证是否真减少了锁，不能只看 EXPLAIN
EXPLAIN 显示 key 用了函数索引，不代表锁真的收敛——必须结合运行时锁视图确认实际锁定行数。
- 第一步：执行带
FOR UPDATE的查询模拟业务，例如：SELECT * FROM users WHERE UPPER(email) = 'A@B.C' FOR UPDATE - 第二步：查
performance_schema.data_locks，过滤LOCK_TRX_ID对应事务，重点看LOCK_MODE和LOCK_DATA - 第三步：若
LOCK_DATA只显示单个值（如'a@b.c'），说明锁收敛；若出现NULL或区间（如(5, 10)），说明仍存在隐式间隙锁，索引未真正生效 - ⚠️ 小心陷阱：函数索引 +
IN或OR条件常导致退化，锁范围可能比单值查询大得多
最易被忽略的一点：函数索引只对字面完全匹配的查询起作用，而生产环境里 ORM 自动生成的 SQL 很容易因大小写、空格、函数别名等问题悄悄绕过它——上线前务必用真实查询语句跑一遍 EXPLAIN FORMAT=TREE 和锁视图双重验证。
