MySQL不存在真正无锁更新，所谓“无锁”实为规避显式锁竞争、将冲突控制移至应用层或异步链路；其行锁是MVCC和崩溃恢复的基础，无法绕过。
MySQL 本身没有提供用户可直接调用的“无锁更新”SQL 原语——UPDATE 操作在行级始终会加 record lock 或 next-key lock，这是事务隔离的底层保障。所谓“无锁”，实际是指**规避显式锁竞争、减少阻塞等待、把冲突控制移到应用层或异步链路中**，而非真的绕过 InnoDB 的锁机制。
为什么不能真跳过行锁？
InnoDB 的行锁是 MVCC 和崩溃恢复的基础：即使你用 SELECT ... FOR UPDATE 显式加锁，或只用普通 UPDATE，只要修改同一行，后到的事务就会在 lock_sys 中排队等待。这不是设计缺陷，而是保证 ACID 的必要开销。试图用 INSERT IGNORE 或 REPLACE INTO 替代 UPDATE 也逃不掉锁——它们同样要先定位、加锁、再写入。
常见误判：
- 以为
WHERE条件命中索引就“不锁”——错，它锁的是索引记录（包括唯一索引和非唯一索引的 gap） - 以为
READ COMMITTED隔离级别下“锁得少”就能高并发——错，它只是不加 gap lock，但 record lock 照样阻塞 - 以为关闭 autocommit 就能“无锁”——错，autocommit 关闭后，锁持有时间反而更长
乐观锁：用 WHERE 校验代替前置加锁
这是最贴近“无锁语义”的方案，核心是把冲突检测从“加锁时”推迟到“提交前”，靠数据库原子性完成最终校验。
典型结构：
UPDATE products SET stock = stock - 1, version = version + 1 WHERE id = 123 AND version = 5;
关键点：
- 必须有
version或updated_at字段，并在读取时一并获取 - 应用层需检查
ROW_COUNT()（MySQL 返回影响行数），为 0 则说明版本已变，需重试或报错 - 避免在事务中多次读取再更新——这会导致 ABA 问题；应单次读+单次带条件更新
- 不要用
NOW()直接更新updated_at，否则 WHERE 条件永远不匹配；应先查出旧值再拼进 SQL
热点数据分片：把单点锁拆成多把小锁
当某一行（如商品库存、账户余额）被高频更新，锁争用集中在一条记录上，此时“分片”是最有效解法——把逻辑上的一行，物理上拆成 N 行，更新时随机或哈希路由到其中一行。
示例表结构：
CREATE TABLE account_shard ( user_id BIGINT NOT NULL, shard_id TINYINT NOT NULL, balance BIGINT NOT NULL, PRIMARY KEY (user_id, shard_id) );
更新语句（应用层计算 shard_id）：
UPDATE account_shard SET balance = balance + 100 WHERE user_id = 1001 AND shard_id = 3;
注意事项：
- 查询汇总时需
SELECT SUM(balance) FROM account_shard WHERE user_id = 1001，性能比单行略差，但远好于锁等待 - shard_id 不宜硬编码，建议用
user_id % N或一致性哈希，避免数据倾斜 - 分片数不是越多越好：N > 16 后，查询聚合成本上升，且事务无法跨分片原子提交
异步批量合并：彻底脱离实时行锁
适用于“写频高、读不强实时”的场景（如 PV/UV 统计、积分累加）。思路是把更新压入队列，由后台任务按批次合并写入。
典型链路：
- 应用层写 Redis：
INCR counter:page_1001 - 定时任务（如每 5 秒）执行：
SELECT SUM(value) FROM redis_keys LIKE 'counter:page_*'→ 聚合后执行单条UPDATE page_stats SET views = views + ? WHERE page_id = ? - 清空 Redis 计数器
这个方案真正意义上“不走 MySQL 行锁路径”，但代价是数据延迟。如果业务要求秒级一致，该方案不可用；若允许分钟级延迟，它比任何乐观锁都更抗压。
容易被忽略的细节：
分片和异步方案看似简单，但一旦上线就很难回退——分片键选错会导致后续无法均衡；异步链路缺失幂等或失败重试，会直接丢数据。真正的难点不在代码怎么写，而在如何设计分片策略、如何监控聚合延迟、以及如何让业务方接受“最终一致”这个前提。
