SQL INSERT执行无报错但特定ID记录未插入表的调试排查方法

第一步：先做基础执行结果校验 #

不要依赖客户端"执行无报错"的提示判断结果，先做两个最基础的校验：

• 执行INSERT语句后立刻打印@@ROWCOUNT的值，确认语句实际影响行数。如果返回值为0，说明INSERT逻辑根本没有写入行；如果返回值为1但后续查询找不到记录，再往下排查。
• 强制走全表扫描查询目标记录，绕过所有非聚簇索引：

-- 物理表用这个语句，强制扫描基表
SELECT * FROM 你的业务表 WITH(INDEX(0)) WHERE ID = 1235

如果全表扫描能查到记录，普通查询查不到，直接定位为索引损坏问题。 #

常见根因与对应排查方案 #

• 非聚簇索引损坏
  这是特定值插入"消失"的最高频原因：数据行已经写入基表数据页，但ID列上的非聚簇索引页损坏，没有写入对应条目，当查询优化器选择走这个非聚簇索引找ID=1235的记录时，自然返回空结果。
  验证方式就是上面的强制全表扫描查询，确认后直接执行索引重建即可修复：

  -- 重建表上所有索引
  ALTER INDEX ALL ON 你的业务表 REBUILD WITH (ONLINE = ON)
  

  注意：你测试用的表变量是临时对象，正常不会出现索引损坏，如果表变量场景也复现，检查是不是测试脚本的批处理分隔符问题——表变量作用域仅在当前批，如果你在INSERT和SELECT之间加了GO关键字，查询时访问的已经是新的空表变量，不是之前插入数据的那个。
• 静默回滚的逻辑分支
  检查两个层面的回滚逻辑：
  1. 外层业务存储过程/脚本有没有写条件判断，比如IF @ID = 1235 ROLLBACK TRANSACTION这类分支，触发回滚但没有抛出任何错误提示。
  2. 表上有没有建INSTEAD OF INSERT触发器，触发器内部写了针对特定ID值跳过插入的逻辑，且没有抛出错误。可以临时禁用触发器后做插入测试验证。
• 行级安全(RLS)策略过滤
  如果数据库开启了行级安全功能，检查安全策略内的过滤函数，是否存在规则把ID=1235的记录对当前登录账号屏蔽了，部分配置错误的RLS策略会允许插入记录，但插入后当前账号没有读取权限，看起来就像插入没生效。可以用sysadmin最高权限账号强制全表扫描验证。
• 上层传参类型错误
  如果是业务应用代码调用的插入逻辑，检查传入参数的类型配置，比如把INT类型参数错配成了字符串类型，传入的内容带不可见控制字符，隐式转换后实际写入的ID值不是你看到的1235。直接在SQL端用变量赋值写原生INSERT语句测试，就能排除上层传参的问题。

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