C#连接SQL Server实战：连接字符串、增删改查与上位机应用

很多人学C#的时候，最容易卡住的地方不是语法，而是“代码到底怎么跟数据打交道”。写了半天控制台程序，输出来输出去，一到真实项目就发现，业务逻辑全都落在数据库里：用户点了个保存按钮，数据要进库；扫码枪扫了一下，记录要落库；设备采集上来一组温度，也得存下来。C#配SQL Server，是Windows生态里最经典、最成熟的一套组合，几乎所有C#上位机、管理系统、进销存、课程设计，都绕不开它。

这篇文章不打算给你贴一堆官方文档，而是把我自己从装环境、写连接字符串、做增删改查、接到上位机场景、再一路排坑的完整过程梳理一遍。看完之后，你应该能独立把一套“C#界面 + SQL Server存储”的小系统跑起来，也知道出了问题该从哪里下手查。适合刚学完C#基础、正在做数据库课程设计、或者工作中要开始碰数据库的开发者。

1. 先搞清楚C#和SQL Server是怎么协作的

1.1 一条数据请求的完整链路

很多初学者容易把“数据库”想象成一个神秘的黑盒子，其实一条数据从界面到硬盘，路径是非常清晰的。

你在C#里写new SqlConnection()，本质上是建立了一条到SQL Server引擎的管道。SQL Server是一个独立的服务进程，它监听某个端口（默认1433），等着有人来连接。连接建立之后，你通过SqlCommand把一段T-SQL语句发过去，SQL Server负责解析、优化、执行，再把结果集返回给C#端。

整个过程可以拆成四层：

• 客户端层：你的WinForms、WPF、控制台程序，负责收集用户输入、展示结果。
• 数据访问层：C#里用ADO.NET（SqlConnection、SqlCommand、SqlDataReader这些类）发出SQL指令、接收结果。
• 数据库引擎层：SQL Server服务本身，负责存储、查询、事务、并发控制。
• 物理存储层：数据最终落到.mdf数据文件和.ldf日志文件里。

用生活化的类比来说，C#程序就像餐厅前台的点单员，SQL Server就是后厨。点单员不关心菜是怎么炒的，他只管把菜单传进去、把菜端出来。但前提是，他得知道后厨在哪、怎么把单子递进去——这就是连接字符串干的事。

1.2 学这套东西到底能做什么项目

光说概念很虚，我列几个实际的、C# + SQL Server最常见的应用场景：

• 进销存管理系统：商品、供应商、入库单、出库单、库存表，典型的增删改查业务。
• 上位机数据采集：设备通过串口、网口把数据传给C#上位机，上位机解析后写入数据库做历史记录。
• 扫码枪录入：扫码枪扫描条码，触发事件，C#把条码+时间戳写入数据库。
• 中小型Web系统后端：ASP.NET Core + SQL Server，企业后台、CMS、订单系统。
• 数据库课程设计/毕业设计：学生选课、图书管理、学生信息管理这些经典题目，本质都是C# + SQL Server。

你会发现，这些场景的核心从来不是“C#语法有多花哨”，而是“数据能不能准确、高效、安全地存进去再查出来”。所以这篇文章的重心也放在这里。

1.3 入门阶段最该优先掌握的五个知识点

我自己带过好几个新人，发现只要把下面五件事啃下来，基本就能应付绝大多数常规开发：

1. T-SQL基础：SELECT、INSERT、UPDATE、DELETE，以及WHERE条件、JOIN连表。
2. 连接字符串的配置：知道每一段参数什么意思，认证方式怎么选。
3. ADO.NET核心对象：SqlConnection、SqlCommand、SqlDataReader、DataTable、SqlParameter。
4. 参数化查询：这是安全底线，后面会专门讲。
5. 常见异常排查：连不上服务器、登录失败、超时，这些占了初学者报错的80%。

2. 环境部署：版本选择、安装陷阱和卸载重来

2.1 别再纠结2008了，新项目直接用2022

我经常看到有人在网上搜“sql server 2008 r2下载”，点进去一堆乱七八糟的站点。这里得说句实在话：SQL Server 2008 R2早就停止官方支持了，新项目不要再用。除非你维护的是老系统，迫不得已要装一个兼容环境，否则一律选新版本。

目前主流的几个版本定位如下：

对绝大多数读者来说，下载Developer版就够了，功能和企业版几乎一致，而且免费。Express版的问题是功能有阉割，比如没有Agent服务，有些工具用起来不爽。学习阶段没必要给自己找麻烦。

