产品概述
应用场景
产品架构
实例类型
兼容性说明
使用规范建议
SELECT ... FOR UPDATE）SELECT ... FOR UPDATE语句可以对查询到的数据行加排他锁，阻止其他事务对这些数据行进行修改或加锁。START TRANSACTION;SELECT * FROM orders WHERE id = 1 FOR UPDATE;-- 对查询到的数据进行操作UPDATE orders SET status = 'shipped' WHERE id = 1;COMMIT;
SELECT ... FOR UPDATE后，其他事务如果尝试对同一数据行执行SELECT ... FOR UPDATE或修改操作，将会被阻塞，直到事务 A 提交或回滚。SELECT ... LOCK IN SHARE MODE）SELECT ... LOCK IN SHARE MODE语句可以对查询到的数据行加共享锁。共享锁允许多个事务同时读取同一数据行，但会阻止任何事务对数据行进行修改。START TRANSACTION;SELECT * FROM products WHERE id = 1 LOCK IN SHARE MODE;-- 其他事务可以读取但不能修改这些数据COMMIT;
WHERE 子句中的条件字段有索引，TDSQL Boundless 会使用行级锁；如果没有索引，则可能升级为范围锁。-- 创建表CREATE TABLE users (user_id INT PRIMARY KEY,username VARCHAR(20));SELECT * FROM users WHERE user_id = 101 FOR UPDATE; -- 行级锁SELECT * FROM users WHERE username = 'john' FOR UPDATE; -- 范围锁（username 列无索引，锁整张表的数据）SELECT * FROM users WHERE user_id >= 100 AND user_id < 200 FOR UPDATE; -- 范围锁（只锁 user_id 在 [100, 200) 区间的数据
对比维度 | TDSQL Boundless | MySQL (基于 InnoDB) | 核心差异与影响 |
加锁对象（对谁加锁） | 逻辑键值 (如 Primary Key = 15) | 数据的物理存储位置 (Space ID + Page Number + 位图) | 根本区别：TDSQL Boundless 不关心数据存储在哪个物理位置，直接对唯一的逻辑标识加锁。MySQL (InnoDB) 的锁与数据的物理页面布局强关联。 |
单条记录加锁 (如： WHERE number=15) | 行为一致：无论记录是否存在，都对逻辑键 primary key = 15 加行级锁。 | 行为分化： 1. 记录存在：对 number=15 的记录加行级锁。 2. 记录不存在：为防止幻读，会加一个间隙锁，锁定相邻两条记录（如 number=7 和 number=20）构成的区间。 | 锁的粒度与语义：TDSQL Boundless 的加锁行为更统一、可预测。MySQL (InnoDB) 在记录不存在时会升级为范围更广的间隙锁，可能影响并发插入。 |
范围查询加锁 (如： WHERE row_id BETWEEN 1 AND 20) | 整体或自适应分解： 1. 无冲突：直接加锁整个逻辑范围 [1, 20]。 2. 有冲突：若范围内某点（如 row_id=15）已被其他事务加锁，则会将加锁范围分解为不连续区间， [1, 15) + [15, 20]，并等待锁释放。 | 分段加锁：根据页面的物理存储顺序，将查询范围拆分成多个小的区间（如 (1,3], (3,5], (5,10]...）进行加锁。 | 加锁策略：TDSQL Boundless 倾向于从逻辑上维护一个大的锁范围，仅在遭遇锁冲突时分解。MySQL (InnoDB) 的加锁粒度受物理数据页的划分影响，更为细碎。 |
特点总结 | 直接加锁：加锁过程不依赖物理位置，逻辑清晰，特别适合分布式架构。 | 加锁前需定位：加锁前必须先确定数据所在的物理页面，锁管理与存储结构耦合紧密。 | 架构适应性：TDSQL Boundless 的实现在分布式环境下扩展性更好。MySQL (InnoDB) 的实现在单机集中式部署中非常成熟高效。 |
文档反馈