数据库完整性返回ok，渠道关联却找不到父记录，怎样区分物理检查和引用检查

integrity_check返回ok，只说明它覆盖的数据库结构检查没有发现问题，不能排除外键孤儿。已声明引用关系的表还应运行foreign_key_check，并针对返回的子表、行号和父表定位数据。

固定检查对象为脱离业务的导入副本

物理结构损坏与关系引用缺失是不同层次。一个完整可读的子表完全可以指向不存在的父记录，尤其是在迁移、手工导入或外键检查关闭期间。重新开启外键后，历史孤儿也不会神奇地被补齐；应检查已存在的数据，而不是只看开关当前值。

构造物理正常但引用无效的反例

附件在专用内存库声明父子表，关闭外键导入子表第一行、父ID99，然后开启外键。integrity_check给出ok，foreign_key_check明确返回child、行1、parent与外键序号。补入对应父记录后再查为空，形成修复前后的对照，而不是把一条异常截图当成结论。

foreign_key_check的最后一个数值用于区分子表中哪条外键约束，不是父记录ID。存在多个引用时，应结合建表定义核对，避免修错关系。演示补父记录只是一种可验证修复，现场还可能应该纠正子记录；必须依据真实数据来源选择，不能一律补造父对象。

核心表达式（完整建表与输入见附件）：

PRAGMA integrity_check;
PRAGMA foreign_key_check;

说明没有声明外键的业务关系需另查

真实修复究竟补父记录、改引用还是删除无效子记录，需要业务来源支持，不能为了让检查结果变空就随意造数据。未声明的逻辑关联、金额守恒和租户归属不在该PRAGMA自动覆盖范围内；两项检查都通过，也不代表所有业务语义正确。

适用范围：不读取生产库，不把两类PRAGMA合称全部业务正确性；只演示已声明引用。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

运行后将integrity_check、foreign_key_check与after_repair三项并排看。第一项ok不会让第二项消失，补入演示父记录以后第三项才为空。检查真实库前应先确认有哪些已声明外键和历史导入规则；如果本来没有声明引用，foreign_key_check没有结果也不能据此推断逻辑关联全部完整。

Python3.8以上及标准库；使用Python自带SQLite。程序不读取现有网关数据库，全部样本写入内存或新建临时目录，执行完自动清理；没有任何模型API调用。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对SQLite integrity_check foreign_key_check，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（integrity_check不检查外键错误；foreign_key_check返回违反引用的行；freelist_count用于空闲页。）；一手依据2（复合外键要求父子列组对应；每个连接须显式开启并核查foreign_keys，事务内切换无效。）。

继续阅读：用量表的整数列混进unknown，怎样在SQLite入库时拦住脏类型；渠道配置改成功却没留下审计记录，怎样把两次写入放进同一事务；New API 升级前备份了，怎样演练一次真正可用的恢复。