SQLite ON DELETE SET DEFAULT：默认值已经设置，为什么删除父记录仍失败
把某个负责人删除后，资产自动转入“未分配”类别，是很自然的表设计。于是给子表外键写DEFAULT 0，再添加ON DELETE SET DEFAULT。真正删除时却报外键错误，容易让人怀疑动作没有执行。事实上，设置默认值只是引用动作的一部分：改成零以后，零仍然需要满足外键关系。默认值是一个值，不会自动在父表创建对应记录。
本文在Linux、CPython 3.12.14与运行时SQLite 3.53.1上实跑。数据库均为独立的:memory:连接，测试结束显式关闭，不读取或修改业务数据库。Python版本与SQLite库版本分别记录，因为相同Python版本可能链接不同SQLite构建。 示例在事务外启用外键并立即回读确认；isolation_level=None使各条独立语句的观察边界清楚。
AI生成的概念示意图：子记录包裹转向默认停靠点，空轮廓码头与真实存在的父记录码头形成对照；不是真实软件界面或运行截图。
完整程序与实际输出
保存为demo.py，执行python3 demo.py。程序只使用固定测试输入，代码和本次输出分别列出。
import sqlite3
con = sqlite3.connect(':memory:', isolation_level=None)
try:
con.execute('PRAGMA foreign_keys = ON')
assert con.execute('PRAGMA foreign_keys').fetchone()[0] == 1
con.executescript('''
CREATE TABLE owner(id INTEGER PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE asset(id INTEGER PRIMARY KEY,
owner_id INTEGER NOT NULL DEFAULT 0
REFERENCES owner(id) ON DELETE SET DEFAULT);
INSERT INTO owner VALUES(7, 'team');
INSERT INTO asset VALUES(1, 7);
''')
try:
con.execute('DELETE FROM owner WHERE id = 7')
except sqlite3.IntegrityError as exc:
print('first delete:', exc.sqlite_errorname)
print('after failure:', con.execute('SELECT * FROM asset').fetchall())
print('owners:', con.execute('SELECT id FROM owner ORDER BY id').fetchall())
con.execute("INSERT INTO owner VALUES(0, 'unassigned')")
con.execute('DELETE FROM owner WHERE id = 7')
print('after fallback exists:', con.execute('SELECT * FROM asset').fetchall())
print('foreign_key_check:', con.execute('PRAGMA foreign_key_check').fetchall())
finally:
con.close()本次实际标准输出：
first delete: SQLITE_CONSTRAINT_FOREIGNKEY after failure: [(1, 7)] owners: [(7,)] after fallback exists: [(1, 0)] foreign_key_check: []
先读清楚这两张表的约定
owner只有编号七的team记录，asset编号一引用它。asset.owner_id同时声明NOT NULL、DEFAULT 0和REFERENCES，并规定父记录删除时设置默认值。三条约束各司其职：不能为空、需要备用值时使用零、非空引用必须指向合法父键。写在同一列定义中，并不代表默认值优先级高到可以绕过其他约束。
第一次删除编号七的父记录时，SQLite需要把相关资产的owner_id改成零。但父表没有编号零，所以变更后的关联不满足外键要求，语句失败。输出使用sqlite_errorname展示SQLITE_CONSTRAINT_FOREIGNKEY，避免依赖不同版本可能变化的错误英文描述，也明确错误类别确实是引用关系。
随后查询资产仍然得到一和七，父表也仍保留七。这证明此次失败没有把资产留在一个半改写状态，也没有先永久删除父记录再单独报告错误。本例使用立即外键与独立删除语句，因此这次语句的效果被撤销；不能据此泛化所有延迟约束和多语句事务的失败边界。
补齐默认目标以后为何能够成功
程序接着明确插入编号零、名称unassigned的父记录，再执行同样的删除。此时资产被改成引用零，原负责人七被删除，foreign_key_check返回空列表。两次尝试唯一有意义的差异，是默认父记录是否存在；这比只看建表语法是否通过，更能验证业务中的兜底路径。
外键动作不会负责替应用维护“未分配”记录。若这个记录被管理员误删、数据迁移遗漏或种子数据没有部署，原本可用的删除流程就可能失败。因此使用哨兵父记录的设计，需要在初始化、迁移与运维检查中把它作为明确依赖，而不是一个约定俗成却无人维护的特殊数字。
不要为让删除通过而临时关闭外键。那会把问题从一次可见的失败变成可能长期存在的孤儿引用。正确方向是决定业务是否真的允许转入默认归属，并保证默认目标合法；如果不允许，拒绝删除本来就是更符合数据约束的结果。数据库错误在这里提供了有效保护。
默认值、空值和级联删除是不同业务
若允许“没有负责人”且子键可空，可以考虑用SET NULL表达缺失关联。若希望资产随负责人一起消失，CASCADE表达的是删除关联子记录。若资产必须保留并且有合法兜底归属，SET DEFAULT才符合本文模型。这些选项会影响数据生命周期，不能因为其中一种更容易让测试通过就随意替换。
默认值还受到本列其他约束限制。若没有显式默认值，相关动作可能得到NULL，而NOT NULL会阻止它；若默认值不满足CHECK，同样不会因为来自外键动作而豁免。把默认值看作一次普通的数据赋值，再检查所有应满足的规则，更容易推导出结果。
复合外键要把整组默认值一起考虑。父键若由租户和负责人编号共同组成，仅保证编号零存在远远不够；需要合法的完整组合，并明确每个租户如何表达未分配。一个全局零值兜底可能掩盖租户边界，设计时应按真实业务键验证，不能从单列示例直接复制。
上线前应当检验哪条删除路径
测试至少包含没有子记录的父项、有子记录但无默认父项、默认父项存在以及默认父项自身被删除。最后一种特别容易被漏掉：如果资产已指向零，再删除零，设置默认值仍然会指回那个即将不存在的目标，因此这条路径通常也应该被阻止。默认记录需要和普通记录不同的维护策略，但权限设计应在应用层清楚表达。
foreign_key_check用来发现当前数据库中的外键违规，不是证明未来每次删除都会成功的预测器。第一次删除前即使现状完全合法，也可能因为动作产生不存在的默认键而失败。因此需要既检查当前数据，也实际在隔离测试数据库里执行关键变更，再观察父表和子表的最终状态。
在真实文件数据库中，应确认每个写连接都启用了外键检查，并在事务外设置及回读。连接池、迁移脚本和离线修复工具可能使用不同连接入口，不能仅凭某个管理界面显示开启就推断所有路径一致。本例先做回读断言，是为了避免把“外键根本没检查”误当成SET DEFAULT工作正常。
性能上，父记录删除可能需要寻找关联子记录。子键索引通常值得评估，但索引只改变查找成本，不改变默认目标必须存在的逻辑。上线验收应先保证数据语义正确，再用真实规模测量删除耗时与锁影响；一个运行很快却把资产指向无意义兜底的方案，仍然不是可靠的归属管理。
参考资料与验证记录
官方资料核验于2026年10月3日。本次完整程序退出码为0，标准错误为空；例子验证的是上述固定输入与运行环境，不表示所有平台和版本的输出细节完全一致。