顺便多说一句，很多老教程喜欢用SQL Server Management Studio（SSMS）作为图形化工具，这个习惯可以保留，SSMS依然好用。不过新版的Azure Data Studio也可以作为替代，界面更轻量，写查询语句更舒服。

2.2 安装时最容易埋雷的三个选项

安装界面其实一路点“下一步”也能装完，但有三处要特别留意，不然后面C#连不上你都不知道为什么。

第一，实例名。默认安装的是MSSQLSERVER，这叫默认实例，连接的时候写localhost就行。如果你在安装时改了实例名，比如填了SQLEXPRESS，那连接字符串里就必须写成localhost\SQLEXPRESS。很多人的连接失败就是栽在这里——明明装的是命名实例，却只写了localhost。

第二，身份验证模式。安装过程中会让你选“Windows身份验证模式”还是“混合模式”。如果你打算用sa账号从C#程序里连数据库，必须选“混合模式”，并给sa设置一个密码。SQL Server默认是不启用sa的，你选了混合模式之后，还得手动去SSMS里把sa账号启用。

第三，防火墙。Windows防火墙默认会拦截外部对1433端口的访问。如果你只是在同一台机器上开发调试，问题不大；但如果你要把数据库部署到服务器上，让别的电脑通过局域网连接，那必须在防火墙里放行1433端口，或者安装时勾选“允许远程访问”。

2.3 安装失败和卸载残留的补救思路

热词里有一条“microsoft sql server 安装失败。 the required msi package 'c:\users\86187\app...'”，这是典型的安装残留问题。SQL Server的安装程序对系统环境很敏感，之前装过一次没卸干净、Windows更新没打全、杀毒软件拦截，都会导致这种失败。

我的建议是：

• 不要急着重装系统。先到“控制面板 -> 程序和功能”里把所有带“Microsoft SQL Server”字样的组件全部卸载。
• 卸载完重启一次，清理C:\Program Files\Microsoft SQL Server目录残留。
• 检查注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server，如果还有残留键值，手动删除（操作注册表前先备份）。
• 用安装介质重新执行安装，选择“全新安装”，不要选“升级”。

如果你要找官方卸载工具，注意现在微软已经不提供单独的“Windows Installer CleanUp”工具了，你可以用“添加删除程序”配合上面的手动清理。网上有些第三方“强力卸载工具”我不建议用，容易把系统整坏。另外一个非常实用的技巧是，在安装失败时，去C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log目录下看日志文件，里面会明确告诉你卡在哪一步，按日志提示处理往往最快。

2.4 快速验证环境是否装好

装完之后，先别急着写C#代码，先确认数据库服务本身是好的。按下Win + R，输入services.msc，找到SQL Server (MSSQLSERVER)这个服务，确认状态是“正在运行”。然后打开SSMS，用Windows身份验证连localhost，能看到对象资源管理器，就说明服务正常了。

这一步很多人会跳过，结果C#报错半天，最后发现是服务根本没启动。

3. 连接字符串：整个应用的命脉

3.1 连接字符串的五个核心字段

C#里最经典的一句连接字符串长这样：

csharp复制string connStr = "Data Source=localhost;Initial Catalog=MyAppDB;User ID=sa;Password=123456;Encrypt=False;";

这里面的每个字段都有讲究。

• Data Source：数据库服务器地址。本机默认实例写localhost或.，命名实例写localhost\实例名，局域网远程写192.168.x.x或服务器名，带端口就写localhost,1433。
• Initial Catalog：要连接的数据库名称。不写的话默认连到master库，一般不建议直接操作master。
• User ID / Password：SQL Server账号密码。如果使用Windows身份验证，则不需要这两项，改成Integrated Security=True;。
• Encrypt：新版SQL Server默认强制加密连接，会提示证书错误。开发环境直接设False，生产环境建议用真证书并设True。

3.2 两种认证方式到底怎么选

这是一个几乎每个初学者都会问的问题。说下我的经验：

Windows身份验证的好处是密码不暴露在连接字符串里，开发时很方便，打开SSMS直接连。但问题是，如果你的程序要部署到别的机器，尤其是一台没有域环境的工控机，Windows账号体系可能对不上，连接就容易失败。

SQL Server身份验证（sa或自建账号）的好处是，只要服务器允许远程连接、账号密码正确，任何客户端都能连。坏处是密码写在配置文件里，要注意保护。

我的建议是：本地开发用Windows身份验证，部署到服务器或者上位机场景，统一改用SQL Server账号。连接字符串放进app.config或appsettings.json里，不要硬编码在代码中。

