企业官网建设流程全解析

很多刚接触 C#/.NET 的朋友，第一次面对 SQL Server 的时候，最容易懵的不是语法，而是“不知道该用哪个命令、写完怎么跑、报错怎么查”。网上搜到的资料要么是零散的代码片段，要么是官方文档那种读了等于没读的长篇大论。我最初带团队做项目时也踩过不少坑，所以一直想整理一份真正面向小白的常用命令手册，把 C#/.NET 连接 SQL Server 时最常用的那些命令、写法、注意事项一次性讲清楚。这篇就是那本手册的完整版，覆盖从环境搭建、连接数据库、增删改查，到参数化查询、事务处理、常见问题排查的完整链路，你看完可以直接照着操作。

我把这份命令大全定位成“保姆级参考”，每一段都配了能直接复制运行的代码示例和通俗解释。无论你是刚学 .NET 的学生、转行做开发的新人，还是偶尔需要写点小工具的非专职程序员，都可以把它当作手边的速查手册。内容完全基于我在真实项目里的实践经验，所有命令都经过实际验证，不存在“理论可以但跑不起来”的情况。

1. 动手前的准备工作：搭建最小可用环境

很多新手上来就直奔代码，结果卡在了环境上。SQL Server 的版本选择、连接工具的安装、数据库的创建，这些琐碎的前置工作如果不理顺，后面的所有代码都会变成“看得懂但跑不动”。所以我先把环境搭建这一步拆细。

1.1 版本选择：Express 版为什么够用

SQL Server 分为很多版本，企业版、标准版、开发版、Express 版。对于学习和小型项目来说，我不建议你直接装企业版，资源占用高、授权复杂，实际用到的功能连十分之一都不到。Express 版是免费的，功能上支持数据库、表、存储过程、视图、索引这些核心能力，性能足够支撑日常学习和中小型应用的开发调试。

安装的时候注意两点。第一，在“功能选择”界面勾选“数据库引擎服务”和“客户端工具连接”即可，其他组件按需再装，别一股脑全选。第二，身份验证模式推荐选择“混合模式”，并设置一个 sa 账户的密码，这样既可以用 Windows 身份登录，也可以后面用账户密码方式连接，灵活性更高。安装完成后，SQL Server 会以 Windows 服务的形式在后台运行，服务名为 MSSQLSERVER，你可以在 Windows 服务管理器中看到它。

1.2 用 SQL 脚本快速创建测试数据库和表

装好之后，打开 SQL Server Management Studio（SSMS）或者你习惯的数据库管理工具，连接本地实例，然后执行下面这段脚本。这段脚本会创建一个名为 DemoDB 的数据库，以及一张名为 Users 的测试表，后面所有 C# 命令示例都会基于这张表展开。

-- 创建数据库 CREATE DATABASE DemoDB; GO -- 切换到 DemoDB USE DemoDB; GO -- 创建用户表 CREATE TABLE Users ( Id INT IDENTITY(1,1) PRIMARY KEY, Name NVARCHAR(50) NOT NULL, Age INT NOT NULL, Email NVARCHAR(100) NULL ); GO

这里有一个小白很容易忽略的点：IDENTITY(1,1)表示 Id 列是自增列，从 1 开始每次加 1，插入数据的时候不需要也不允许显式给 Id 赋值。NVARCHAR则是 SQL Server 中用于存储 Unicode 字符串的类型，和 C# 的 string 对应，处理中文时比 VARCHAR 更稳妥。表建好后，顺手插入几条测试数据，方便后面验证查询命令。

INSERT INTO Users (Name, Age, Email) VALUES (N'张三', 25, N'zhangsan@example.com'); INSERT INTO Users (Name, Age, Email) VALUES (N'李四', 30, N'lisi@example.com'); INSERT INTO Users (Name, Age, Email) VALUES (N'王五', 28, NULL);

这里要注意，SQL 字符串前面加N前缀，表示后面的字符串按 Unicode 处理，这是写入中文字符时的规范写法，不加 N 在某些排序规则下会出现乱码或写入失败。

2. C#连接SQL Server：从连接字符串开始

环境准备好后，就到了关键的第一段代码：怎么让 C# 程序连上 SQL Server。这一段几乎决定了后面所有操作是否顺利，连接字符串的格式、连接对象的管理方式，都需要一次搞对。

