插入值超列长度时SQL Server表存入错误值的问题排查

看起来你已经把常规排查路径都走了一遍，这种“悄无声息修改数据”的情况确实头疼，我来帮你梳理几个容易被忽略的SQL Server组件，说不定问题就藏在这里：

1. 被遗漏的特殊触发器 #

你说已经检查过触发器，但有没有可能是INSTEAD OF触发器或者CLR触发器？

• INSTEAD OF触发器会直接替代你的INSERT操作，执行它自己的逻辑，有时候排查容易把它漏掉。你可以跑下面的SQL看看表上有没有这类触发器：

  SELECT name, type_desc
  FROM sys.triggers
  WHERE parent_id = OBJECT_ID('[dbo].[Values]')
  

• 要是触发器是用.NET写的CLR触发器，常规的触发器列表里不会直接显示，得查系统视图找CLR相关的模块：

  SELECT t.name AS trigger_name, am.assembly_class
  FROM sys.triggers t
  JOIN sys.assembly_modules am ON t.object_id = am.object_id
  WHERE t.parent_id = OBJECT_ID('[dbo].[Values]')
  

2. 绑定到自定义数据类型的规则（Rule） #

你提到code列是自定义数据类型，虽然你觉得它只是对应char(8)无额外逻辑，但有可能这个自定义类型绑定了一个规则（Rule），而规则里藏着截断后替换为*的逻辑？可以用下面的SQL检查：

SELECT r.name AS rule_name, c.name AS column_name, t.name AS type_name
FROM sys.rules r
JOIN sys.columns c ON r.object_id = c.rule_object_id
JOIN sys.types t ON c.system_type_id = t.system_type_id
WHERE c.object_id = OBJECT_ID('[dbo].[Values]') AND c.name = 'code'

3. 服务器/数据库级的全局触发器 #

除了表级触发器，还有可能存在数据库级甚至服务器级的DML触发器，它们会监听所有符合条件的INSERT操作，悄悄修改数据。你可以跑这两个查询排查：

-- 检查数据库级DML触发器
SELECT name, type_desc
FROM sys.triggers
WHERE parent_class_desc = 'DATABASE' AND type_desc LIKE '%DML%'

-- 检查服务器级触发器
SELECT name, type_desc
FROM sys.server_triggers

4. 封装插入逻辑的自定义存储过程 #

如果你的插入操作不是直接写INSERT语句，而是通过自定义存储过程执行的，那修改逻辑很可能藏在存储过程里。你可以查一下所有涉及这个表的存储过程：

SELECT p.name AS procedure_name
FROM sys.procedures p
JOIN sys.sql_expression_dependencies d ON p.object_id = d.referencing_id
WHERE d.referenced_id = OBJECT_ID('[dbo].[Values]')

5. 数据质量服务（DQS）的清理规则 #

如果你在用SQL Server的数据质量服务，说不定配置了针对这个表的自动数据清理规则，会在插入时自动修正值。可以去DQS的知识库和项目里，看看有没有针对code列的规则配置。

6. 行级安全（RLS）的自定义谓词（罕见） #

虽然行级安全主要用来过滤数据，但如果有人在RLS的谓词函数里写了奇怪的逻辑，也有可能意外修改数据（这不符合RLS的设计初衷，但不排除遗留系统里的骚操作）。可以检查下表上的RLS策略：

SELECT name AS policy_name
FROM sys.security_policies
WHERE object_id = OBJECT_ID('[dbo].[Values]')

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