3.3 连接字符串放进配置文件

实际的C#项目里，连接字符串一般放在配置文件里，这样发布后改环境不用重新编译。WinForms/WPF项目用App.config，ASP.NET Core项目用appsettings.json。

App.config的写法：

xml复制<connectionStrings>
  <add name="DefaultConnection"
       connectionString="Data Source=localhost;Initial Catalog=MyAppDB;User ID=sa;Password=123456;Encrypt=False;"
       providerName="System.Data.SqlClient" />
</connectionStrings>

代码里读取：

csharp复制using System.Configuration;

string connStr = ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;

注意：WinForms项目改了App.config之后，最终生成的文件名可能是你的程序名.exe.config，发布的时候记得把这个文件一起带上。

3.4 连接池和超时参数

还有两个参数我建议你们关注一下。一个是Connect Timeout，默认15秒，如果服务器没启动或者网络不通，程序会卡15秒才报错。开发时可以设成3秒，快速感知问题：

csharp复制"Data Source=localhost;Initial Catalog=MyAppDB;Integrated Security=True;Connect Timeout=3;"

另一个是连接池。ADO.NET默认开启连接池，同一个连接字符串的SqlConnection会被复用，不用每次新建物理连接。所以你在代码里频繁Open()和Close()并不会严重影响性能，反而是每次new不同连接字符串才会导致池碎片。这一点很多新手不知道，总觉得要搞什么“全局单例连接”，其实没必要。正确的做法是：每次用完就关，交给连接池去复用。

4. 增删改查的完整落地：从最朴素的ADO.NET写起

4.1 一个最小可运行的查询模板

学习阶段，我不建议一上来就上EF Core或者Dapper，先把最底层的ADO.NET跑通了，你才能理解后面那些框架到底帮你省了什么。

最小查询模板：

csharp复制using System;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        string connStr = "Data Source=localhost;Initial Catalog=MyAppDB;Integrated Security=True;Encrypt=False;";
        
        using (SqlConnection conn = new SqlConnection(connStr))
        {
            conn.Open();
            string sql = "SELECT Id, Name, Price FROM dbo.Products";
            using (SqlCommand cmd = new SqlCommand(sql, conn))
            using (SqlDataReader reader = cmd.ExecuteReader())
            {
                while (reader.Read())
                {
                    Console.WriteLine($"{reader["Id"]} | {reader["Name"]} | {reader["Price"]}");
                }
            }
        }
    }
}

注意两个细节。第一，using关键字确保SqlConnection和SqlDataReader用完后自动释放，避免连接泄漏。第二，reader["Name"]这种方式读取列值，列名一定要和SQL查询的列名一致，不推荐用reader[0]这种方式，因为SQL一旦改动，索引就全乱了。

4.2 参数化查询是底线，不是可选项

很多教程为了省事，会教你这样拼SQL：

csharp复制string name = textBox1.Text;
string sql = "SELECT * FROM dbo.Users WHERE Name = '" + name + "'";

这行代码几乎可以列为C#数据库开发的头号危险写法。原因很简单：如果用户在文本框里输入' OR '1'='1，拼出来的SQL就变成了：

sql复制SELECT * FROM dbo.Users WHERE Name = '' OR '1'='1'

这个条件永远为真，等于把你整张表都查出来了。如果再配合DROP TABLE之类的注入语句，后果更严重。

正确的写法是用参数化查询：

csharp复制string sql = "SELECT * FROM dbo.Users WHERE Name = @name";
using (SqlCommand cmd = new SqlCommand(sql, conn))
{
    cmd.Parameters.AddWithValue("@name", textBox1.Text);
    using (SqlDataReader reader = cmd.ExecuteReader())
    {
        // 处理结果
    }
}

@name是SQL参数占位符，C#端用Parameters.AddWithValue把值传进去。SQL Server会把参数当做一个“值”来处理，而不是当“SQL代码”来解析，这样就堵死了注入路径。这个习惯我从入行第一天用到现在，从来没有被SQL注入坑过。

4.3 查询结果：DataReader还是DataTable

SqlDataReader是流式读取，一条一条往下读，占用内存小，适合处理大量数据。但它有一个特点：读取的时候连接必须是打开的，而且只能向前读，不能随机跳转。

DataTable则是把整个结果集一次性拉到内存里，断开连接之后还能用。它适合数据量不大、需要做进一步筛选或绑定的场景。比如：

