由于没有给字段设置唯一性，所以改为通过查询语句加锁确保唯一性，但是发现select count(*) 为0时，不会加锁，所以在insert方法后面需要加锁二次查询确保唯一性。
在 PolarDB 的读已提交事务隔离级别下，SELECT ... FOR UPDATE 的行为与索引使用、锁机制以及数据是否存在密切相关。以下是导致 WHERE 条件未用索引时查不到数据且不会锁表的原因分析：
- 1. 索引未命中
如果 WHERE 条件未使用索引，数据库会进行全表扫描（Full Table Scan）。
在全表扫描过程中，SELECT ... FOR UPDATE 会对每一行数据加锁，但前提是这些行满足 WHERE 条件。
如果没有数据满足 WHERE 条件，则不会对任何行加锁，也不会锁表。
- 2. 读已提交隔离级别
在读已提交隔离级别下，事务只能看到已经提交的数据。
如果查询条件下的数据不存在（可能是被其他事务删除或尚未插入），则当前事务不会对这些不存在的行加锁。
- 3. 锁机制
SELECT ... FOR UPDATE 的锁作用范围是基于查询结果集的。
如果查询结果为空（即没有数据满足条件），则不会有任何行被加锁。
数据库不会对整个表加锁，而是仅对符合条件的行加锁。
- 4. 性能优化
当 WHERE 条件未使用索引时，数据库可能通过优化器判断查询代价过高，从而避免不必要的锁操作。
如果查询结果为空，数据库可能会直接跳过锁操作以减少资源消耗。
解决方案
如果希望确保 SELECT ... FOR UPDATE 能够正确加锁，可以考虑以下措施：
优化索引：为 WHERE 条件创建合适的索引，确保查询能够高效定位目标数据。
检查数据存在性：在执行 SELECT ... FOR UPDATE 之前，先确认数据是否存在。
调整隔离级别：如果业务场景允许，可以考虑使用更高级别的隔离（如可重复读），但这可能会引入其他问题（如幻读）。
示例代码
以下是一个示例，展示如何在事务中使用索引和 SELECT ... FOR UPDATE
-- 创建测试表并插入数据
CREATE TABLE test_table (
id INT PRIMARY KEY,
name VARCHAR(50),
status INT
);
INSERT INTO test_table (id, name, status) VALUES (1, 'Alice', 1);
INSERT INTO test_table (id, name, status) VALUES (2, 'Bob', 0);
-- 添加索引以优化 WHERE 条件
CREATE INDEX idx_status ON test_table(status);
-- 开启事务
BEGIN;
-- 使用 SELECT ... FOR UPDATE 查询
SELECT * FROM test_table WHERE status = 1 FOR UPDATE;
-- 更新数据
UPDATE test_table SET status = 0 WHERE id = 1;
COMMIT;
通过上述方式，可以确保查询能够高效定位数据并加锁。