SQLite数据库替换路径字符串触发意外唯一约束违反问题排查

嘿，我来帮你捋捋这个事儿——你遇到的这个唯一约束违反错误，大概率不是SQLite的Bug，而是咱们在操作路径重命名的时候疏忽了某些细节。先把你的操作场景补全（毕竟你没写完所有SQL），我猜你的完整步骤大概是这样：

CREATE TABLE test (db_id INTEGER PRIMARY KEY, path TEXT UNIQUE);
INSERT INTO test (path) VALUES ('a');
INSERT INTO test (path) VALUES ('a/b');
INSERT INTO test (path) VALUES ('a/c');
-- 尝试把目录a重命名为d，先更新子路径
UPDATE test SET path = 'd/b' WHERE path = 'a/b';
UPDATE test SET path = 'd/c' WHERE path = 'a/c';
-- 最后更新父目录时触发错误
UPDATE test SET path = 'd' WHERE path = 'a';

下面给你拆解可能的原因和对应的解决办法：

1. 目标路径'd'已经存在于数据库里 #

这是最常见的情况！你可以先查一下数据库里是不是已经有一条path为'd'的记录：

SELECT * FROM test WHERE path = 'd';

如果真的存在，你得先处理这条记录——要么删掉，要么把它重命名成别的，之后再执行你的更新操作。

2. 更新顺序或者事务的锅 #

如果你的操作是分散执行的（没放在事务里），万一有其他进程同时修改数据库，可能会导致中间状态出现冲突。建议把所有更新打包进一个事务，这样所有操作会一次性生效，不会触发中间状态的约束检查：

BEGIN TRANSACTION;
UPDATE test SET path = 'd/b' WHERE path = 'a/b';
UPDATE test SET path = 'd/c' WHERE path = 'a/c';
UPDATE test SET path = 'd' WHERE path = 'a';
COMMIT;

3. 排序规则导致的非预期匹配 #

SQLite默认是按二进制比较文本的，但如果你的path列用了不区分大小写的排序规则（比如COLLATE NOCASE），那'D'和'd'会被视为同一个路径。你可以查一下表的结构确认：

PRAGMA table_info(test);

看path列的collate字段，如果是NOCASE，那得确保数据库里没有大小写不同的d路径。

4. 路径里藏着特殊字符 #

有时候路径里可能有看不见的特殊字符——比如空格、制表符，你看起来是'a'，实际存的是'a '（带空格），这时候更新成'd'如果刚好有个真的'd'就会冲突。你可以用十六进制输出看看路径的真实内容：

SELECT path, hex(path) FROM test WHERE path LIKE '%a%';

通过十六进制就能一眼看出有没有隐藏字符了。

总结 #

基本上都是咱们操作时的小疏漏，不是SQLite的Bug。按照上面的步骤排查一遍，应该就能解决问题啦！

内容的提问来源于stack exchange，提问作者MShekow