2.1 连接字符串的构成与常见写法

连接字符串是 C# 连接 SQL Server 的“钥匙”，它告诉程序数据库在哪里、用哪个账号登录。最常用的写法是下面这种：

string connStr = "Server=localhost;Database=DemoDB;User Id=sa;Password=your_password;TrustServerCertificate=True;";

逐个拆开解释。Server是数据库实例的地址，本机可以写localhost或.，如果 SQL Server 命名实例（比如安装时指定的实例名 SQLEXPRESS），要写成localhost\\SQLEXPRESS。Database指定要连接的数据库名。User Id和Password是登录账号密码。TrustServerCertificate=True是 .NET 连接 SQL Server 时针对证书信任的配置项，本地开发环境建议加上，能避免不少证书相关的连接报错。

有一点需要特别提醒：不要把密码直接硬编码在代码里。上面的示例是为了方便演示，真实项目中应该把连接字符串放在配置文件（如 appsettings.json 或 Web.config）里，或者使用环境变量、密钥管理服务来保护敏感信息。

2.2 SqlConnection 与 using 的正确用法

连接字符串准备好后，就能创建 SqlConnection 对象了。这里涉及一个非常重要的 C# 习惯：所有实现了 IDisposable 接口的资源对象，都应该用 using 包裹。SqlConnection 就是典型的非托管资源，它底层占用数据库连接，如果不及时释放，连接池会被耗尽，程序运行一段时间后就会出现“连接超时”的报错。

using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); Console.WriteLine("数据库连接成功！"); // 这里写你的数据库操作 } // 离开 using 代码块，连接自动关闭并释放

using关键字在这里的作用是“作用域结束后自动调用 Dispose 方法”，你不需要手动写conn.Close()，哪怕中间代码抛了异常，它也能保证连接被正确关闭。这是一个看起来不起眼、但对稳定性影响巨大的细节。我在很多新人代码里见过只写conn.Open()不写Close的情况，这是最常见的连接泄漏隐患。

2.3 连接池：为什么不要频繁开关连接

可能有人会问：既然 using 会自动关闭连接，那我每次操作都 new 一个连接再关掉，不是挺方便的吗？从功能上说是可以，但性能上不划算。SQL Server 的 .NET 驱动默认开启了连接池，连接字符串相同的情况下，第一次 Open 会创建物理连接，之后 Close 并不是真的断开，而是把连接归还到池中复用。

理解这一点对小白调试很有帮助：如果你改了代码里的连接字符串（比如换了密码），连接池中的旧连接可能仍然被复用，导致改动不生效。遇到这种情况，可以在连接字符串中临时加上Pooling=False来禁用连接池，或者在程序里调用SqlConnection.ClearPool(conn)清空池子。不过在正式项目里，还是应该依赖连接池，频繁开关连接不仅慢，还会造成不必要的资源开销。

3. 增删改查的完整命令写法

连接建立后，核心操作就来了。C# 里操作 SQL Server，永远绕不开三个核心对象：SqlCommand（执行命令）、SqlDataReader（读取查询结果）、SqlDataAdapter（填充数据集）。这一章我会按照“查、增、改、删”的顺序，把最常用的命令写法完整展示出来，并解释每一步的含义。

3.1 查询：ExecuteReader 与 ExecuteScalar 的选择

查询是使用频率最高的操作。根据你需要返回的结果形态，有两种选择：查询多行多列用ExecuteReader，查询单个值（比如 COUNT、SUM、MAX）用ExecuteScalar。

先看 ExecuteReader 的标准写法：

string sql = "SELECT Id, Name, Age, Email FROM Users WHERE Age > @minAge"; using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@minAge", 20); using (SqlDataReader reader = cmd.ExecuteReader()) { while (reader.Read()) { int id = reader.GetInt32(0); string name = reader.GetString(1); int age = reader.GetInt32(2); string email = reader.IsDBNull(3) ? null : reader.GetString(3); Console.WriteLine($"{id} - {name} - {age} - {email}"); } } } }

这段代码有几个细节值得单独拎出来讲。Parameters.AddWithValue是参数化写法，第 4 章会展开细说，这里先按下不表。reader.GetInt32(0)是按列索引取值，索引从 0 开始，顺序对应 SELECT 语句中列的顺序。Nullable 列一定要用IsDBNull判断后再取值，这是数据库编程里最常见的运行时错误来源之一——从数据库读出来的 NULL，直接套GetString会抛异常。

