把生产库里一张用户表的数据导出成能直接跑的 INSERT 语句这个需求听起来简单真动手做的时候往往会在半路翻车中文变成问号、时间少了几毫秒、几百万行的脚本导入到一半报类型转换错误。我在几次数据交付和跨环境同步里反复踩过这些坑最后一次是把一张 270 万行的用户主表从线上导到一台隔离环境的实例前后改了四版生成脚本才跑通。这篇就把这套SQLServer 用户表数据导出为 Insert 语句的完整做法从头到尾拆一遍从工具生成的傻瓜路径到自己写 T-SQL 拼装的硬核方案再到导入侧怎么验证数据没走样都会给出可直接抄的代码和参数。适合手上有数据搬运任务但不想用备份还原的开发者也适合刚接触 T-SQL 动态拼接、想搞清楚类型转换细节的朋友。1. 先想清楚把表数据变成 INSERT 语句究竟在解决哪一类搬运难题在动手写代码之前值得先花五分钟判断这件事该不该用 INSERT 脚本来做。因为很多人第一反应是数据搬运嘛备份还原或者导入导出向导不就完了但真正用过之后会发现那些方案在某些场景下根本走不通或者代价远超预期。1.1 三个最常触发这个需求的现场第一个现场是交付初始化数据。某个系统上线要带一批基础配置或者某个演示环境需要一份能反复重建的样例数据。这种情况下你要交给对方的不是一堆物理文件而是一段打开就能执行的文本对方在自己的实例上跑一遍就有了。备份文件做不到这一点因为它绑定了版本、绑定了文件路径还带着整个库的上下文。第二个现场是跨版本、跨实例的小批量同步。两台实例之间不一定网络相通中间可能还要经过文件摆渡、审批拷贝之类的人工环节。这种情况下一段纯文本的 SQL 脚本是最容易通过审查、最容易人工比对、也最容易回滚的载体出问题了一眼就能看出是哪行数据不对。第三个现场是问题定位与复现。线上某条用户记录状态异常你要把它复制到测试环境里重现问题。直接 SELECT 出来贴成 INSERT是最快的方式比建临时表、导文件、再导入快得多。这类场景数据量很小但对保真的要求极高——少一个字符、少一位小数可能就复现不出来。1.2 为什么文本脚本至今没有被备份文件取代从技术上说备份还原确实更完整、更快、更保真。但它有个绕不开的短板备份是整个数据库级别的黑盒你没法只挑一张表、几列数据、几行记录。而生成 INSERT 脚本可以做到精确到列、精确到行、精确到值。再有一点是可审阅性。文本脚本是白的你能用任何编辑器打开、diff、合并、手工改两行。数据交付场景里接收方往往需要确认你到底给我塞了什么脚本是他们唯一能看懂的形式。我在一个涉及用户手机号脱敏的项目里就吃过亏本来打算直接给备份结果对方的安全流程要求逐条审阅数据内容最后只能退回脚本方案顺便还得在生成阶段就把敏感列做替换。所以判断标准很清晰数据量在几十万行以内、需要人工介入、需要跨环境手工搬运、需要精确控制范围——这四类情况INSERT 脚本就是最优解。超过这个量级就该认真考虑 bcp、导入导出向导或者直接走备份了。2. 四条实现路径的真实取舍以及选型时最容易被忽略的两条约束明确了要做接下来是选工具。市面上能完成SQLServer 表数据转 INSERT 语句的路径大致有四条各自的脾气完全不同选错了会在中途返工。2.1 能力边界对照路径上手成本保真度大数据量表现可控性管理工具生成脚本向导极低中高特殊类型偶有偏差生成慢百万行级容易卡死低只有几个开关手写 T-SQL 拼装中需要懂元数据视图高每列都能定制好可分批、可直出文件极高sqlcmd/bcp 结合查询输出中取决于查询写法好高应用代码层读取后拼串中高取决于类型映射一般受驱动和内存限制高但维护成本大管理工具那条路是最多人第一次会走的右键表、写脚本、选数据几十秒出结果。它的短板在于完全不透明你没法指定某个 datetime2(7) 列要保留几位小数没法控制 float 是否用可逆格式输出也没法把上百条单行 INSERT 合并成批量 VALUES。数据量一旦上到几十万行向导会在生成阶段就开始吃内存机器不够好直接卡住。应用代码层那条路我不太推荐。看着灵活实际上每个数据库驱动对类型的映射规则都不一样decimal 的精度、datetime 的时区、binary 的十六进制表示每一处都可能是静默失真的来源。而且这类脚本写完基本只有作者能维护换个人接手就是灾难。真正值得投入的是后两条用 T-SQL 在数据库内部生成语句文本然后通过命令行工具把结果集落地成文件。前者负责保真后者负责性能和稳定。这个组合我在百万行级别验证过是可控性和效率平衡得最好的方案。2.2 决定选型的两条隐性约束第一条是输出通道的字符截断限制。这一点几乎所有人都踩过你精心拼好了一条两万字符的 INSERT 语句在管理工具里执行查询结果集网格里显示完整但你用另存为导出成文件打开一看只有前 8192 个字符。命令行工具也一样默认对变长字段的显示宽度有上限超过就截断而且不报错。这个限制不搞清楚导出的脚本会带着残缺数据一路流到目标库。第二条是编码与排序规则的匹配。生成出来的脚本最终要以文件形式存在文件的编码决定了中文、日文、特殊符号能否原样保留。管理工具另存为时默认跟随系统区域设置在某些环境里就是 GB 系编码一旦目标库的排序规则不同或者脚本被传到一台语言设置不一样的机器上打开中文就会变成乱码。正确做法是统一按 UTF-8带 BOM或 UTF-16 保存同时在生成的每个字符串字面量前加N前缀。这两条约束都不是性能优化而是能不能用的问题。选型阶段把它们排在最前面考虑后面的坑能少一半。3. 管理工具生成脚本五分钟出活但成败全在几个勾选项虽然我最终推荐自己写生成器但工具路径该讲清楚——大量中小场景下它确实够用只是必须知道哪几个选项决定了成败。3.1 完整操作路径与勾选顺序最快的入口不是那个生成脚本向导而是直接在对象树里右键表编写表脚本为 → INSERT 到 → 新查询编辑器窗口。这条路径会跳过向导的一堆页面直接吐出一段针对单表的 INSERT 脚本。但这条快捷路径有几个默认行为需要提前知道它默认只生成表结构加数据也就是先 CREATE TABLE 再一堆 INSERT如果你只需要数据部分得手工把前面那段删掉。它默认不包含标识列的显式值也就是说如果表有自增主键生成的 INSERT 语句里根本不会出现主键列导入后主键会重新编号行与行之间的关联关系就断了。它对大文本列的处理默认走非 Unicode 路径中文有可能丢。所以要拿到合格的产物更稳的做法还是走完整向导右键数据库 → 任务 → 生成脚本 → 选择特定对象 → 勾选目标表 → 在设置脚本编写选项里点高级。页面不多但每一步都有讲究。3.2 高级选项里那几个开关的真实后果高级选项列表很长真正和导数据相关的就那么四五个其余都是结构相关的可以忽略。选项默认值建议值影响编写数据的脚本FalseTrue不开这个导出的只有空表结构要编写脚本的数据的类型仅限架构仅限数据只导数据时选这个避免重复建表报错转换为 UnicodeFalseTrue决定字符串前是否加 N 前缀中文必备为服务器版本编写脚本当前版本目标库版本跨版本导入时必须调低否则语法不兼容包含 IF NOT EXISTSFalse按需重复执行脚本时避免主键冲突报错转换为 Unicode这一项最容易被忽略因为它藏得深而且不开也不一定立刻出错——只有当数据里出现中文、日文、或者生僻符号时才会暴露。我见过一次交付脚本在源机器上跑得好好的拷到另一台机器上执行所有中文用户名全部变成问号排查了半天才发现是这一步没勾。还有为服务器版本编写脚本如果目标库是较低版本而源库用了较新语法生成的脚本会带着不兼容的写法过去执行时报语法错误。这个错误信息往往指向一个看起来很无辜的位置很容易误判成数据问题。提示用工具生成后务必先拿脚本在目标环境的一个空表上试跑一遍别直接往有数据的表里灌。试跑能用最小成本暴露编码、版本、标识列这三类问题。向导的另一个隐性代价是行数上限。它内部是按批处理的几十万行还能撑住但生成过程会持续占用内存机器配置一般的话中途失败的概率不低而且失败时往往只给一句笼统的错误不告诉你是哪一行出的问题。这也是我后面转向自写生成器的直接原因。4. 手写 T-SQL 生成器把每一列的类型差异逐条啃掉自己写的核心思路其实不复杂查系统元数据拿到表的列清单和类型针对每一列拼出一段把这个值转成 SQL 字面量的表达式最后用这些表达式组装成完整的 INSERT 语句。难点全在转成 SQL 字面量这一步——不同类型有不同规则稍不注意就是静默失真。4.1 从元数据到语句文本的骨架第一步是拿列信息。sys.columns联合sys.types就能拿到列名、类型名、长度、精度、是否可空、是否标识列、是否计算列。IF OBJECT_ID(tempdb..#Cols) IS NOT NULL DROP TABLE #Cols; SELECT c.column_id, c.name AS col, t.name AS typ, c.max_length, c.precision, c.scale, c.is_nullable, c.is_identity INTO #Cols FROM sys.columns AS c JOIN sys.types AS t ON t.user_type_id c.user_type_id WHERE c.object_id OBJECT_ID(Ndbo.Users) AND c.is_computed 0 AND t.name NOT IN (Ntimestamp, Nrowversion) ORDER BY c.column_id;这里有两个过滤条件必须加。is_computed 0排除计算列因为计算列不能出现在 INSERT 的列清单里硬塞进去直接报错。timestamp/rowversion这两种类型也是同理它们是数据库自动维护的版本戳不允许显式插入。拿到列清单后第二步是给每列生成值转字面量的表达式。用一个 CASE 按类型族分派输出的是字符串形式的 SQL 片段后面再拼起来动态执行。SELECT col, CASE WHEN typ IN (Ntinyint, Nsmallint, Nint, Nbigint) THEN NCAST( QUOTENAME(col) N AS varchar(20)) WHEN typ Nbit THEN NCAST( QUOTENAME(col) N AS varchar(1)) WHEN typ IN (Ndecimal, Nnumeric, Nmoney, Nsmallmoney) THEN NCAST( QUOTENAME(col) N AS varchar(50)) WHEN typ IN (Nfloat, Nreal) THEN NCONVERT(varchar(50), QUOTENAME(col) N, 3) WHEN typ IN (Ndate, Ndatetime, Ndatetime2, Nsmalldatetime, Ntime) THEN NCONVERT(varchar(40), QUOTENAME(col) N, 126) WHEN typ Ndatetimeoffset THEN NCONVERT(varchar(50), QUOTENAME(col) N, 127) WHEN typ Nuniqueidentifier THEN NCAST( QUOTENAME(col) N AS varchar(36)) WHEN typ IN (Nbinary, Nvarbinary, Nimage) THEN NCONVERT(varchar(max), QUOTENAME(col) N, 2) ELSE NCONVERT(nvarchar(max), QUOTENAME(col) N) END AS expr FROM #Cols;注意ELSE分支把所有字符类型char/varchar/nchar/nvarchar/text/ntext/xml 等都兜住了统一转成 nvarchar(max)。这样做的好处是处理逻辑只有一套坏处是大文本列会占用较多内存后面讲分批时会提到怎么缓解。4.2 字符串、日期、二进制三类难缠数据的转写规则字符串的关键是两件事加N前缀把单引号翻倍。SQL 里字符串字面量的转义规则只有一个——单引号本身用两个单引号表示。所以REPLACE(col, , )就是全部。写成可读的形式是这样CASE WHEN col IS NULL THEN NULL ELSE NN REPLACE(CONVERT(nvarchar(max), col), N, N) N END这里的写法容易看晕拆开看NN是开头产出一个N中间是转义后的内容N是结尾产出两个单引号也就是一个结束引号加上语句自身的引号。我第一次写的时候少打了一个引号生成的脚本永远是奇数个引号执行时一路报语法错误找了好久。有人会问能不能用STRING_ESCAPE这个内置函数。答案是不能至少不能直接用。这个函数转义的是 JSON、HTML 这类格式里的特殊字符对单引号的处理规则和 T-SQL 字面量完全不同用在生成 INSERT 语句上只会更乱。日期时间的核心诉求是不受目标库语言设置影响。2024-03-05这样的字面量在某些语言设置下会被解释成3 月 5 日在另一些设置下是5 月 3 日这取决于SET LANGUAGE和SET DATEFORMAT的当前值。要绝对安全就用yyyy-mm-ddThh:mm:ss.mmm这种带 T 的 ISO8601 格式也就是CONVERT(..., 126)。带时区的datetimeoffset用 127它会附上完整的偏移量。date和time类型用 126 也没问题会输出对应的短格式。二进制的规则是输出0x加十六进制串。CONVERT(varchar(max), col, 2)给出的是不带前缀的纯十六进制所以拼的时候要在前面手工补上0x。浮点数必须用CONVERT(varchar(50), col, 3)style 3 是科学计数法且可完整往返的格式。如果直接用CAST或者默认转换位数会被截断导回去的值和原值差最后几位。这种差异在小数点后十几位才体现肉眼几乎看不出来但如果这个字段参与后续计算或做校验和比对就会炸。需要注意的是style 3 是在较新版本才支持的老版本得用 style 2。4.3 REPLACE 的先后顺序一步错就全盘错如果字符串里含回车换行直接原样放进 INSERT 语句是合法的——字符串字面量内部可以跨行。但生成出来的脚本会变得极难阅读一行数据占好几行还没法用行号定位。所以通常会把这些不可见字符替换成CHAR(13)、CHAR(10)这样的拼接表达式。这里有一个非常隐蔽的顺序坑。下面两种写法的结果完全不同-- 错误顺序先转换行再转引号 REPLACE(REPLACE(col, CHAR(13), CHAR(13) ), , ) -- 正确顺序先转引号再转换行 REPLACE(REPLACE(col, , ), CHAR(13), CHAR(13) )错误的写法中第一步先把回车替换成了 CHAR(13) 这段文本里面本身就带着引号第二步的引号转义会把这几个引号也翻倍最终产出的是 CHAR(13) 导入时分段就错了数据里会平白多出引号字符。正确的顺序是先处理所有需要转义的引号再去替换换行符——此时替换插入的新引号片段不会再被二次处理。同理如果有多个特殊字符要处理顺序必须是单引号 → 回车 → 制表符 → 其他。单引号永远第一个因为它会影响后续每一步的字符串边界。4.4 空值、标识列、计算列、行版本的排除逻辑NULL 和空字符串必须严格区分。这是导入后对不上账的最常见原因之一。空字符串转出来是NNULL 转出来必须是裸的NULL中间不能有引号。写法上就是前面那个 CASE先判断IS NULL是就输出NULL文本否则才走引号包裹分支。对于非字符串类型CAST出来的 NULL 会参与字符串拼接导致整行结果变成 NULL。所以非字符串表达式外面还要套一层ISNULL(expr, NULL)。这个细节我最初漏掉了结果整张表里只要有一个可空数值列是空的那条 INSERT 就整行消失行数对不上还找不到原因。标识列的处理分两种情况。如果不关心主键的具体值目标表是空表、没有外键引用那就干脆把标识列从列清单里排除让它重新生成。如果要保留原值就必须显式列出该列并在脚本前后加上SET IDENTITY_INSERT dbo.Users ON; -- 一堆 INSERT SET IDENTITY_INSERT dbo.Users OFF;有两点要注意IDENTITY_INSERT同一时刻只能对一张表生效多表导出时必须成对出现不能全部打开再统一关闭另外这两条语句必须和 INSERT 在同一个会话里如果中间插了GO会话上下文不会断但如果脚本被拆到不同连接执行就会失效。计算列和行版本列在前面的元数据查询里已经过滤掉了。但还有一类容易漏的带有DEFAULT约束的列。如果原值是 NULL而你生成的是DEFAULT关键字导入后这个 NULL 会被默认值填掉数据就变了。所以可空列一律用NULL不要用DEFAULT。5. 把逐行 INSERT 压成批 VALUES文件体积和导入速度一起救回来一行一条 INSERT 是最稳妥的因为出错时能精确定位到行。但它有两个明显缺点文件体积大每条语句都要重复一遍INSERT INTO 表名 (列清单) VALUES导入慢每条语句都要单独解析、编译、执行。5.1 表值构造器的上限与分组拼接思路SQL Server 从 2008 版本开始支持一条 INSERT 带多组 VALUES也就是表值构造器INSERT INTO dbo.Users (Id, UserName) VALUES (1, N张三), (2, N李四), (3, N王五);单条语句最多支持 1000 个元组超过就直接报语法错误。所以分组大小取 500 到 1000 之间比较稳妥取 500 留点余量避免因为个别行的表达式特别长而触到语句长度上限。分组拼接的实现思路是给每行编个组号再按组号聚合。用ROW_NUMBER除一下就行WITH src AS ( SELECT *, (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) - 1) / 500 AS grp FROM dbo.Users ) SELECT NINSERT INTO dbo.Users (Id, UserName, CreatedAt) VALUES STRING_AGG(N( CAST(Id AS varchar(20)) N, N REPLACE(UserName, N, N) N, CONVERT(varchar(30), CreatedAt, 126) N), N,) N; FROM src GROUP BY grp;STRING_AGG是较新版本才有的聚合函数老版本得用FOR XML PATH加STUFF的经典套路来模拟写法更啰嗦但效果一样。ORDER BY (SELECT NULL)的意思是我不关心行的顺序这样能避开排序开销如果目标表有聚集索引、希望导入时顺序写入减少页分裂可以改成按主键排序。批 VALUES 相比单行 INSERT文件体积通常能压到三分之一左右导入速度提升更明显——在本地测试里同样 50 万行数据单行模式导入耗时约 4 分半批模式约 50 秒。5.2 分批与 GO 分隔的实操参数即便用了批 VALUES整张表一次性生成一个巨大文件也不是好主意。文件太大编辑器打不开出错了也没法局部重跑。合理的做法是按固定行数切段每段之间插一个GO。GO不是 T-SQL 关键字它是客户端工具识别的批分隔符。加它的实际作用是控制编译单元的大小。一条包含几千个 INSERT 的脚本如果不分批客户端会尝试整体发送内存占用和编译时间都会飙升而且一旦中间某条出错回滚范围不可控。切段大小的经验值场景每段行数理由小表万行以内2000文件不至于太碎出错定位粒度够用中等表十万级5000平衡编译开销和单段体积大表百万级10000减少 GO 数量降低客户端调度开销另外每段开头加上SET NOCOUNT ON;能减少返回的影响行数消息导入过程能快不少。段与段之间不要套事务整表一个事务会让日志文件暴涨反而更慢。如果确实需要原子性按段提交出问题就整段重来。6. 百万行导出的性能账瓶颈不在 SQL而在结果集的落地方式很多人以为是拼接 SQL 太慢实际测下来完全不是这么回事。生成语句本身的 CPU 开销在百万行级别也就几十秒真正拖时间的是结果集怎么从数据库出来、又怎么落到磁盘上。6.1 拼接本身的成本在哪拼接的主要开销来自三个方面一是每行的多次REPLACE字符串越长开销越大二是类型转换尤其是CONVERT(nvarchar(max), ...)对 text/ntext 这类大对象类型的处理三是排序如果用了ORDER BY或者ROW_NUMBER带排序会额外占用 tempdb。第一项基本优化不了除非放弃逐字符处理。第二项可以通过在元数据阶段就排除掉不需要导出的列来缓解——比如那些巨大的日志文本列、base64 图片列如果目标场景根本用不上直接不导省下的时间很可观。第三项则是明确可以避开的如果不需要保证行顺序就别排序。还有一点SELECT出来的结果在客户端是以行集形式传输的每行一条记录。行数越多网络往返和客户端反序列化的开销越突出。这个开销和 SQL 内部拼接完全无关但用户感知到的卡主要来自这里。6.2 输出到文件的三个关键参数绕开客户端反序列化最有效的办法是用命令行工具直接把查询结果重定向到文件跳过任何图形界面。核心参数有三个任何一个漏了都会出问题。sqlcmd -S 实例地址 -d 数据库名 -E \ -i generate.sql -o output.sql \ -y 0 -Y 0 -h -1 -W -f 65001-y 0和-Y 0分别控制变长和 Unicode 类型的显示宽度设成 0 表示不限制。这是最容易漏的参数——默认值只有 256超过就静默截断一行长文本被砍成前 256 个字符看着脚本能执行数据就是残缺的。需要注意-y 0的实际封顶是 8000超过 8000 字符的单个值仍然会被截遇到这种情况得在生成阶段就把它拆成多个字符串拼接表达式。-h -1去掉列标题-W去掉尾部补的空格。这两个不加的话输出文件里会多出一行标题和大量填充空格虽然不影响执行但文件体积会无谓地膨胀。-f 65001指定输入输出都用 UTF-8 编码。这一步保证中文能原样写进文件。如果目标库的排序规则和你生成时的环境不同这个是保命的参数。注意-f指定的编码必须和后续打开文件的编辑器一致否则会出现用 UTF-8 写入、用 GB 系打开的经典乱码。生成完成后用不带 BOM 的方式开局会比较稳。还有一个细节sqlcmd 默认启用了-b之外的一些行为遇到错误时可能只打印错误继续往下跑。建议加上-b让它在遇到严重错误时返回非零退出码并立即终止避免带着残缺数据一路跑完。7. 导回去之后的验证链路怎么证明数据真的没走样脚本能在目标库执行成功不等于数据对了。类型转换、字符截断、NULL 与空字符串混淆这些问题都不会在执行阶段报错只会在数据里留痕。7.1 行数、校验和与双向差集最基础的三层验证从粗到细第一层比行数。源表COUNT(*)和目标表COUNT(*)是否相等。这一步能抓住大部分丢行问题但抓不住行数对了内容错了。第二层比校验和。如果两张表结构完全一致可以用CHECKSUM_AGG(BINARY_CHECKSUM(*))做一个整体指纹比对。它在整表层面给出一个数值相等说明大概率一致。缺点是不能定位到具体哪一行而且BINARY_CHECKSUM对某些类型比如大文本、xml支持不好需要先排除这些列。第三层比双向差集。这是最可靠的SELECT * FROM dbo.Users_src EXCEPT SELECT * FROM dbo.Users_dst; SELECT * FROM dbo.Users_dst EXCEPT SELECT * FROM dbo.Users_src;两个方向都必须查。单向只能发现源有目标没有或者内容不同双向都为空才能确认完全一致。用EXCEPT有两个前提列的数量、顺序、类型必须能对应且不包含xml、image、text这类不可比较的类型。遇到这种情况就把那几列拿出来单独CAST成nvarchar(max)再比。如果数据量大双向差集跑得很慢可以先把两边都SELECT ... INTO到临时表再在临时表上比速度会快一些。7.2 报错定位的通用手法导入过程报错时最忌讳的是看到错误就去改数据。正确的顺序是先去定位是哪一行出的问题。用图形界面执行时错误信息里通常会带行号但这个行号是脚本文件的行号不是数据行号。如果用的是批 VALUES 模式一行脚本对应几百条数据光看行号没法定位。这时候要把那一段脚本单独拎出来改成单行 INSERT 模式一条条跑把范围缩到最小。常见的错误类型和对应根因错误提示根因处理方式将字符串转换为 datetime 时失败日期格式受 LANGUAGE 影响改用带 T 的 ISO8601 格式字符串或二进制数据将被截断目标列长度小于原列检查 DDL 是否一致或脚本被截断违反主键约束目标表已有数据或标识列重复先清表或用 IF NOT EXISTS 包裹不允许在计算列中插入值列清单里混入了计算列元数据查询时过滤 is_computed无法插入显式值到标识列有标识列但没开 IDENTITY_INSERT加 SET IDENTITY_INSERT ON/OFF字符串截断这个错误特别值得单独说因为它有两种完全不同的成因。一种是目标表的列定义比源表短比如源表是nvarchar(200)导进了nvarchar(100)这个必须改表结构。另一种是脚本在生成或传输过程中被截断了比如前面提到的 sqlcmd 默认 256 字符限制这种是脚本本身残缺得回去改生成参数。8. 那些在导入时才炸出来的坑前面几节讲的都是怎么做对这一节讲哪些地方会做错还不自知。这些坑的共同特点是生成阶段不报错、执行阶段不报错、直到有人真的去查这条数据才发现不对。8.1 字符集、排序规则与 N 前缀中文乱码的根因通常有两层字符串字面量缺N前缀或者文件编码不对。两层问题症状一样但修法完全不同得分开排查。如果脚本里是张三而不是N张三那么在非 Unicode 环境下这个字面量会先按当前代码页解释成字节再插入目标列。源库代码页和目标库代码页一致时看不出问题一旦跨过去就是问号。所以生成阶段无条件加N是最省事的做法哪怕目标列是 varchar——加了 N 之后插入 varchar 列会做隐式转换值本身不会变。如果脚本里已经有N前缀但文件保存成了 GB 系编码再在 UTF-8 环境下打开同样会乱。这时候要检查文件的编码标记。用一个支持显示编码的编辑器打开看右下角显示的是 UTF-8 还是 GB2312。管理工具另存为对话框里有个编码下拉框默认值跟着系统走一定要手动改成 UTF-8。还有一层更隐蔽的排序规则不同的列在比较和排序时行为不同。如果脚本里带了WHERE条件或者ORDER BY跨排序规则执行可能得到不同的结果。不过纯粹的 INSERT 语句不受这个影响可以暂时不管。8.2 时间精度、位类型与浮点数的静默失真时间精度是最容易被忽视的。datetime的精度是 3.33 毫秒datetime2(7)是 100 纳秒。如果源列是datetime2(7)而你用CONVERT(varchar(23), col, 121)转出来只保留到毫秒后面四位就丢了。这种丢失去看数据是看不出来的因为差的是 0.0001 毫秒级别但如果是做时间戳比对或者有唯一性约束就会出问题。正确做法是按目标精度给足长度datetime2(7)用CONVERT(varchar(40), col, 126)让 126 输出完整的 7 位小数。位类型的坑在于显示形式。有些工具在结果集里把 bit 显示成True/False但真正的CAST(bit_col AS varchar(1))输出的是1/0。如果你手工复制结果集里的文本去拼脚本复制到的是True那插进去就报类型转换错误。所以必须用CAST显式转换不能依赖显示层的格式化。浮点数前面提过这里补充一点real是单精度float是双精度两者的可逆转换格式略有差异。real用 style 3 转换后可能带E00这样的指数形式插入时能正确解析但如果目标是decimal列指数形式会转换失败。这类跨类型的场景必须手工指定转换规则不能指望自动。8.3 大文本被截断的三种成因第一种是客户端显示宽度限制。sqlcmd 的-y/-Y参数、管理工具结果网格的 65535 字符上限、以及以文本格式显示的 8192 上限三处都能截。对策就是前面说的-y 0 -Y 0加上直接输出到文件绕开任何显示层。第二种是生成表达式本身的长度限制。有些环境里CONVERT(nvarchar(max), col)在拼接时被隐式降级成nvarchar(4000)超过的部分直接被砍。对策是在拼接时显式声明CAST(... AS nvarchar(max))确保类型不被降级。这个行为在不同版本上表现不完全一致建议在生成后挑几条最长的记录验证一下尾部字符是否完整。第三种是文件系统或传输环节的截断。生成的脚本文件特别大时某些传输方式比如通过聊天工具、邮件附件会对单文件大小做限制处理不当就会得到个残缺文件。这种情况没法在技术上防只能靠导入前先核对文件行数和末尾内容。一个实用的自检方法在生成脚本的最后追加一行特殊标记比如-- END OF EXPORT。导入前打开文件拉到最末尾看这行在不在。在说明文件完整不在说明中途被截了别急着执行。我在那个 270 万行的项目里就用这个方法救过一次——传输环节把一个 400 多兆的文件截成了 300 兆因为末尾标记缺失第一时间就发现了没有被残缺数据污染目标库。后来我养成了一个习惯任何超过十万行的导出生成脚本的最后一行必须是可识别的结束标记同时记录总行数导入前先比对。这个做法看着土实际非常有效比任何复杂的校验流程都直接。