csharp复制DataTable dt = new DataTable();
using (SqlDataAdapter adapter = new SqlDataAdapter("SELECT * FROM dbo.Products", conn))
{
    adapter.Fill(dt);
}
dataGridView1.DataSource = dt;

把DataTable直接赋给DataGridView.DataSource，表格就自动显示出来了，这是WinForms/MVP开发里最常用的套路。但要注意，如果查询结果是几万行以上的大表，一次性Fill到内存里会很吃紧，这时候就要考虑分页查询，或者改用SqlDataReader逐条处理。

4.4 事务：多个操作要么全成、要么全不成

现实业务里很少只有一个SQL语句。比如转账操作，要先扣A的余额，再加B的余额，如果第一步成功、第二步失败，账就平不了。这时候就需要事务。

csharp复制using (SqlConnection conn = new SqlConnection(connStr))
{
    conn.Open();
    using (SqlTransaction tran = conn.BeginTransaction())
    {
        try
        {
            string sql1 = "UPDATE dbo.Accounts SET Balance = Balance - 100 WHERE Id = @fromId";
            using (SqlCommand cmd1 = new SqlCommand(sql1, conn, tran))
            {
                cmd1.Parameters.AddWithValue("@fromId", 1);
                cmd1.ExecuteNonQuery();
            }

            string sql2 = "UPDATE dbo.Accounts SET Balance = Balance + 100 WHERE Id = @toId";
            using (SqlCommand cmd2 = new SqlCommand(sql2, conn, tran))
            {
                cmd2.Parameters.AddWithValue("@toId", 2);
                cmd2.ExecuteNonQuery();
            }

            tran.Commit();
        }
        catch
        {
            tran.Rollback();
            throw;
        }
    }
}

关键点有三个：SqlCommand一定要带上tran这个参数；所有操作都成功才Commit；任何一个操作抛异常就Rollback。这个模板可以直接抄，也可以进一步封装成泛型方法，但核心逻辑是不变的。

4.5 从手写映射到Dapper和EF Core

用SqlDataReader手写实体映射是这样的：

csharp复制Product p = new Product
{
    Id = (int)reader["Id"],
    Name = reader["Name"].ToString(),
    Price = (decimal)reader["Price"]
};

字段少还好，字段一多，全是重复劳动。这时候就该考虑Dapper了。Dapper是介于纯ADO.NET和重量级ORM之间的轻量工具，扩展方法在IDbConnection上，支持泛型映射，性能接近手写ADO.NET。

csharp复制using Dapper;

string sql = "SELECT * FROM dbo.Products WHERE Id = @id";
Product p = conn.QueryFirstOrDefault<Product>(sql, new { id = 1 });

而EF Core是完整的ORM，适合业务模型复杂、需要做迁移和关系映射的项目。学习路径我建议是：先把ADO.NET的CRUD写熟练，再上Dapper提升开发效率，最后按需学EF Core。跳级学习EF Core的后果是，你遇到问题根本不知道底层在干什么。

5. 上位机实战里C#和数据库的结合点

5.1 上位机为什么离不开数据库

热词里“C#上位机”出现频率非常高，这确实也是大量C#开发者的主战场。上位机做的事情一般是：通过串口、网口、USB和硬件设备通信，读取设备状态、采集数据、下发控制指令。但设备数据如果不落库，重启电脑就全没了，那采集还有什么意义？

所以上位机系统里，数据库的职责通常有两个：

• 把采集到的历史数据保存下来，供后续做报表、曲线分析、回溯查询。
• 保存设备参数、配方、用户配置，让程序每次启动时从数据库读取。

这就对C#的异步处理能力有要求了。上位机在收数据的时候，界面不能卡死，数据库写入也不能阻塞采集线程。所以我建议数据库操作一律放到后台线程或者异步方法里执行。

5.2 扫码枪触发事件后如何写入SQL Server

扫码枪有两种常见接入方式：一种是模拟键盘输入，鼠标焦点在哪，扫描结果就输入到哪，此时你只需要处理文本框的KeyDown或其他事件即可；另一种是通过串口或网口直接给上位机发数据，这种更灵活，但需要自己接收。

假设扫码枪接在串口上，用SerialPort接收数据，然后插入数据库。基础框架如下：

csharp复制using System.IO.Ports;
using System.Data.SqlClient;

SerialPort sp = new SerialPort("COM3", 9600, Parity.None, 8, StopBits.One);
sp.DataReceived += (s, e) =>
{
    string code = sp.ReadExisting().Trim();
    if (!string.IsNullOrEmpty(code))
    {
        InsertBarcode(code);
    }
};
sp.Open();