ExecuteScalar 的写法更简单，典型场景是取 COUNT：

string sql = "SELECT COUNT(*) FROM Users WHERE Age >= @minAge"; using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@minAge", 18); int count = (int)cmd.ExecuteScalar(); Console.WriteLine($"成年用户数量：{count}"); } }

ExecuteScalar返回的是 object 类型，使用时需要强转。COUNT 返回的是 INT，所以直接(int)强转即可。如果是 SUM 或 AVG，要注意可能返回 decimal 或 double，强转前要确认实际类型。

3.2 增删改：ExecuteNonQuery 与返回影响行数

增删改操作不返回结果集，只返回“受影响的行数”，对应的命令方法是ExecuteNonQuery。以插入为例：

string sql = "INSERT INTO Users (Name, Age, Email) VALUES (@name, @age, @email)"; using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@name", "赵六"); cmd.Parameters.AddWithValue("@age", 26); cmd.Parameters.AddWithValue("@email", "zhaoliu@example.com"); int rows = cmd.ExecuteNonQuery(); Console.WriteLine($"成功插入 {rows} 行数据"); } }

这里返回的 rows 就是影响行数。你可以利用它做简单的操作成功判断：插入如果返回 1，说明有一行数据写入成功；更新如果返回 0，说明没有符合条件的行，可能是条件写错了，也可能是数据已经是最新的。更新和删除的写法结构完全相同，只是 SQL 语句不同，比如：

string updateSql = "UPDATE Users SET Age = @newAge WHERE Name = @name"; string deleteSql = "DELETE FROM Users WHERE Id = @id";

有一点要特别提醒新手：SQL Server 默认的 DELETE 和 UPDATE 操作是“有条件才删/改”的，如果忘记写 WHERE，就会操作整张表。比如上面那句 DELETE 如果漏掉WHERE Id = @id，整张 Users 表会被清空。这种事故在真实项目中时有发生，尤其是有时候手滑把参数写成了可空值，SQL 执行时条件匹配不到任何行，提升到具体代码层面很难察觉。所以执行删除和更新前，建议先用同条件的 SELECT 查询验证一遍结果范围。

3.3 分页查询的常用写法

实际项目中几乎不可能每次都把全表查出来，分页是必备技能。SQL Server 有几种分页写法，其中比较常用的是OFFSET ... FETCH NEXT语法，配合ORDER BY使用：

SELECT Id, Name, Age, Email FROM Users ORDER BY Id OFFSET @offset ROWS FETCH NEXT @pageSize ROWS ONLY;

C# 侧代码如下：

int pageIndex = 2; // 第几页，从 0 开始 int pageSize = 10; // 每页多少条 string sql = "SELECT Id, Name, Age, Email FROM Users ORDER BY Id OFFSET @offset ROWS FETCH NEXT @pageSize ROWS ONLY"; using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@offset", pageIndex * pageSize); cmd.Parameters.AddWithValue("@pageSize", pageSize); // 执行查询和读取，和 3.1 一样 } }

这里的核心是OFFSET从第几行开始跳过，FETCH NEXT取多少行。注意OFFSET的偏移量是pageIndex * pageSize，即“之前所有页一共显示的记录数”。OFFSET 和 FETCH 必须配合 ORDER BY 使用，没有 ORDER BY 的情况下，SQL Server 不保证返回顺序，分页就失去了意义。

4. 参数化查询：小白最容易忽略的安全底线

如果说这一章只能记住一件事，那就是：永远不要用字符串拼接的方式把用户输入嵌进 SQL 语句。这不仅是代码规范问题，更是安全问题。某年我参与一个内部系统的安全审计时，发现很多历史代码都用了字符串拼接，修复起来非常痛苦，因为要改的东西牵连甚广。

4.1 为什么不能直接拼接字符串

先看一个反例，网上随便搜都能看到类似的写法：

string name = txtName.Text; // 用户输入 string sql = "SELECT * FROM Users WHERE Name = '" + name + "'";

如果用户输入的是张三' OR '1'='1，拼接后 SQL 就变成了：

SELECT * FROM Users WHERE Name = '张三' OR '1'='1'

