SQLite中如何使用PRAGMA foreign_keys正确开启外键约束？

用过SQLite的开发者大多碰到过这样的困惑：明明建表时写了FOREIGN KEY定义，删除主表记录后，子表里一堆孤立数据却安然无恙。这不是SQLite的bug，而是它的设计如此——外键约束默认是关闭的，必须通过PRAGMA foreign_keys命令显式开启。这条命令的行为和大多数关系型数据库不同，比如MySQL（InnoDB引擎）默认就启用了外键检查，而SQLite把它交给应用层决定。理解这条命令的正确用法，是保证数据完整性绕不开的一步。

外键约束为什么默认关闭以及如何开启

SQLite官方给出的解释是历史原因：外键约束是在3.6.19版本才引入的，为了兼容早期的大量存量应用，默认值设为了关闭。同时，SQLite是一个嵌入式数据库，很多场景跑在资源受限的环境里，外键检查会带来额外的性能开销，所以让使用者自己权衡。

开启的方式很简单，在建立数据库连接后执行一条命令即可：

PRAGMA foreign_keys = ON;
-- 关闭则是
PRAGMA foreign_keys = OFF;
-- 查看当前状态
PRAGMA foreign_keys;

需要特别注意的是，这个设置是会话级别的，不是持久化的。也就是说，它只对当前连接有效，连接断开后失效，下一次连接进来依然是默认的关闭状态。如果你的应用使用连接池，务必确保每一条从池里取出的连接都执行过这条命令，否则某些连接有外键保护、某些没有，问题会非常隐蔽。

另一个容易踩的坑是执行时机。PRAGMA foreign_keys不能在事务内部开启或关闭。SQLite规定，当事务处于活动状态时，这条PRAGMA会被静默忽略，不报任何错误。很多框架在封装数据库操作时会自动开启事务，如果你在这样的环境下执行PRAGMA却没生效，多半就是这个原因。正确的做法是在事务开始之前设置，例如：

-- 正确：在事务外执行
PRAGMA foreign_keys = ON;
BEGIN;
DELETE FROM orders WHERE id = 1;
COMMIT;

-- 错误：事务内执行会被忽略
BEGIN;
PRAGMA foreign_keys = ON;  -- 静默失效，不生效
DELETE FROM orders WHERE id = 1;
COMMIT;

开启后的实际效果与级联删除配置

开启外键约束后，SQLite会严格检查所有写操作。往子表插入一条引用不存在主键的记录，会直接抛出SQLITE_CONSTRAINT_FOREIGNKEY错误（错误码787）；删除被引用的父表记录同样会失败。来看一个完整的建表示例：

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL
);

CREATE TABLE orders (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL,
    amount REAL,
    FOREIGN KEY (user_id) REFERENCES users(id)
        ON DELETE CASCADE   -- 父记录删除时级联删除子记录
        ON UPDATE CASCADE   -- 父表主键更新时同步更新
);

ON DELETE后面可以跟几种不同的策略，选哪种取决于业务语义。CASCADE表示级联删除，适合订单这种强依附于用户的从属数据；SET NULL把子表外键列置空，要求该列允许NULL，适合可有可无的弱关联；RESTRICT和NO ACTION都是拒绝删除父记录，区别在于触发检查的时机，实际使用中效果几乎一样；SET DEFAULT会设置成列的默认值，用得较少。如果不写任何子句，默认行为等同于NO ACTION。

还有一个调试利器值得了解：PRAGMA foreign_key_check。它可以扫描整个数据库，找出所有违反外键约束的行，特别适合在存量数据上补开外键之前做检查。如果直接对一份已经存在脏数据的库开启约束，写入操作可能莫名其妙失败，先用它排查一遍能省不少排查时间：

-- 返回所有违反约束的行：表名、行id、被引用表、父表中的失败主键
PRAGMA foreign_key_check;

-- 只检查某张表
PRAGMA foreign_key_check(orders);

如果结果为空，说明数据是干净的，可以放心开启外键。如果有输出，需要先手工清理这些孤立数据，否则后续写入会遇到约束冲突。

在不同编程语言中的正确配置姿势

由于PRAGMA是会话级的，各语言驱动里配置的位置略有差异，但核心原则一致：连接建立后、执行任何业务SQL前设置。

Python的标准库sqlite3提供了钩子参数，在建立连接时直接传入即可，这是最稳妥的方式：

import sqlite3

# Python 3.12 之后支持参数
conn = sqlite3.connect("app.db")

# 兼容旧版本的通用写法：通过 setconfig 或直接执行
conn.execute("PRAGMA foreign_keys = ON")

# 验证是否生效，返回1表示开启
print(conn.execute("PRAGMA foreign_keys").fetchone())

Java的JDBC驱动会在每个新连接建立后自动执行PRAGMA foreign_keys=ON（sqlite-jdbc驱动5.x版本起默认启用），如果想显式控制，可以通过连接属性设置。Go语言的mattn/go-sqlite3驱动则支持在DSN里加参数：

db, err := sql.Open("sqlite3", "app.db?_foreign_keys=on")
if err != nil {
    log.Fatal(err)
}

把配置写在DSN里有个明显好处：连接池创建的每一条连接都会自动带上这个参数，不存在遗漏某条连接的可能。相反，如果是自己在业务代码里执行PRAGMA语句，很容易因为连接池复用而漏掉。无论用哪种语言，建议在应用启动时加一条验证逻辑，查询PRAGMA foreign_keys的返回值，确认配置真的生效了再对外提供服务，这样能把环境问题挡在最前面。

总结

PRAGMA foreign_keys虽然只是一条简单的开关命令，但会话级生效和事务内失效这两个特性让它在实际项目中坑点频出。记住三件事：连接建立时立即开启、不要在事务内执行、存量数据先用foreign_key_check体检。配合合理的级联策略，SQLite完全可以承担起严格的引用完整性保护，不用再靠应用层代码去手工维护关联关系了。

PRAGMA foreign_keysSQLite外键约束ON DELETE CASCADE修改时间：2026-09-03 06:28:32