简介这套C#开发的SQL Server自动建表工具面向需要批量建表或处理中文表字段的.NET开发者与数据库管理员。程序通过读取文本文件解析列名与类型自动生成并执行CREATE TABLE语句同时支持将中文字段名转换为拼音首字母便于跨语言系统兼容适用于数据导入、系统初始化等场景。压缩包共30个文件体积约971KB包含7个C#源码文件、3个配置文件、3个动态库及3个可执行程序另有资源文件与项目解决方案可直接还原打开或运行查看。源码中展示了ADO.NET的SqlConnection与SqlCommand连接执行方式以及拼音首字母转换的具体实现方便二次开发。已有1430人学习浏览这份资料。通过完整工程可快速掌握C#连接SQL Server、解析文本生成建表语句、处理中文元数据等关键代码减少手工建表重复操作提升数据库初始化效率。1. 数据库自动建表解决的不只是省手写 SQLC# 与 SQLSERVER 的增量建表方案数据库自动建表就是让 C# 程序读一份表结构定义自动生成 CREATE TABLE 并执行到 SQLSERVER 上不再人肉去写建表脚本。我做上位机交付时被这事反复折磨每台客户端都要先手动跑建表 SQL漏跑一个字段就现场报错。后来把建表做成程序启动时的自动动作再没让实施同事碰 SQL。这套方案解决的是开发、测试、生产多套环境之间表结构漂移的问题你只维护一份 C# 表定义发布时程序自己检查、自己建、自己补。适合三类人——写 C# 管理系统和上位机的中小团队、做数据库同步工具想搭 DDL 同步能力的开发者以及拿 C# 做数据库课程设计的学生。它不是黑科技本质是「把表结构当成数据来管理」。下文从模型设计、语句生成、增量更新到避坑按一条可复现的路径讲完。2. 把表结构当成数据C# 元数据模型驱动的自动建表设计2.1 为什么用元数据而不是 SQL 脚本加一个字段不用改三个地方常见做法是准备一堆 .sql 建表脚本发布时逐个执行。这个做法在前二三十张表、一两套环境时没毛病但规模一上来问题就明显了脚本由不同的人维护A 同事在开发库手敲了一列忘了同步脚本B 同事生产部署时两边对不上两份脚本没法直接 diff全靠肉眼更麻烦的是脚本没法跑第二次——CREATE TABLE 不带 IF 判断第二次必报错于是大家只能在脚本外面再套一层又一层的 IF NOT EXISTS越套越乱。我一般反过来做不维护 SQL 脚本维护一份 C# 的表结构定义元数据程序根据这份定义动态生成 SQL。这个思路和 EF Core 的 Code First 同源但自己写的优势是可控——不用背一整套 ORM 的迁移机制生成的 SQL 自己能读能改SQLSERVER 的特殊语法筛选索引、内存优化表、分区方案也编得进去。团队协作时加字段只改模型一处所有环境保持一致不会再出现「开发库有、脚本里没有」的字段。元数据驱动还有个隐藏收益同一份定义能生成多种产物。除了 CREATE TABLE还能生成 SELECT 列名列表、INSERT 参数占位、DTO 类乃至接口文档。数据库同步工具里常见的「结构比对」功能底层也是先拉取双方元数据再做差集。可以说自动建表只是这套元数据模型的第一个消费者后面接什么全看业务需要。2.2 建表模型四件套字段、约束、索引、外键的 C# 定义先给出能直接落地的模型类。我一般用四个类字段不多但覆盖了日常九成建表需求public class TableDefinition { public string Schema { get; set; } dbo; public string TableName { get; set; } public ListColumnDefinition Columns { get; set; } new(); public string? PrimaryKeyName { get; set; } // 显式命名不自动生成 public Liststring PrimaryKeyColumns { get; set; } new(); public ListIndexDefinition Indexes { get; set; } new(); public ListForeignKeyDefinition ForeignKeys { get; set; } new(); } public class ColumnDefinition { public string Name { get; set; } public Type ClrType { get; set; } // C# 类型决定 SQL 类型映射 public int? Length { get; set; } // 字符串/二进制用nvarchar(50) public int? Precision { get; set; } // decimal 用总位数 public int? Scale { get; set; } // decimal 用小数位 public bool IsNullable { get; set; } true; public bool IsIdentity { get; set; } public string? DefaultValue { get; set; } // 直接写 SQL 原文如 GETDATE() public string? Description { get; set; } // 可选生成文档或扩展属性 } public class IndexDefinition { public string IndexName { get; set; } public Liststring Columns { get; set; } new(); public bool IsUnique { get; set; } public bool IsClustered { get; set; } // 一个表只能有一个聚集索引 } public class ForeignKeyDefinition { public string ForeignKeyName { get; set; } public string ReferencedSchema { get; set; } dbo; public string ReferencedTable { get; set; } public Liststring Columns { get; set; } // 本表外键列 public Liststring ReferencedColumns { get; set; } // 引用表列 }逻辑说明ClrType 是关键字段决定第 3 章的 SQL 类型映射Length、Precision、Scale 用可空类型是为了区分「没设置」和「显式传了 0」——nvarchar(0) 在 SQLSERVER 里合法但没人想要decimal 不写精度默认 decimal(18,0)会把小数位全部砍掉。DefaultValue 我故意设计成 string直接把 SQL 原文写进去比如 DEFAULT GETDATE() 或 NEWID()这样不用在代码里为每种默认值写分支也方便支持特殊写法。参数说明PrimaryKeyName 和 IndexName 要求显式指定而不是自动拼出 PK_表名 这类名字。自动生成看着省事但表改名或从别的库导入时同名约束冲突会让人排查到怀疑人生显式命名在运维排错时能少猜很多。IsClustered 默认 false 也是刻意的——一个表只能有一个聚集索引默认开了容易埋雷。2.3 一张设备采集表的定义实例模型长什么样、预期 SQL 长什么样光有模型不好理解给一张真实感强的表。上位机场景经常是 PLC、西门子 OPC 采集完直接落库设备采集表 DeviceReadings 存温度和开关量var deviceTable new TableDefinition { Schema dbo, TableName DeviceReadings, PrimaryKeyName PK_DeviceReadings, PrimaryKeyColumns new Liststring { Id }, Columns new ListColumnDefinition { new() { Name Id, ClrType typeof(long), IsIdentity true, IsNullable false }, new() { Name DeviceCode, ClrType typeof(string), Length 50, IsNullable false, DefaultValue }, new() { Name Temperature, ClrType typeof(decimal), Precision 10, Scale 2 }, new() { Name SwitchState, ClrType typeof(bool), IsNullable false, DefaultValue 0 }, new() { Name ReadTime, ClrType typeof(DateTime), IsNullable false, DefaultValue GETDATE() }, new() { Name Remark, ClrType typeof(string), Length 200, IsNullable true }, }, Indexes new ListIndexDefinition { new() { IndexName IX_DeviceReadings_DeviceCode_ReadTime, Columns new Liststring { DeviceCode, ReadTime } } } };这段定义翻译成预期 SQL 大致是Id 是 bigint 自增主键DeviceCode 是 nvarchar(50) 非空且默认空字符串Temperature 是 decimal(10,2)SwitchState 是 bitReadTime 是 datetime2 默认取当前时间Remark 可空 nvarchar(200)最后在 DeviceCode ReadTime 上建非聚集索引。几个细节值得说。字符串列给了非空默认值 而不是 NULL后续代码读出来不会是 DBNull省掉一堆空值判断——数据库增删改查的代码里NULL 处理往往是 bug 高发区。DateTime 的默认值用 GETDATE() 而不是 C# 的 DateTime.Now保证时间由数据库生成多客户端时钟偏差不会影响数据。bool 映射 bit默认 0。这些不是唯一选择但都是生产环境检验过的习惯。3. 核心实现从 C# 表定义到 SQLSERVER 的 CREATE TABLE 生成3.1 C# 类型到 SQLSERVER 类型的映射表与映射函数模型建好第一个要写的函数是类型映射。下面是我常用的映射表C# 类型SQLSERVER 类型可带参数说明intint无32 位整数longbigint无自增主键常用shortsmallint无小范围整数stringnvarchar(n) / nvarchar(max)LengthLength 为空时走 maxboolbit无0 / 1decimaldecimal(p,s)Precision, Scale默认 decimal(18,2)doublefloat无对应 C# doublefloatreal无对应 C# floatDateTimedatetime2无比 datetime 精度高推荐Guiduniqueidentifier无配合 NEWID()byte[]varbinary(n) / varbinary(max)Length同上处理映射里最容易踩的是 string很多人一律映射成 nvarchar(max)但 max 字段不能建普通索引也占不了内存优化表。我的规则是 Length 有值就走 nvarchar(n)没有才走 max。另外那句「sqlserver 字符串转数字」的查询根源经常不在 SQL 端而在 C# 侧把数字用 string 存了映射出来是 nvarchar后续要么 CONVERT 要么隐性转换性能直接垫底。数据库里要存数值C# 侧就用 decimal/int别让类型映射替你背锅。映射函数我写成静态方法独立于建表生成器方便单测public static string MapToSqlType(ColumnDefinition col) { // 字符串Length 有值才走定长否则 nvarchar(max) if (col.ClrType typeof(string)) return col.Length.HasValue ? $nvarchar({col.Length.Value}) : nvarchar(max); if (col.ClrType typeof(int)) return int; if (col.ClrType typeof(long)) return bigint; if (col.ClrType typeof(short)) return smallint; if (col.ClrType typeof(bool)) return bit; if (col.ClrType typeof(DateTime)) return datetime2; if (col.ClrType typeof(Guid)) return uniqueidentifier; // decimal 必须带精度空合并给默认 18,2 if (col.ClrType typeof(decimal)) return $decimal({col.Precision ?? 18},{col.Scale ?? 2}); if (col.ClrType typeof(double)) return float; if (col.ClrType typeof(float)) return real; if (col.ClrType typeof(byte[])) return col.Length.HasValue ? $varbinary({col.Length.Value}) : varbinary(max); throw new NotSupportedException($未支持的类型映射: {col.ClrType}); }逻辑说明decimal 分支用空合并运算符给默认值Precision 没写就是 18 位总长、2 位小数这是金额和传感器数据的常规设置想用 decimal(10,2) 就显式传 Precision10。string 和 byte[] 用 HasValue 判断而不是大于 0 判断因为 Length0 属于用户传了但没传对走 nvarchar(0) 会在数据库端直接报错比静默转 max 更早暴露问题。参数说明函数入参只有 ColumnDefinition没有整张表是为了让映射保持纯函数——同样的列定义在任何表里都映射出同样的类型。将来要支持别的数据库把返回值改成三元组类型名、长度、精度再套一层方言适配即可函数本身的职责不用动。这也让类型映射可以被单独拉出来做单元测试。3.2 生成带存在性判断的 CREATE TABLE 语句最小可用实现有了映射函数下一步把 TableDefinition 拼成完整建表脚本。我习惯用 StringBuilder 逐行拼接列多了以后字符串插值会让人看不清逗号和括号谁跟谁配对。public static string GenerateCreateTable(TableDefinition table) { var sb new StringBuilder(); var fullName $[{table.Schema}].[{table.TableName}]; // 外层用 OBJECT_ID 做存在性判断保证脚本可以重复执行 sb.AppendLine($IF OBJECT_ID(N{fullName}, NU) IS NULL); sb.AppendLine(BEGIN); sb.AppendLine($ CREATE TABLE {fullName}); sb.AppendLine( (); var lines new Liststring(); foreach (var col in table.Columns) { // 拼接顺序类型 - IDENTITY - 空值约束 - DEFAULT顺序不能乱 var def $[{col.Name}] {MapToSqlType(col)}; if (col.IsIdentity) def IDENTITY(1,1); def col.IsNullable ? NULL : NOT NULL; if (!string.IsNullOrEmpty(col.DefaultValue)) def $ DEFAULT {col.DefaultValue}; lines.Add(def); } if (table.PrimaryKeyColumns.Count 0) { var pkName table.PrimaryKeyName ?? $PK_{table.TableName}; var pkCols string.Join(, , table.PrimaryKeyColumns.Select(c $[{c}])); lines.Add($CONSTRAINT [{pkName}] PRIMARY KEY ({pkCols})); } sb.AppendLine( string.Join(, Environment.NewLine , lines)); sb.AppendLine( );); sb.AppendLine(END); return sb.ToString(); }逻辑说明最外层用 OBJECT_ID(N[dbo].[表名], NU) 判断用户表是否存在这是 SQLSERVER 自带的原子判断比先查 meta 再拼脚本可靠。存在就不执行 BEGIN 内的建表逻辑实现了「跑第二次不报错」——这是自动建表最低限度的幂等性。列定义拼接顺序是类型 → IDENTITY → 空值约束 → DEFAULT这是 SQLSERVER 的语法顺序反过来写直接语法错误。参数说明PrimaryKeyName 没指定时用 PK_表名 兜底但我建议永远显式指定。表名一旦超过 60 个字符SQLSERVER 对标识符的截断会导致兜底约束名对不上运维排查时非常难受。另外 Environment.NewLine 在 Linux 容器跑 SQLSERVER 时会自动切换换行符如果生成的脚本要在 Windows 和 Linux 之间做文件 diff固定用 \r\n 更省事。3.3 执行建表连接、超时、批量并发的参数设置SQL 生成完执行本身不复杂但连接管理上有个容易忽略的点建表是 DDLCOMMAND_TIMEOUT 默认 30 秒在表很大或有锁等待时不够用我一般显式提到 60 秒以上。public static int ExecuteSql(string connectionString, string sql) { using var conn new SqlConnection(connectionString); conn.Open(); using var cmd new SqlCommand(sql, conn); cmd.CommandTimeout 60; return cmd.ExecuteNonQuery(); } public static void EnsureDatabase(string connectionString) { // 目标库不存在时先连 master 建库再回连业务库建表 var builder new SqlConnectionStringBuilder(connectionString); var dbName builder.InitialCatalog; if (string.IsNullOrEmpty(dbName)) throw new ArgumentException(连接串里必须带 InitialCatalog); builder.InitialCatalog master; ExecuteSql(builder.ConnectionString, $IF DB_ID(N{dbName}) IS NULL CREATE DATABASE [{dbName}]); }逻辑说明ExecuteNonQuery 返回受影响行数对 CREATE TABLE 来说通常是 0所以返回值只用来写日志不能拿它判断成败——判断成败看有没有抛 SqlException。EnsureDatabase 解决的是自动建表的上游问题目标数据库本身不存在时CREATE TABLE 会直接报「数据库不存在」先连 master、用 DB_ID 判断再建库是成本最低的兜底。参数说明用 SqlConnectionStringBuilder 拿库名而不是正则切连接串遇到密码里带分号或特殊字符才不会翻车。并发方面如果用 Task 并行建多张表注意别共享同一个 SqlConnection——SQLSERVER 的 DDL 会拿库级架构锁并行建表反而互相等待串行执行通常更快。这个血泪经验我在一次初始化 40 张表的任务里踩过并行改串行后总耗时反而降了三分之一。4. 增量更新让自动建表能跑第二次、能补已存在的表4.1 表存在性检查sys.tables 与 INFORMATION_SCHEMA 怎么选只支持「库是空的」的自动建表没有实战价值真实项目数据库里早就躺着几十张表。所以第二步是增量表不存在就建表存在就对比字段缺列补列缺索引补索引。第一步是查表是否存在有两个入口。sys.tables 目录视图是 SQLSERVER 自带速度快、信息全INFORMATION_SCHEMA.TABLES 是 SQL 标准接口换数据库平台比如对接 MySQL、达梦时迁移成本低。我的取舍是确定只跑 SQLSERVER 就用 sys 目录视图代码可能被拿去兼容别的库才用 INFORMATION_SCHEMA。做数据库同步工具时推荐用 INFORMATION_SCHEMA因为工具往往要对接多种数据库。public static bool TableExists(SqlConnection conn, string schema, string tableName) { using var cmd new SqlCommand( SELECT COUNT(*) FROM sys.tables t INNER JOIN sys.schemas s ON t.schema_id s.schema_id WHERE t.name tableName AND s.name schema, conn); cmd.Parameters.AddWithValue(tableName, tableName); cmd.Parameters.AddWithValue(schema, schema); return (int)cmd.ExecuteScalar() 0; }逻辑说明直接 COUNT 而不是 TOP 1因为只需要 bool 结果。连接 sys.schemas 是为了限定 schema——同一个表名在不同 schema 下可以共存dbo 和 staging 下各有一张同名表很常见。参数用 AddWithValue 在这里没问题DDL 场景下参数值都是自己代码里的字符串不涉及用户输入注入。参数说明AddWithValue 在需要长度的场景下可能推断出过长的 nvarchar导致索引失效但在这个 COUNT 查询里影响极小。较真的话可以换新 SqlParameter(tableName, SqlDbType.NVarChar, 128)。这段代码在数据库同步工具里我直接复用把 schema 和 tableName 改成配置读取就变成了「只检查不建」的只读模式。4.2 字段级增量更新读 sys.columns 生成 ALTER TABLE ADD表存在后对比现有列和期望列。核心是把 sys.columns 读出来构建一个字典再和模型里的 Columns 做差集。public static Dictionarystring, (string Type, bool IsNullable, bool IsIdentity) LoadExistingColumns(SqlConnection conn, string schema, string tableName) { using var cmd new SqlCommand( SELECT c.name, TYPE_NAME(c.user_type_id) AS data_type, c.is_nullable, c.is_identity FROM sys.columns c WHERE c.object_id OBJECT_ID(fullName), conn); cmd.Parameters.AddWithValue(fullName, $[{schema}].[{tableName}]); using var reader cmd.ExecuteReader(); var result new Dictionarystring, (string, bool, bool)(); while (reader.Read()) result[reader.GetString(0)] (reader.GetString(1), reader.GetBoolean(2), reader.GetBoolean(3)); return result; }拿到现有列字典后增量逻辑分三类模型里有、库里没有的列执行 ALTER TABLE ADD两边都有但类型对不上的列执行 ALTER TABLE ALTER COLUMN库里多出来的列不处理——可能被别的子系统使用不要手贱去删。删除列的功能我一般不做生产环境删列风险太大。public static void AlignTable(string connectionString, TableDefinition table) { using var conn new SqlConnection(connectionString); conn.Open(); if (!TableExists(conn, table.Schema, table.TableName)) { ExecuteSql(connectionString, GenerateCreateTable(table)); return; } var existing LoadExistingColumns(conn, table.Schema, table.TableName); foreach (var col in table.Columns) { if (existing.ContainsKey(col.Name)) continue; // 已存在则跳过 var addSql $ALTER TABLE [{table.Schema}].[{table.TableName}] $ADD [{col.Name}] {MapToSqlType(col)} (col.IsNullable ? NULL : NOT NULL) (col.IsIdentity ? IDENTITY(1,1) : ) (string.IsNullOrEmpty(col.DefaultValue) ? : $ DEFAULT {col.DefaultValue}); using var cmd new SqlCommand(addSql, conn); cmd.CommandTimeout 60; cmd.ExecuteNonQuery(); } }逻辑说明这套逻辑的首要目标是「补列不重建」——ALTER TABLE ADD 是元数据操作SQLSERVER 不需要重写整张表几百毫秒完成DROP 再 CREATE 的方式数据量稍大就会全表扫描、日志暴涨。ADD Column 时把类型、空值约束、IDENTITY、DEFAULT 一次带上避免先加空列再补约束的两步走。参数说明这里没处理类型不一致的 ALTER COLUMN 升级因为升级要小心精度缩短导致的数据截断。如果确定需要常见做法是先判断目标精度是否大于等于现有精度只允许向宽的方向 ALTER向窄方向改必须生成数据迁移脚本并人工确认。数据库同步工具一般也不会自动缩窄字段这点我和主流工具的行为保持一致。4.3 索引与外键的幂等创建建表之后的第二步字段对齐之后是索引。索引单独处理有两个原因一是 CREATE TABLE 里的列级索引语法受限组合索引、唯一索引、筛选索引都得在表创建后再单独执行二是增量场景下要判断索引是否存在否则重复执行会报「索引已存在」。public static void EnsureIndexes(string connectionString, TableDefinition table) { using var conn new SqlConnection(connectionString); conn.Open(); foreach (var idx in table.Indexes) { var guard IF NOT EXISTS ( SELECT 1 FROM sys.indexes WHERE object_id OBJECT_ID(fullName) AND name indexName ); var colList string.Join(, , idx.Columns.Select(c $[{c}])); var createSql $CREATE {(idx.IsUnique ? UNIQUE : )} ${(idx.IsClustered ? CLUSTERED : NONCLUSTERED)} $INDEX [{idx.IndexName}] ON [{table.Schema}].[{table.TableName}] $({colList}); using var cmd new SqlCommand(guard createSql, conn); cmd.Parameters.AddWithValue(fullName, $[{table.Schema}].[{table.TableName}]); cmd.Parameters.AddWithValue(indexName, idx.IndexName); cmd.ExecuteNonQuery(); } }逻辑说明IF NOT EXISTS 判断的是索引名而不是索引列组合——同一个表上可能出现相同列但不同名的索引按名判断能保证重复执行幂等。UNIQUE 关键字要放在 CREATE 和索引类型之间顺序写错会语法报错。聚集索引一个表只能有一个所以模型里 IsClustered 默认 false明确知道要哪个聚集索引时才开。注意自动建表的执行顺序应该是先建所有不依赖别人的表再补索引最后补外键。外键引用的父表必须先存在。外键的幂等逻辑和索引一样只是改成查 sys.foreign_keys 按约束名判断生成 ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES ...。表依赖关系复杂时用拓扑排序确定建表顺序如果拓扑排序失败出现环说明表设计有问题该回头审视业务而不是硬调代码。5. 自动建表避坑指南SQLSERVER 上 5 个高频翻车现场自动建表本身代码量不大真正让人熬夜的是 SQLSERVER 那些不吃亏不知道的语法和元数据细节。下面 5 条按现象、原因、解决的格式写实前四条我都亲手在项目里修过。5.1 表名列名撞上关键字Order、User、Desc 的方括号教训现象建表脚本在别的库跑得好好的换到新库就报 Incorrect syntax near the keyword Order表名是 User 时更隐蔽有些版本不报错但生成的表在 SSMS 里怎么都查不到。原因Order、User、Desc、Level 都是 SQLSERVER 的保留关键字或未来保留字CREATE TABLE 里不加方括号时解析器把字段名当语法成分吃掉了。解决所有标识符一律用方括号包起来生成器里统一写[{table.Schema}].[{table.TableName}]不要直接拼字符串。更冷的坑是列名叫 From 的加方括号能建成功但 SELECT 时如果不写方括号照样报错——所以生成 SELECT 语句时也要复用同一套标识符转义函数别只在建表时老实。5.2 nvarchar 的 max_length 是字节数结构对比永远对不上现象自动建表跑完第二次日志显示「需要修改列 Remark长度不一致」但数据库里明明就是 nvarchar(200)模型里也是 200。原因sys.columns.max_length 对 nvarchar 返回的是字节数nvarchar(200) 的 max_length 是 400nvarchar(max) 返回 -1。代码里直接用 max_length 和 Length 比永远差一倍。解决用 INFORMATION_SCHEMA.COLUMNS 的 CHARACTER_MAXIMUM_LENGTH 代替 sys.columns.max_length它返回字符数或者自己除以 2但必须处理 -1max 类型和 0text/ntext 兼容残留。我的习惯是类型对齐统一查 INFORMATION_SCHEMA.COLUMNS只有拿性能细节比如是否自增时才回 sys.columns。5.3 给有数据的表加 NOT NULL 列一条 DEFAULT 解决翻车现象增量脚本在空表上没问题一到有数据的生产库执行 ALTER TABLE ADD [AlarmLevel] int NOT NULLSQLSERVER 报错ALTER TABLE only allows columns to be added that can contain nulls。原因表里已有行新加的 NOT NULL 列没有默认值SQLSERVER 不知道该给已有行填什么直接拒绝整个操作。解决分两步——先加可空列、回填默认值、再改成 NOT NULL或者更简洁——ADD 时带 DEFAULT 子句SQLSERVER 会用默认值填充已有行后直接完成约束。注意 DEFAULT 后面要跟常量或确定性函数。-- 推荐写法带 DEFAULT 的 ADD一步到位 ALTER TABLE [dbo].[DeviceReadings] ADD [AlarmLevel] int NOT NULL CONSTRAINT [DF_DeviceReadings_AlarmLevel] DEFAULT (0); -- 不要这样ADD 可空列、UPDATE、ALTER COLUMN 三连 -- 事务没包好会留下中间状态回看事务日志才知道哪步断了5.4 建表脚本没包事务跑到一半留下一地残骸现象批量建 30 张表第 17 张表有个类型映射错误程序抛异常退出。重跑时前 16 张表建好了第 17 张建了一半有列没主键后续表全没建。干净环境部署变成了清理现场。原因SQLSERVER 的 DDL 本身可以放进事务回滚但默认每条语句自动提交程序循环里每张表独立执行没有事务边界中断后已提交部分不会撤销。解决整个「建表补索引补外键」流程包进显式事务任何一步抛异常整体回滚。事务内锁会变重批量表数控制在 50 张以内比较稳。回滚后事务日志会增长顺手看一眼 sqlserver 事务日志确认没有残留的未提交事务。using var conn new SqlConnection(connectionString); conn.Open(); using var tx conn.BeginTransaction(); foreach (var table in tables) { // 注意SqlCommand 要带上事务对象而不是内部再开新连接 using var cmd new SqlCommand(GenerateCreateTable(table), conn, tx); cmd.CommandTimeout 120; cmd.ExecuteNonQuery(); } tx.Commit();5.5 nvarchar(max) 的索引陷阱建了等于没建现象给 Remark 列配了索引EnsureIndexes 也没报错但查询就是不走索引执行计划里整表扫描。原因nvarchar(max)、varbinary(max)、text 这些大对象类型不能建普通索引。更糟的是 IF NOT EXISTS 按索引名判断如果之前某次已创建过同名索引之后类型改成 max重跑会误认为自己「建过了」于是没报错。解决第一道防线是类型映射里收紧 string 的默认映射Length 必填避免悄悄生成 max第二道防线是在 EnsureIndexes 里加类型检查索引列一旦是大对象类型直接抛异常而不是静默忽略。如果确实需要在大文本上搜索应该用全文索引或计算列上的哈希索引而不是硬建普通索引。6. 进阶验证建完表不等于建对表——指纹校验与 SchemaVersion 版本化自动建表跑通之后我给自己加了一道验证用结构指纹判断「库里的表和模型期望的是否一致」。做法是把每张表的列定义按顺序拼成一个字符串算 SHA256 存进 SchemaVersion 表每次启动重算比对不匹配就报警而不是自动改生产表。public static string ComputeTableFingerprint(SqlConnection conn, string schema, string tableName) { using var cmd new SqlCommand( SELECT c.name | TYPE_NAME(c.user_type_id) | CAST(c.max_length AS varchar(10)) | CAST(c.is_nullable AS varchar(1)) | CAST(c.is_identity AS varchar(1)) FROM sys.columns c WHERE c.object_id OBJECT_ID(fullName) ORDER BY c.column_id, conn); // 列顺序也算进指纹 cmd.Parameters.AddWithValue(fullName, $[{schema}].[{tableName}]); var sb new StringBuilder(); using var reader cmd.ExecuteReader(); while (reader.Read()) sb.Append(reader.GetString(0)).Append(;); var bytes System.Security.Cryptography.SHA256.HashData( System.Text.Encoding.UTF8.GetBytes(sb.ToString())); return Convert.ToHexString(bytes); }指纹只取列名、类型、长度、可空、自增五个属性能捕获九成以上结构漂移ORDER BY column_id 保证列顺序变了也能发现。max_length 用字节数没关系指纹是相对值自己和自己比。SchemaVersion 表就两列——表名和指纹哈希主键约束保证一张表一行。提示结构指纹只做报警不做自动修复。生产表的结构变更必须人工确认。.NET 5 以下没有 Convert.ToHexString用 BitConverter.ToString(bytes).Replace(-, ) 替代即可。我的收尾习惯是上线前在空库连跑三遍自动建表第二第三遍必须零报错零输出再造点脏数据塞进去跑一次增量确认没把数据弄没。这套验证做完自动建表才敢说能用。希望这套 C# 驱动 SQLSERVER 自动建表的思路和坑位清单能帮到你少熬几个查建表脚本的夜。本文还有配套的精品资源点击获取