因为'1'='1'永远为真，这条 SQL 会把整张表的数据全部查出来。这还只是查询场景，更危险的是用户输入'; DROP TABLE Users; --之类的注入语句时，后果就是灾难性的。这种方式就叫 SQL 注入，是 Web 应用中最古老也最常见的安全漏洞之一。

可能有人会说，我的程序是内网用的、没有外部用户，是不是就安全了？不。只要输入可能来自任何外部渠道——一个配置文件、一个接口参数、一个 Excel 导入——就不能假设输入是安全的。凡是变量要进入 SQL 语句，就必须走参数化。

4.2 参数化查询的标准写法

参数化查询的思路很简单：SQL 语句中不直接嵌变量，而是用占位符（如@name）表示，真正的值通过参数对象传给数据库。数据库会把这个参数当作“数据”，而不是“SQL 指令”，因此即使参数值里包含恶意内容，也只会当作字符串处理。前面章节里的代码示例其实已经用了参数化写法，这里正式总结一下：

string sql = "SELECT * FROM Users WHERE Name = @name AND Age > @age"; using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@name", name); cmd.Parameters.AddWithValue("@age", age); using (SqlDataReader reader = cmd.ExecuteReader()) { // 正常读取 } } }

AddWithValue是最简单的参数添加方式，参数名要和 SQL 中的占位符保持一致，大小写不敏感。注意占位符前面的 @ 符号在 C# 和 SQL 中都要写，C# 里不用带上类型信息，SQL Server 会根据参数值的类型自动推断，不过对于某些特殊类型（如 DateTime、decimal），建议显式指定参数类型，避免隐式转换带来的性能问题。

4.3 常见参数类型与空值处理

参数化查询还牵扯一个经常踩坑的问题：空值。比如插入一条 Email 为 NULL 的记录，直接用AddWithValue("@email", null)，程序会抛异常，因为 AddWithValue 不允许参数值为 null。正确的做法是使用DBNull.Value：

cmd.Parameters.AddWithValue("@email", string.IsNullOrEmpty(email) ? DBNull.Value : (object)email);

这里三目运算符的两种返回类型要一致，所以给email做了(object)强转。同样的逻辑也适用于更新场景——如果用户没有填写某个可选字段，就应该写入 NULL，而不是空字符串。空字符串和 NULL 在数据库语义上是两回事：NULL表示“未知”，空字符串表示“知道它是空的”，这种差异会在 COUNT、WHERE 条件等地方产生完全不同的查询结果。

关于类型，还有一个容易混淆的地方：SQL Server 的BIT类型对应 C# 的bool，DATETIME对应DateTime，DECIMAL(18,2)对应decimal。用AddWithValue时参数值用对应 C# 类型传递即可，大多数情况下驱动都能正确映射。但遇到明确数据类型的存储过程参数时，建议用cmd.Parameters.Add("@param", SqlDbType.Int).Value = 123;的方式显式声明，能减少类型推断导致的边界问题。

5. 事务处理：批量操作不出错的保障

日常开发中经常遇到这样的需求：一次性往多张表写数据，或者先删后插。如果其中一步失败，前面成功的操作怎么办？比如转账场景，A 账户扣钱成功，但 B 账户加钱失败，这时候 A 的钱就凭空蒸发了。事务就是用来解决这类问题的：把一系列操作打包成一个整体，要么全部成功，要么全部回滚。

5.1 什么时候需要事务

事务不是万能的，也不应该给每个操作都套上。需要用到事务的典型场景包括：

• 多个表之间的数据一致性操作，如订单表和库存表同时更新
• 先查询后更新的复合逻辑，比如“扣减前先检查库存”
• 批量插入或修改，中途失败需要整体撤销
• 主从表结构的数据保存，如订单头与订单明细一起写入

判断标准就一条：这些操作是否必须同时成功或同时失败。如果是，就需要事务。如果只是单条 SQL 或者日志写入这种允许部分成功的场景，事务反而会增加锁开销，降低并发性能。

5.2 SqlTransaction 的示例代码

C# 中使用事务，核心是用conn.BeginTransaction()开启事务，然后把SqlCommand的Transaction属性指向这个事务对象。看完整示例：