DataReceived事件在后台线程触发，所以InsertBarcode里要避免操作UI控件，如果要更新界面，需要Invoke回UI线程。插入数据库的逻辑用之前的参数化方式即可：

csharp复制private void InsertBarcode(string barcode)
{
    string sql = "INSERT INTO dbo.ScanRecords(Barcode, ScanTime) VALUES(@barcode, GETDATE());";
    using (SqlConnection conn = new SqlConnection(connStr))
    using (SqlCommand cmd = new SqlCommand(sql, conn))
    {
        cmd.Parameters.AddWithValue("@barcode", barcode);
        conn.Open();
        cmd.ExecuteNonQuery();
    }
}

这里用SQL Server的GETDATE()生成时间戳，避免C#和数据库服务器时间不一致带来的麻烦。

5.3 socket通讯与数据库写入的协作

热词里还有“C# socket”，上位机通过TCP/IP和硬件通信同样是高频场景。用TcpListener或者Socket接收数据时，一个最常见的做法是：接收线程只负责把原始报文解析成结构体，然后丢进一个队列，再由独立的写入线程消费队列落库。

这个“生产-消费”模式是我的个人经验里最稳的写法。原因很简单：设备发送频率是不可控的，可能某段时间突然爆发大量数据，如果直接在接收线程里逐条写库，数据库稍微慢一点，socket缓冲区就被撑爆，造成丢包。

用ConcurrentQueue或者Channel做缓冲，接收线程入队、写入线程出队批量写库，既能保证不丢数据，又能通过批量提交减少数据库压力。不要图省事直接在接收事件里开数据库连接，实测下来一旦数据量大，丢数据是必然的。

5.4 大批量数据写入用SqlBulkCopy

上位机采集的数据往往是高频率的，比如每秒采集几十个点。如果一条一条INSERT，插入速度会很感人。这时候要用SqlBulkCopy。

csharp复制using System.Data.SqlClient;

DataTable dt = new DataTable();
dt.Columns.Add("DeviceId", typeof(int));
dt.Columns.Add("Value", typeof(float));
dt.Columns.Add("CollectTime", typeof(DateTime));

foreach (var data in bufferList)
{
    dt.Rows.Add(data.DeviceId, data.Value, data.CollectTime);
}

using (SqlBulkCopy bulk = new SqlBulkCopy(connStr))
{
    bulk.DestinationTableName = "dbo.DeviceData";
    bulk.BatchSize = 1000;
    bulk.WriteToServer(dt);
}

SqlBulkCopy底层用的是BCP协议，插入速度比逐条INSERT快一到两个数量级。一个小坑：DataTable的列名和数据库表列名必须一致，否则它会按列的顺序映射，非常容易插错。建议显式设置ColumnMappings，比如bulk.ColumnMappings.Add("DeviceId", "DeviceId")，这样最保险。

5.5 别在UI线程里做数据库操作

新手写WinForms，特别喜欢在按钮点击事件里直接进行数据库查询，数据量大时界面就会卡成“未响应”。正确做法是按钮事件里只启动一个异步方法：

csharp复制private async void btnQuery_Click(object sender, EventArgs e)
{
    btnQuery.Enabled = false;
    try
    {
        DataTable dt = await Task.Run(() => QueryData());
        dataGridView1.DataSource = dt;
    }
    finally
    {
        btnQuery.Enabled = true;
    }
}

注意async void只在事件处理器里使用，普通方法不要写async void，最好返回Task。

6. 五个高频报错的完整排查链路

6.1 openrowset被阻止：不是Bug，是安全策略

热词里有一条非常经典：“sql server 阻止了对组件 'ad hoc distributed queries' 的 statement 'openrowset'”。这个消息我在论坛上看到过无数次，原因是SQL Server默认禁用了OpenRowset这种跨服务器查询组件。

先解释一下OpenRowset是干什么的。它允许你在一台SQL Server上直接查询另一台数据源，比如：

sql复制SELECT * FROM OPENROWSET('SQLNCLI', 'Server=192.168.1.100;Trusted_Connection=yes;', 'SELECT * FROM dbo.Users');

这个功能在异构数据交换、临时跨库查询时确实有用，但它也让数据库有了“向外连接”的能力，安全风险比较大，所以默认关闭。

如果你确实要临时用一下，可以这样开启：

sql复制EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;

用完之后建议立刻关掉：

