icp通过在存储引擎层提前用全部索引列条件过滤，仅对最终满足所有索引条件的索引项加锁，显著减少锁数量；其影响加锁范围的关键在于执行时机和索引列条件是否可下推。
谓词下推（Predicate Pushdown）本身不改变加锁逻辑，但索引下推（ICP）会实质性影响加锁范围——关键在于：MySQL 在 ICP 模式下，只对最终满足 WHERE 中所有索引列条件的索引项加锁，而不是对所有“匹配最左前缀”的索引条目都加锁。
ICP 如何缩小加锁范围
在未启用 ICP 的老版本（如 MySQL 5.5），只要索引扫描命中了最左前缀条件，哪怕后续条件（如 status = 'pending'）实际不满足，InnoDB 仍会对该索引条目加记录锁（或间隙锁），然后回表后由 Server 层过滤掉。这意味着锁住了大量“本不该参与最终结果”的索引行。
启用 ICP 后，存储引擎层在遍历索引时，就用全部索引列上的条件（例如复合索引 (user_id, created_at, status) 上的 user_id = 123 AND status = 'pending'）做判断。只有同时满足这些条件的索引项，才会触发回表和加锁；其余被 ICP 过滤掉的索引条目，根本不会进入加锁流程。
- 加锁对象从“所有最左前缀匹配项” → 缩小为“所有索引条件下推后仍满足的项”
- 锁粒度没变（仍是索引记录锁/间隙锁），但锁的数量显著减少
- 特别在范围查询 + 非前缀字段过滤场景下（如
WHERE user_id > 100 AND status = 'done'），ICP 能避免对大量status != 'done'的索引节点加锁
为什么 status = 'pending' 这类非前缀条件也能影响加锁
因为 ICP 允许把涉及索引列的谓词（哪怕不是最左前缀）下推到引擎层执行。只要 status 是复合索引的一部分，且查询中用了等值条件，优化器就可能选择 ICP —— 此时 InnoDB 在 B+ 树叶子页扫描时，会逐条比对 status 值，不满足的直接跳过，不申请锁。
注意：status 必须是索引列，且不能是函数包裹（如 UPPER(status) = 'PENDING'），否则无法下推，Server 层过滤回归，锁范围扩大。
- 可下推的典型条件：
=、IN、BETWEEN（仅限索引列）、部分>/（需满足排序连续性） - 不可下推的常见情况：
LIKE '%abc'、IS NULL（某些版本）、col + 1 = 5、任何对索引列的函数调用 - 可通过
EXPLAIN FORMAT=TRADITIONAL查看Extra字段是否有Using index condition
容易被忽略的死锁风险变化
ICP 缩小了单次查询的加锁集合，看似更安全，但它改变了加锁顺序和范围边界，反而可能在并发更新场景中引入新类型的死锁。
比如两个事务分别执行：
UPDATE orders SET state = 'shipped' WHERE user_id = 100 AND status = 'pending';
和
UPDATE orders SET state = 'canceled' WHERE user_id = 100 AND status = 'created';
若复合索引是 (user_id, status)，ICP 会让两个事务只锁定各自 status 值对应的索引项，而非整个 user_id = 100 的索引区间。这减少了锁冲突，但若事务还涉及其他非索引字段的更新，且加锁顺序不一致，仍可能因细粒度锁交错而死锁。
- ICP 不等于无锁，只是锁得更精准
- 线上排查死锁时，
SHOW ENGINE INNODB STATUS中的 lock_trx_id 和 lock_rec_ids 对应的不再是“前缀匹配段”，而是实际被 ICP 选中的具体索引记录 - 应用层重试逻辑需兼容这种更细、更分散的锁行为
真正影响加锁的是 ICP 的执行时机，不是谓词下推这个概念本身；而是否触发 ICP，取决于索引结构、查询写法、MySQL 版本及优化器决策——它藏在 EXPLAIN 里，却在并发时真实地改写了锁的分布地图。