using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); SqlTransaction transaction = conn.BeginTransaction(); try { string sql1 = "UPDATE Account SET Balance = Balance - @amount WHERE UserId = @fromUser"; using (SqlCommand cmd1 = new SqlCommand(sql1, conn, transaction)) { cmd1.Parameters.AddWithValue("@amount", 100); cmd1.Parameters.AddWithValue("@fromUser", 1); cmd1.ExecuteNonQuery(); } string sql2 = "UPDATE Account SET Balance = Balance + @amount WHERE UserId = @toUser"; using (SqlCommand cmd2 = new SqlCommand(sql2, conn, transaction)) { cmd2.Parameters.AddWithValue("@amount", 100); cmd2.Parameters.AddWithValue("@toUser", 2); cmd2.ExecuteNonQuery(); } transaction.Commit(); Console.WriteLine("事务提交成功"); } catch (Exception ex) { transaction.Rollback(); Console.WriteLine($"事务回滚：{ex.Message}"); } }

这里有一个关键的写法细节：SqlCommand 的构造函数接受了三个参数——SQL 语句、连接对象、事务对象。如果你只写了new SqlCommand(sql, conn)而忽略了事务参数，命令执行的默认行为就是在独立事务之外运行，事务就形同虚设了。这是新手使用事务时最容易犯的错误，我见过不止一次代码里开了事务但命令没有绑定 Transaction 的情况，后果就是“该回滚的没回滚，数据变得乱七八糟”。

5.3 事务中容易踩的坑

使用事务有几个需要心里有数的点。第一，开启事务后，相关的表会被加锁，其他事务的读写可能被阻塞。如果事务里执行了耗时很长的操作，比如慢查询或外部接口调用，会导致连接长时间持有锁，高并发时容易出现死锁。因此事务应该“短平快”，不要在事务里做与数据库无关的操作。

第二，SQL Server 的默认隔离级别是 Read Committed，事务里第一次查询的结果在同一个事务内可能因为其他会话的修改而改变。如果对数据一致性有更高要求，可以显式指定隔离级别，如RepeatableRead或Snapshot，但代价是更高的锁竞争或额外开销。这个内容比较深，新手阶段先理解事务生效的基本规则即可。

第三，事务回滚不是万能的。如果表使用了自增主键，即使回滚了 DELETE 操作，自增计数也不会倒退。也就是说，事务回滚能保证数据逻辑的一致性，但不保证物理行为的完全恢复。这在做数据修复脚本时尤其重要，不要以为回滚了就等同于没发生过。

6. 常见问题排查与避坑经验

到了这一章，我会把整个学习和开发过程中经常遇到的报错、异常和诡异现象集中梳理一遍。很多问题看起来五花八门，实际原因高度重复，掌握了排查思路，能省下大量搜索时间。

6.1 连接失败：那些最常见的元凶

连接失败是最常见的入门问题，报错信息通常是“在建立与服务器的连接时出错”或“找不到服务器或无法访问”。我总结了几个高频原因。

• 服务器实例名写错：localhost和localhost\\SQLEXPRESS是两种不同的写法，如果安装时选择了默认实例，用localhost；如果选择了命名实例，必须带上\\SQLEXPRESS之类的内容。可通过 SQL Server 配置管理器查看当前实例名称。
• 端口未开放：默认端口 1433，如果数据库不在本机，需要确认防火墙允许该端口通信。测试时可以先用telnet 服务器IP 1433验证一下端口通不通。
• 身份验证模式不对：如果 SQL Server 只开了 Windows 身份验证，用User Id=sa连接肯定会失败。安装时选混合模式可避免这个问题，也可在 SSMS 中右键实例属性、安全性、服务器身份验证里切换。
• 登录账户被禁用或密码错误：sa账户可能出于安全考虑被禁用了，可以先用 Windows 身份登录确认，然后启用并重置密码。

排查连接问题，我习惯的步骤是：先在 SSMS 里用同样的账号密码手动连接，能连上说明服务没问题，问题出在 C# 代码或配置上；SSMS 也连不上，基本就是服务状态、端口或账号问题。这样能快速缩小范围。

6.2 查询超时与性能优化方向

新手常遇到的另一个问题是“Timeout expired. The timeout period elapsed prior to completion of the operation”。默认情况下，SqlCommand 的执行超时是 30 秒，超时后抛异常。解决思路不是一味调大超时时间，而是先搞清楚为什么慢。