sql复制EXEC sp_configure 'Ad Hoc Distributed Queries', 0;
RECONFIGURE;

我个人的经验是，能不用OpenRowset就不用，跨库需求优先考虑建立链接服务器（Linked Server），或者更彻底一点，在C#代码里直接连多个数据源，自己控制数据流转。这样权限边界更清晰，也方便排查问题。

6.2 “无法连接到localhost”的排查顺序

这个报错初学者遇到的最多，但95%的根因都是那几件事。我给你们一个固定的排查链路，照着走基本能解决。

第一步，确认服务有没有启动。Win + R输入services.msc，找SQL Server (MSSQLSERVER)或SQL Server (SQLEXPRESS)，看状态是不是“正在运行”。没启动就右键启动。

第二步，确认实例名。默认实例写localhost，命名实例写localhost\实例名。不清楚自己装的是什么，就打开SSMS，看连接对话框里“服务器名称”自动带出来的是什么。

第三步，确认TCP/IP协议是否启用。打开“SQL Server配置管理器”，找到“SQL Server网络配置”，看“TCP/IP”是不是已启用。很多电脑默认只启用了Shared Memory，其他机器连不上，就是卡在这里。改完记得重启SQL Server服务。

第四步，确认防火墙放行。在防火墙高级设置里添加入站规则，放行1433端口。这一步只影响远程连接，本机连接可以跳过。

第五步，用工具测试端口。命令行执行telnet localhost 1433，如果提示连接失败，说明端口根本没监听。

这套链路我每次部署新环境都会走一遍，十分钟内基本能定位问题。

6.3 用户'sa'登录失败

这个报错比“无法连接”稍微深一层，说明网络通、服务正常，但身份验证没过。根因也是三个最典型的。

第一，SQL Server没启用混合认证模式。解决方法：SSMS连接成功后，右键服务器 -> 属性 -> 安全性 -> 选“SQL Server和Windows身份验证模式”，然后重启服务。

第二，sa账号没启用。在SSMS的安全性 -> 登录名 -> sa，右键属性 -> 状态 -> 登录 -> 选“启用”。

第三，密码不对或者有特殊字符被转义。SQL Server的sa密码建议避免包含;，因为这个字符会破坏连接字符串的解析。我见过不止一次，密码里带;导致连接字符串被截断。

6.4 MSI安装失败时的日志定位技巧

前面说了安装失败的大方向，这里补充一个非常实用的日志定位技巧。SQL Server安装程序会在C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log目录下生成安装日志，按时间戳分文件夹。里面的Summary.txt会列出安装过程中每个功能的执行状态，Detail.txt会给出具体的报错模块。

我看到过一个真实案例，用户安装2022一直失败，日志里指向Fuzzy Lookup组件安装问题，后来发现是他的Windows系统缺少某个更新补丁。这就说明，安装失败不一定是SQL Server本身的问题，操作系统环境占很大因素。所以排查顺序是：看日志定位失败组件，查该组件依赖的系统功能，补环境，再重试。

6.5 为什么别人能连上，我连不上

最后说一个很玄学但很常见的情况：同一台服务器，A电脑能连数据库，B电脑连不上。先别怀疑数据库配置，先检查两台电脑的网络差异。ping一下服务器IP，再telnet 服务器IP 1433看端口通不通。如果B电脑ping不通，那是网络路由的问题；ping得通但端口不通，那不是防火墙就是服务器只监听了特定IP。

有时候SQL Server的TCP/IP会监听在“所有地址”上，有时候因为安装了多个实例会绑定到固定端口。在配置管理器里查看TCP/IP的属性，找到“IPAll”下的“TCP端口”，确认是1433。如果端口不为1433，连接字符串里就必须带上端口号。

这个排查思路同样适用于连接云服务器上的SQL Server，只不过云厂商的安全组规则也要检查一遍。我调试过很多“连不上”的问题，最后发现基本都是端口没放行，很少是数据库本身坏了。

学C#和SQL Server，路径其实很清晰：装好环境，学会连接，跑通增删改查，再在实践中慢慢体会事务、并发、性能这些进阶概念。不要一上来就追求花哨的技术，先把最朴素的流程走一遍，踩过的坑自然会让你的理解上一个台阶。

最后再分享一个小习惯：我写数据库相关代码时，永远先SQL后C#。在SSMS里把SQL语句调通了，再粘贴到C#里做参数化封装。这样能排除掉“到底是SQL写错还是C#代码写错”的干扰，排查问题速度快很多。你们也可以试试这个工作流，效率提升是立竿见影的。