x锁阻塞s锁是因二者语义冲突：x锁表示独占修改，s锁表示安全读取，底层锁兼容性规则定义为不兼容；同一行上多个s锁可共存，但只要存在x锁，任何新s锁或x锁均需等待。
为什么X锁会阻塞S锁？这是锁兼容性规则决定的
不是MySQL“故意设计成这样”，而是S锁（共享锁）和X锁（排他锁）在InnoDB底层就定义为不兼容。当一个事务对某行加了X锁，其他事务再尝试对该行加S锁（比如执行SELECT ... LOCK IN SHARE MODE）就会被挂起等待——因为X锁意味着“我要独占修改”，S锁意味着“我要安全地读”，二者语义冲突。
常见错误现象：Lock wait timeout exceeded 报错往往就源于此：事务A持着X锁没释放，事务B卡在申请S锁上超时。
使用场景中容易忽略的一点是：UPDATE语句本身不显式写LOCK IN SHARE MODE，但它内部先做一次当前读（加X锁），这就天然阻塞后续所有对该行的S锁请求。
- 同一行上，多个S锁可以共存（读-读不阻塞）
- 但只要有一个X锁存在，任何新S锁或X锁都会等待
- 注意：普通
SELECT不申请S锁，所以它不参与这个锁等待队列
快照读为什么完全绕过锁系统？它根本不申请锁
MVCC快照读（如SELECT * FROM t WHERE id = 1）不走锁路径，而是直接查Undo Log里的历史版本。它依赖的是事务启动时刻生成的Read View，根据DB_TRX_ID和m_ids列表判断哪一版数据对自己可见。
这意味着：即使另一事务正拿着X锁修改同一行，你的快照读也完全感知不到——它看的是“过去”，对方改的是“现在”。
性能影响很实在：没有锁竞争、没有上下文切换、不进锁等待队列。但代价是看不到已提交的新版本（在RR级别下）或看到部分新版本（RC级别下）。
-
REPEATABLE READ下，事务第一次SELECT生成Read View，之后复用 -
READ COMMITTED下，每次SELECT都新建Read View，所以能读到其他事务刚提交的行 - 一旦语句带
FOR UPDATE或命中唯一索引更新前定位，就退化为当前读，立刻进锁流程
为什么说“读写分离”不是靠配置，而是靠语句类型自动分流？
MySQL没有“开启读写分离开关”这种东西。所谓分离，是引擎根据SQL语义自动路由：普通SELECT → 快照读路径；UPDATE/SELECT FOR UPDATE → 当前读+加锁路径。两者底层走的是完全不同的代码分支。
容易踩的坑是误以为“只要没写FOR UPDATE就一定不阻塞”，但其实以下情况也会触发当前读：
-
UPDATE t SET x=1 WHERE id=100：WHERE条件命中主键，必须先当前读取最新行才能加锁更新 - 唯一索引等值查询后紧跟
INSERT ... ON DUPLICATE KEY UPDATE - 某些优化器认为需要精确锁定范围时，会主动升级为当前读（尤其配合
ORDER BY ... LIMIT）
你可以用SHOW ENGINE INNODB STATUS里的TRANSACTIONS段确认某条SELECT是否真的走了快照读——如果没出现在lock struct(s)里，基本就是快照读。
最常被忽略的复杂点：长事务会让快照读变慢甚至失败
MVCC不是无成本的。如果一个事务长时间不提交（比如应用层开启事务后停在HTTP响应前），它的Read View会一直保留，导致Purge线程无法清理它之前产生的Undo Log。历史版本链越积越长，新事务构造Read View时要遍历的版本数就越多。
结果不是阻塞，而是延迟：原本毫秒级的SELECT可能变成秒级；极端情况下触发Lock wait timeout exceeded，即使你没写任何锁语句。
监控关键指标：HISTORY LIST LENGTH（来自SHOW ENGINE INNODB STATUS），超过5万就要警惕；避免在业务逻辑里跨HTTP请求持有一个事务。