最常见的原因是：数据表没有建索引，查询需要全表扫描。比如WHERE Name = @name这种条件，如果 Name 列没有索引，当表数据量超过几十万行时，查询就会明显变慢甚至超时。解决方式是给常用查询条件列加上索引：

CREATE INDEX IX_Users_Name ON Users(Name);

另外一个容易忽视的问题是参数嗅探。简单说，存储过程或参数化 SQL 第一次执行时，SQL Server 会根据当时的参数值生成执行计划并缓存，后续即使参数值变了，执行计划可能还是老一套，对于某些数据分布不均的表来说，可能产生极慢的查询。这个知识点对新手有点进阶，但如果遇到“明明索引建了还是很慢”的情况，可以尝试用OPTION (RECOMPILE)提示强制每次重新生成执行计划。

还有一个实战里经常出现的：ORM 临时生成的 SQL 可能包含不必要的列或表连接。如果你用的是 EF Core 或 Dapper 这类框架，框架生成的 SQL 可能和你手写的预期不一致。执行慢查询时，用 SQL Server Profiler 或sys.dm_exec_query_stats抓一下实际执行的 SQL，往往会有意外发现。

6.3 空值处理与数据类型不匹配

C# 的null和数据库的NULL在互操作中有不少坑。除了前面提到的DBNull.Value，还有一种情况是读取时类型不匹配。比如数据库列类型是INT，允许 NULL，但某行数据是 NULL，调用reader.GetInt32(1)就会抛出InvalidCastException。遇到可能为 NULL 的列，应该先调用reader.IsDBNull判断再取值，或者用更简洁的写法：

int? age = reader.IsDBNull(1) ? (int?)null : reader.GetInt32(1);

把int包装成int?（可空值类型），这样age就能安全地代表“未知”的状态。这个技巧在处理用户资料这类大量可空字段的场景中非常实用，比逐字段 if 判断省事得多。

字符串截断也是常见问题：给NVARCHAR(50)列写入超过 50 个字符的字符串，SQL Server 默认可能抛“String or binary data would be truncated”错误。这个报错很好排查，量一下数据长度即可。但在 UPDATE 场景中要小心，因为有时候是某条数据的某个字段超长，而 SELECT 看着没问题，导致定位很难，我习惯先跑一遍SELECT MAX(LEN(字段)) FROM 表找出超长行。

6.4 实操速查：常见问题对照表

下面是我整理的一份对照表，基本覆盖了初学者阶段 90% 以上的高频报错。建议截图收藏，遇到问题先对照查一遍。

6.5 调试数据库代码的独家技巧

最后分享几个调数据库代码时非常实用的技巧，这些都是常规教程里不太会写的内容。

第一，在 C# 里把生成的 SQL 和参数值打印出来。很多异常表面上是数据库报错，实际是传入的参数值不对。写一个辅助方法，把最终执行的 SQL（占位符换为实际值）输出到控制台或日志，几秒钟就能看清问题在哪。我团队的代码规范里就有一条：Debug 模式下必须输出参数化后的完整 SQL。

第二，先用 SSMS 跑 SQL，再跑 C#。C# 代码我们把它当成一个“SQL 执行器”，出问题时先确认这条 SQL 在 SSMS 中能正确执行、返回正确结果，再去查 C# 侧是不是传参出错。这样可以避免把 SQL 语法错误、数据错误、代码错误搅在一起排查，大幅缩短调试时间。

第三，学会看 SQL Server 的错误日志。不是每个错误都会出现在程序的控制台里，有些连接层面的问题（如登录失败、服务启动失败）只记录在 Windows 事件查看器和 SQL Server 错误日志中。用 SSMS 连接到服务器后，展开“管理”节点，查看“SQL Server 日志”，往往能找到比应用层错误更详细的原因。

每次带新人，我都会把上面这些内容讲一遍。实际做下来，大家普遍反映最难的其实不是记住命令，而是建立一种“数据库操作思维”：理解连接、命令、事务这几个对象之间的关系，理解参数化的必要性，理解“先考虑数据一致性，再考虑代码”的顺序。这些思维方式一旦建立，C# 操作 SQL Server 的命令就不再是一堆孤立的代码片段，而是能根据需求随时组装的能力。希望这份命令大全能帮你跨过入门那道坎，少走一些我当年走过的弯路。