企业官网建设流程全解析

2026年开年第一坑：SQL Server 从安装到日常操作的完整梳理

2026年1月20日，元旦刚过没多久，手头正好接了个小项目，需要在Windows Server上部署一套SQL Server环境供业务系统使用。本来以为就是“下一步下一步”的事，结果从版本选择到安装完成，再到建库建表、性能排查，零零碎碎踩了不少坑。趁这几天有空，把这些经验整理成一篇实操笔记，围绕SQL Server的安装、基础操作、查询优化和日常问题排查几个方向全部过一遍。无论你是刚接触数据库的学生，还是从MySQL转过来的开发，又或者是被临时拉去救火的运维，这篇文章都适用，读完能少走很多弯路。

先说一个很多人问的问题：SQL Server到底选哪个版本？其实版本选对了，后面能省一大半麻烦。我这次安装的是SQL Server 2022 Standard，原因很简单：项目需要正式环境，Express版虽然免费但内存限制1GB、数据库大小限制10GB，对生产业务来说太憋屈。如果只是学习入门，完全可以装Express版，功能上和正式版几乎一样，日常练手完全够用。

1. 安装之前先想清楚：版本选哪个、装之前要准备什么

1.1 版本选择：2019还是2022，Express够不够用

SQL Server目前主流版本是2019和2022，2008和2012已经属于老古董了，除非是接手遗留系统，否则不建议新装。2016和2017卡在中间，功能上没有质变，Veeam等备份软件的支持也没问题，但对新项目来说不是最优选择。

版本之间怎么选，我按实际情况总结了一张表：

另外还有Developer版本，功能和Enterprise一样，但只允许开发和测试使用，不可以用于生产环境。学习SQL Server、看执行计划、研究索引调优，用Developer版免费且无功能阉割，这是微软留给学习者的一大福利，别浪费。

选择版本时还要考虑一个问题：业务场景需要哪些高级功能。比如Always On可用性组，Standard版从2016开始支持基本版，但只允许一个辅助副本；Enterprise版支持更多副本和只读路由。如果是简单的主备场景，Standard版够用；如果需要复杂的读写分离，预算充足就直接Enterprise。

1.2 安装前检查清单与常见坑

很多人一上来就下载安装包，结果装到一半报错，然后到处找答案。其实安装前的环境检查做足了，90%的问题都可以提前避免。我这次实际踩过的一个坑就是：Windows Server上的.NET Framework版本太旧，安装程序直接弹窗提示缺组件，被迫中断。

安装前建议按这个清单过一遍：

• 操作系统版本：SQL Server 2022要求Windows 10 1607以上或Windows Server 2016以上，并且是64位系统。32位系统只能装老版本，这个不必纠结。
• .NET Framework：SQL Server 2022需要.NET Framework 4.7.2以上，装之前可以去“控制面板-程序-启用或关闭Windows功能”里检查。缺了就去微软官网下个运行时补上。
• 磁盘空间：完整安装大概需要6GB以上，算上后续数据库文件增长和数据备份，建议至少预留20GB。只装数据库引擎会小一些，但别卡着线装。
• 内存：Express版理论上512MB就能跑，但实际使用会卡到怀疑人生。新装环境建议4GB起步，Windows本身就要吃2GB左右。
• 防火墙：安装过程中会自动放行1433端口，但如果你的环境里预先配置了安全策略，装完后检查一下防火墙规则，别让外部客户端连不上。
• 安装账户：建议给SQL Server服务创建独立账户，不要用管理员账户跑服务。虽然单机学习环境怎么弄都没事，但生产环境的安全基线还是得做好。

还有一个很常见的困惑是：下载时不知道去哪里找安装包。微软官网的SQL Server下载页面是最靠谱的来源，输入关键词“SQL Server下载”就能找到官方入口。第三方下载站虽然有时候确实能下到完整ISO，但安全风险太高，尤其是公司环境，被装了后门软件就麻烦了。百度网盘分享的安装包同样来路不明，强烈不建议在生产环境使用，官方渠道下载慢一点也无所谓，安全第一。

2. 动手安装：从下载到SSMS连上数据库

2.1 安装SQL Server数据库引擎的完整步骤

我这次装的SQL Server 2022 Standard，过程比想象中顺利，可能是因为版本比较新，安装程序对Windows Server 2022的适配已经很成熟了。下面按步骤写一下实际操作流程。

第一步，右键下载好的安装程序，选择“以管理员身份运行”。这一步很关键，不要直接双击，否则UAC提示出来时选择“是”也可以，但在部分企业环境中，非管理员账户双击会导致安装程序在写入系统目录时权限不足，装一半就退出了。

第二步，安装程序启动后，界面会分几个选项，选择“全新SQL Server独立安装或向现有安装添加功能”。如果只是首次安装，选这个就好。不要选“从SQL Server安装媒体升级”，那是给老版本升级用的。

第三步，产品密钥页面。Standard版需要输入密钥，Developer版则需要勾选“指定可用版本”然后选Developer。密钥在购买时的邮件里，如果是MSDN订阅，在Azure门户的订阅权益页面可以找到。千万别把密钥放U盘里搞丢了，补发流程很折磨人。

第四步，许可条款页面直接勾选“我接受许可条款”，接着会进入功能选择页。对于大多数场景，至少需要勾选“数据库引擎服务”和“客户端工具连接”。SSMS（SQL Server Management Studio）不在这个安装包里，需要单独下载安装。其他像Integration Services、Analysis Services这些，不是BI项目就不要勾，装多了不仅没意义，还给系统服务增加负担。

第五步，实例配置页面。默认的“默认实例”会在连接时用机器名或localhost直接访问，端口自动用1433。如果你打算在一台机器上装多个SQL Server实例，就选择“命名实例”，连接时写成“机器名\实例名”。我一般建议独立环境用默认实例，省事；但如果机器上已经有一个老实例了，新装一个命名实例互不干扰更稳妥。

第六步，服务器配置页面。这里配置SQL Server服务的启动账户和排序规则。默认的排序规则是SQL_Latin1_General_CP1_CI_AS，一般不用改，除非你确定业务有特殊需求。CI表示不区分大小写，AS表示区分重音，大多数中文业务系统用默认就好。

第七步，数据库引擎配置页面里有几个关键设置。身份验证模式选“混合模式”，也就是SQL Server身份验证加Windows身份验证，然后设置sa密码。很多教程让你只选Windows身份验证，说这样更安全，但实际开发中各种工具的连接串都需要SQL账号，到头来还得改回混合模式。设密码时别用弱密码，生产环境被扫到sa弱口令密码是迟早的事。下面可以勾选“添加当前用户”，这样后续用SSMS登录时可以直接用Windows身份验证，不用记密码。

第八步，后面的错误报告、临时目录选项保持默认即可，一路Next，最后检查安装配置，没问题就点“安装”。安装过程大概10到20分钟，期间会装实例共享目录、运行检查规则、配置服务等，等到进度条跑完出现“安装完成”的界面，就说明数据库引擎已经装好了。

2.2 安装SSMS并完成第一次连接

数据库引擎装完只是第一步，第二步是装SSMS。SSMS就是SQL Server的管理工具，相当于图形化的操作台，建库建表跑查询都在里面完成。坏消息是SSMS需要单独下载，好消息是微软把下载页面放在了专门的SSMS下载地址，免费且更新频率高，一般一个月左右一个小版本。

下载后直接双击安装，安装过程相对简单，选择安装位置即可。装完后在开始菜单里找到“Microsoft SQL Server Management Studio 18”或“20”（版本号取决于你下载的哪个），打开后弹出连接对话框。

连接配置如下：

• 服务器类型：数据库引擎
• 服务器名称：填写localhost或者机器名，如果是命名实例就写localhost\实例名
• 身份验证：Windows身份验证或者SQL Server身份验证（填sa和密码）

点击“连接”后，左侧对象资源管理器里会显示数据库列表，包括系统数据库master、model、msdb、tempdb，以及你自己建的库。此时SQL Server已经可以正常使用了。

我第一次装的时候遇到过一个问题：SSMS连不上，报错提示“已成功与服务器建立连接，但在登录过程中发生错误”。原因是当时只选了Windows身份验证，防火墙又没放行1433端口，外部工具连接全被拦了。后来把身份验证改成混合模式，在SQL Server配置管理器里启用了TCP/IP协议，才能正常连接。如果你也遇到连不上问题，按这个思路检查：协议是否启用、防火墙是否放行、服务是否启动、身份验证模式是否正确。

2.3 安装失败与连接报错快速处理

安装和连接过程中报错是常态，遇到问题先别慌，绝大多数都有规律。我遇到过的主要有几种：

• 安装时提示“此版本的SQL Server需要.NET Framework 4.7.2”，解决方式是去“设置-应用-可选功能”或“控制面板-程序和功能-启用或关闭Windows功能”中确认.NET Framework状态，缺了就装，装完重启再运行安装程序。
• 安装后SSMS登录报“无法连接到localhost”，第一步确认“SQL Server服务”是否启动。按下Win+R，输入services.msc，找到“SQL Server (实例名)”服务，状态是“正在运行”才算正常。如果没启动，右键启动，并把启动类型改成“自动”，否则服务器重启后数据库服务不会自动拉起。
• 连接时报“客户端无法建立到SQL Server的连接”，优先检查SQL Server配置管理器——打开后选择“SQL Server网络配置-实例名的协议”，右侧确保TCP/IP已启用，双击TCP/IP去IP地址页，把IPAll里的TCP端口填成1433。
• 防火墙问题：SQL Server安装时通常会添加防火墙入站规则，但如果你换过端口，或者安装时取消了防火墙配置，就需要手动新增规则，放行1433端口或对应实例的端口。

有一类问题在SQL Server 2008上非常经典：想删除数据库，但一直提示失败。原因是SQL Server 2008（包括2008 R2）在删除数据库时，会检查该数据库是否正在被使用，如果有连接占用，比如其他人开着SSMS查询，删除就会卡住或者报错。解决办法是先将数据库设置为“单用户模式”再删除，或者先杀掉占用连接的进程。虽然新版本SQL Server在这方面有所改进，但在并发环境下依然会遇到类似问题，执行删除操作前一定要确认没有业务连接正在使用。

3. 建库建表与增删改查：把最基本的操作练熟

3.1 创建数据库与数据表

安装和连接搞定后，接下来就是日常最频繁的操作了。SQL Server的日常操作核心可以分成三个部分：建库建表、增删改查、查询优化。把这三个练熟，日常开发基本就不会慌了。

先看创建数据库。SSMS图形化的操作方式是：在对象资源管理器里右键“数据库”，选“新建数据库”，填一个数据库名称，比如ProjectDB，然后点击“确定”。SQL Server会自动生成一个主数据文件（.mdf）和一个日志文件（.ldf），默认放在安装目录的DATA文件夹下。

我更推荐直接写T-SQL语句来创建，尤其是需要脚本化交付的环境：

CREATE DATABASE ProjectDB ON PRIMARY ( NAME = N'ProjectDB', FILENAME = N'D:\Data\ProjectDB.mdf', SIZE = 100MB, MAXSIZE = UNLIMITED, FILEGROWTH = 64MB ) LOG ON ( NAME = N'ProjectDB_log', FILENAME = N'D:\Data\ProjectDB_log.ldf', SIZE = 64MB, MAXSIZE = UNLIMITED, FILEGROWTH = 64MB );

这里有几个细节值得注意：

• 文件路径尽量放在独立的业务数据盘，不要和系统盘混在一起，否则磁盘IO互相干扰。
• SIZE是初始大小，FILEGROWTH是自动增长步长。生产环境建议把初始大小设置成接近实际容量的值，避免频繁自动增长造成碎片。
• MAXSIZE设为UNLIMITED是上限不设限制，但实际生产环境建议设一个上限，防止某个失控任务把磁盘写满。

创建数据表的语句也很基础，但参数和类型选不对，后面会很被动。以一个用户信息表为例：

CREATE TABLE dbo.Users ( UserID INT IDENTITY(1,1) NOT NULL PRIMARY KEY, UserName NVARCHAR(50) NOT NULL, Email NVARCHAR(100) NULL, CreatedDate DATETIME NOT NULL DEFAULT(GETDATE()) );

这里有三个点要说明：

• NVARCHAR和VARCHAR的区别：NVARCHAR存Unicode，能存中文和各种字符，VARCHAR只能存非Unicode字符。只要业务有中文输入，统一用NVARCHAR，别在这上面省空间。
• IDENTITY(1,1)表示自增，相当于MySQL的AUTO_INCREMENT，每次插入数据自动加1，不用手动指定。
• DEFAULT(GETDATE())会在插入数据时自动填充当前时间，省得每次写INSERT都必须带上时间字段。

如果你是从MySQL转过来的，会明显感觉到两者的差异：MySQL中用AUTO_INCREMENT，SQL Server用IDENTITY；MySQL中反引号包围标识符，SQL Server用方括号；MySQL中类型有TINYINT、DATETIME等，SQL Server类型更丰富，比如DATETIME2、SMALLDATETIME。这些差异不算大，但写语句时容易混淆。

3.2 增删改查语句与自增主键

建好表之后就是增删改查，这部分语法和标准SQL基本一致，直接上示例。

插入数据：

INSERT INTO dbo.Users (UserName, Email) VALUES ('张三', 'zhangsan@example.com');

不需要写UserID字段，IDENTITY自增列会自动生成。如果一次插入多条数据，可以写成：

INSERT INTO dbo.Users (UserName, Email) VALUES ('李四', 'lisi@example.com'), ('王五', 'wangwu@example.com');

查询数据：

SELECT UserID, UserName, Email, CreatedDate FROM dbo.Users WHERE UserName LIKE N'%张%' ORDER BY CreatedDate DESC;

这里注意LIKE配合中文条件时，前面最好加上N前缀，表示后面的字符串是Unicode字符，否则某些排序规则下会查不到结果。这个坑很隐蔽，我见过不少人在中文模糊查询时，明明有数据却查不出来，就是少了这个N。

更新数据：

UPDATE dbo.Users SET Email = 'newname@example.com' WHERE UserID = 1;

删除数据：

DELETE FROM dbo.Users WHERE UserID = 1;

DELETE和TRUNCATE的区别也值得说一下：DELETE是逐行删除，可以加WHERE条件，会记录事务日志，删除速度慢但可控；TRUNCATE是直接释放整个表的数据页，不能加WHERE，速度快但不可恢复。如果只是想清空表数据而保留表结构，用TRUNCATE更合适，但如果要保留事务日志以便误删恢复，还是老老实实用DELETE。

3.3 常用时间函数与字符串函数

SQL Server的时间函数和字符串函数，是日常写查询时最高频的工具集。很多人从MySQL转过来后，拿到时间字段不知道怎么处理，这里把最常用的一批整理出来。

时间函数方面：

-- 当前时间 SELECT GETDATE(); -- 返回带毫秒的日期时间 SELECT SYSDATETIME(); -- 返回更高精度的日期时间 SELECT CURRENT_TIMESTAMP; -- 等价于GETDATE() -- 日期部分提取 SELECT DATEPART(YEAR, GETDATE()); -- 当前年份 SELECT DATEPART(MONTH, GETDATE()); -- 当前月份 SELECT DAY(GETDATE()); -- 当前日 SELECT DATENAME(WEEKDAY, GETDATE()); -- 星期几，返回中文或英文名称 -- 日期加减 SELECT DATEADD(DAY, 7, GETDATE()); -- 七天后 SELECT DATEADD(MONTH, -1, GETDATE()); -- 一个月前 -- 日期差 SELECT DATEDIFF(DAY, '2026-01-01', '2026-01-20'); -- 结果为19 -- 格式化 SELECT FORMAT(GETDATE(), 'yyyy-MM-dd HH:mm:ss');

FORMMAT函数虽然方便，但性能比CONVERT差不少。如果要对几十万行数据做格式化输出，建议用CONVERT配合样式号：

SELECT CONVERT(VARCHAR(19), GETDATE(), 120); -- 输出 yyyy-MM-dd HH:mm:ss

字符串函数方面，最常用的是：

SELECT LEN(N'abc'); -- 3，返回字符数 SELECT DATALENGTH(N'abc'); -- 6，返回字节数 SELECT LEFT(N'abcdef', 3); -- abc SELECT RIGHT(N'abcdef', 3); -- def SELECT SUBSTRING(N'abcdef', 2, 3); -- bcd，从第2位开始取3个 SELECT CHARINDEX(N'c', N'abcdef'); -- 3，查找子串位置 SELECT REPLACE(N'abcabc', N'bc', N'xy'); -- axyaxy SELECT UPPER(N'abc'); -- ABC SELECT LOWER(N'ABC'); -- abc

这里有一个容易踩坑的点：LEN和DATALENGTH的区别。LEN返回的是字符个数，但会忽略尾部空格；DATALENGTH返回的是字节数，不忽略尾部空格。对中文字符来说，DATALENGTH往往是LEN的两倍，因为每个中文字符占两个字节。比如LEN(N'你好')是2，DATALENGTH(N'你好')是4。如果你模糊查询时发现结果数量不对，大概率是没意识到这个差异。

4. 查询优化：别等慢到受不了才想起来

4.1 索引怎么加、加在哪

如果只是学基础操作，前面的内容已经可以应付很多场景了。但SQL Server用得越久，越能感受到查询优化的重要性，尤其是数据量上来之后，一个糟糕的查询可以把整个数据库拖垮。

查询优化的核心是索引。索引相当于书的目录，没有索引的查询就是整本书从头翻到尾，速度必然慢。SQL Server的索引主要分为聚集索引和非聚集索引两种。

聚集索引决定了表数据的物理存储顺序，每张表只能建一个，默认就是主键。非聚集索引是单独存储的索引结构，每张表可以建很多个，查询时先查索引，再根据索引中的书签找到对应的数据行。

加索引的原则，从实际经验来说总结成几条：

• 针对WHERE条件中频繁出现的字段加索引。
• 针对JOIN的关联字段加索引。
• 针对ORDER BY排序字段加索引，避免额外的排序操作。
• 选择性高的字段比选择性低的字段更适合建索引。比如“性别”字段只有男和女两种值，建索引意义不大；而“Email”字段几乎每条都不一样，建索引效果就非常明显。
• 不要对频繁更新的字段建太多索引，每次INSERT、UPDATE、DELETE都要同步更新索引，会增加额外开销。

创建索引的语句：

CREATE NONCLUSTERED INDEX IX_Users_Email ON dbo.Users(Email);

查询时如果发现SQL Server选择走索引，执行计划里会显示“Index Seek”，比“Table Scan”快得多。

4.2 查看执行计划定位慢查询

光知道加索引还不够，得知道问题到底出在哪里。SQL Server提供了一个非常强大的可视化工具——执行计划。在SSMS里选中一条查询语句，点击工具栏上的“显示估计的执行计划”或直接按Ctrl+L，就能看到SQL Server会怎么执行这条SQL。

执行计划会展示一串图标，从右往左读，每个图标代表一种操作，比如Clustered Index Scan（聚集索引扫描）、Index Seek（索引查找）、Nested Loops（嵌套循环）、Hash Match（哈希匹配）、Sort（排序）。其中比较“贵”的操作是扫描和排序，扫描表示没用上索引，排序表示额外内存和CPU开销。

定位慢查询的标准思路是：

• 使用SQL Server Profiler或扩展事件跟踪慢查询，找到耗时长、读取量大的SQL语句。
• 在SSMS中复制该SQL，查看执行计划，看哪些操作占比最高。
• 针对占比最高的操作做优化：加索引、重写查询、拆分大事务。
• 优化后对比执行计划和IO统计，确认提升效果。

查看IO统计是一个容易被忽略但很实用的技巧。在SSMS中执行以下命令，然后再跑查询：

SET STATISTICS IO ON; SET STATISTICS TIME ON; SELECT * FROM dbo.Users WHERE Email = 'zhangsan@example.com';

消息选项卡里会显示“逻辑读取次数”。逻辑读取次数越低，说明查询效率越高。优化前几千次，优化后几十次，这个对比比任何理论都直观。

关于SQL Server Profiler，每次要新建模板的时候，默认模板可以覆盖90%的跟踪需求。网上很多“SQL Server Profiler模板下载”的资源，其实没必要去找，自己在SQL Server Profiler里新建跟踪，勾选SQL:BatchCompleted和SQL:StmtCompleted事件，筛选CPU和Duration超过阈值的语句就足够了。模板这东西自己建一次，以后直接复用还更顺手。

4.3 内存占用过高的排查思路

SQL Server还有一个让运维头疼的问题：内存占用太高。装完SQL Server后，你可能会发现Windows任务管理器里SQL Server进程占用了大量物理内存，但这是在不出问题时的正常现象。SQL Server默认会尽可能多地占用可用内存作为缓冲池，用来缓存数据页，减少磁盘IO。如果不希望SQL Server把内存吃满，可以在服务器属性里设置“最大服务器内存”。

设置方法有两种。一种是SSMS图形化：右键服务器，选择“属性”，点击“内存”，把“最大服务器内存”改成一个合理的值。更推荐用T-SQL设置，因为可以在脚本中统一管理：

EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max server memory', 8192; -- 单位为MB，这里设置8GB RECONFIGURE;

这里有个关键点：给SQL Server分配的最大内存不等于整个系统的内存，要预留一部分给Windows操作系统和应用程序。经验值是如果服务器有32GB内存，给SQL Server设24GB左右，剩下8GB给OS和监控代理等程序。

排查“SQL Server Windows NT占用内存”问题时，先要判断是正常缓存还是内存泄漏。正常缓存的表现是长时间运行后内存占用稳定在一个高位，重新启动服务后内存释放，之后又慢慢涨上来；异常的表现是内存持续增长不回落，甚至触发操作系统级的内存压力，其他应用开始卡顿。两者处理思路完全不同：正常缓存调低最大服务器内存即可，异常情况则要看具体等待类型，比如PAGEIOLATCH_SH和PAGEIOLATCH_EX过高，说明内存压力大且磁盘IO跟不上。

5. 容易被忽略的日常维护与问题排查

5.1 无法删除数据库的常见原因

日常维护中经常遇到一类问题：删除数据库时失败，报错提示“数据库正在使用，无法删除”。直观感受是“明明没人用啊，怎么就删不掉”。

这种情况通常是几个原因引起的：

• SSMS的对象资源管理器或查询窗口里占用着该数据库。比如有查询窗口执行了USE ProjectDB，这时数据库就一直有外部连接。
• 后台作业、报表订阅或第三方工具持有数据库连接。
• 数据库正处于单用户模式或只读模式。

解决办法，先杀掉占用连接再删库。查询当前有哪些进程：

SELECT session_id, login_name, status FROM sys.dm_exec_sessions WHERE database_id = DB_ID('ProjectDB');

找到阻塞的session_id后，可以杀掉：

KILL 57; -- 把57换成实际session_id

如果连接太多不便逐个查看，直接把数据库设为单用户模式再删除：

ALTER DATABASE ProjectDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE ProjectDB;

这里WITH ROLLBACK IMMEDIATE很关键，它会把还未提交的事务回滚掉，强制断开所有连接。生产环境执行前一定要确认没有正在跑的重要事务，一旦回滚，那些事务的执行结果就没有了。

SQL Server 2008/2008 R2里这个问题更突出。老版本的SQL Server在删除大数据库时，如果数据文件很大，删除操作本身就很慢，加上2008对并发连接的承受能力弱点，单用户模式基本成了删库标配步骤。如果你还在维护SQL Server 2008环境，建议尽早规划升级，毕竟扩展支持已经结束，安全风险会越来越大。

5.2 客户端连接错误08001排查

还有一个非常常见的连接报错，文本大概是这样的：

[08001] [Microsoft][ODBC Driver 18 for SQL Server]命名管道提供程序: 无法打开与SQL Server的连接

这个报错会出现在很多场景里，比如通过ODBC连接SQL Server、用Python的pyodbc连接、用Power BI导入数据时。看起来是命名管道（Named Pipes）的问题，但实际上并不一定要使用命名管道。

SQL Server客户端默认的连接方式和连接字符串密切相关。默认的连接协议顺序是：Shared Memory、TCP/IP、Named Pipes。如果连接字符串里没有指定协议，客户端会按顺序尝试。报错提到命名管道无法打开，可能的原因包括：

• TCP/IP协议未启用，客户端尝试了TCP/IP失败后，回退到命名管道也失败。
• 防火墙阻断了1433端口，导致TCP/IP根本无法建立连接，客户端自动降级到命名管道。
• 连接字符串里明确指定了“Named Pipes”作为协议，但是SQL Server配置管理器里的Named Pipes协议被禁用了。
• 目标SQL Server实例不在本机，命名管道跨机器访问时还需要额外的netbios解析，更容易出问题。

排查思路很简单。第一，检查SQL Server配置管理器，把TCP/IP和Named Pipes都启用。第二，检查防火墙，确保1433端口可访问。第三，在连接字符串里显式指定TCP/IP协议，比如：

conn_str = ( "DRIVER={ODBC Driver 18 for SQL Server};" "SERVER=192.168.1.100,1433;" "DATABASE=ProjectDB;" "UID=sa;" "PWD=你的密码;" "Encrypt=yes;TrustServerCertificate=yes;" )

注意ODBC Driver 18及以后版本默认启用Encrypt=yes，如果SQL Server没有配置证书，连接会失败。解决方式是在连接字符串里显式加上Encrypt=yes;TrustServerCertificate=yes；如果在你自己的可控环境里，直接加上Encrypt=no也可以，但生产环境建议还是配证书。

Python程序员在Windows上连接SQL Server时很喜欢用pyodbc，但配置不熟时最容易踩两个坑：一个是ODBC驱动版本不对，32位程序用了64位的ODBC驱动；另一个是连接超时，把连接池的空闲超时错当成连接超时去调，结果毫无作用。我的习惯是检查驱动时执行：

import pyodbc print(pyodbc.drivers())

把输出的驱动名和连接字符串里的DRIVER名称一一对应，确保完全一致。

5.3 正则表达式与SQL Server的边界

另一个经常引起新手混乱的问题是SQL Server和正则表达式的关系。很多人用过MySQL的REGEXP，到了SQL Server发现没有直接对应的函数，就开始怀疑是不是自己没找到。

实际上SQL Server从2022版本开始内置了正则表达式函数REGEXP_LIKE、REGEXP_SUBSTRING和REGEXP_REPLACE，但需要数据库兼容级别达到160才能使用。如果用的还是2019版本，就需要用LIKE配合通配符来做简单的模式匹配，或者用CLR自定义函数扩展正则能力。

比如用LIKE查询以“张”开头的用户名：

SELECT UserName FROM dbo.Users WHERE UserName LIKE N'张%';

LIKE的通配符只有几个：%匹配任意长度字符串，_匹配单个字符，[abc]匹配集合中的任意一个字符，[^abc]匹配不在集合中的字符。这个能力对于简单的模式匹配是够用的，但复杂场景比如校验电话号码格式、提取特定模式文本，LIKE就力不从心了。

SQL Server 2022的正则表达式写法：

SELECT UserName FROM dbo.Users WHERE REGEXP_LIKE(UserName, N'^张');

这个功能目前用的人还不多，因为很多线上环境还停留在2019甚至更老版本。需要跨版本兼容时，要么改写为LIKE，要么在应用层处理正则逻辑，不建议为了一个正则功能拉高数据库版本。在版本升级计划里把这个需求列进去，等版本升上去后再切换到原生正则。

这个例子也说明了版本和功能之间的强关系。SQL Server 2022相比2019，本机在备份压缩、TLS 1.3支持、Intelligent Query Processing等方面都有增强，但升级数据库版本是一个系统工程，涉及兼容性评估、回归测试、备份恢复策略，不是说升就升的。网上很多“SQL Server 2022下载”的资源，下载安装前先确认你所在组织的许可和合规要求，个人学习环境则无所谓，装就完了。

5.4 常用维护脚本和备份策略

最后补充几个日常维护中非常实用的小脚本。这些脚本都是我在实际使用中验证过的，随取随用。

检查所有数据库的大小：

SELECT db.name AS DatabaseName, CAST(SUM(mf.size) * 8 / 1024.0 AS DECIMAL(12, 2)) AS SizeMB FROM sys.databases db JOIN sys.master_files mf ON db.database_id = mf.database_id GROUP BY db.name ORDER BY SizeMB DESC;

查看当前正在运行的请求：

SELECT r.session_id, r.status, r.command, DB_NAME(r.database_id) AS DatabaseName, r.wait_type, r.wait_time, r.cpu_time, r.total_elapsed_time FROM sys.dm_exec_requests r ORDER BY r.total_elapsed_time DESC;

这个查询对排查阻塞和死锁特别有用。如果看到某个session_id的wait_type是LCK_M_X，说明它在等一把排他锁，大概率就是阻塞源。

备份数据库的常规语句：

BACKUP DATABASE ProjectDB TO DISK = N'D:\Backup\ProjectDB_20260120.bak' WITH INIT, COMPRESSION;

备份文件命名最好带上日期，方便保留策略做轮转。配合SQL Agent作业，可以做到每天自动备份、每周完整备份、每小时日志备份，但前提是你愿意花时间配置维护计划，生产环境这是必须的投入。

微软最近大力推广SQL Server 2022的备份到对象存储功能，也就是直接把备份文件写入Azure Blob或S3兼容存储，这对异地容灾很有帮助。不过目前在生产环境落地还不多，等生态再成熟一些，异地容灾的复杂度会大幅降低。

写在最后的几个经验

其实SQL Server安装和入门不难，难的是遇到问题时知道去哪里分析和排查。这次从安装到建库建表，再到查询优化和问题排查走了一遍，有几个感触特别深：

安装前多花十分钟检查环境，比装到一半报错再回头找原因省事得多。版本选择别贪新也别念旧，根据业务需求来：学习用Developer或Express，生产用Standard，大并发高可用场景再考虑Enterprise。

查询优化这件事，别等到数据库卡顿才想起来。写SQL时养成看执行计划的习惯，逻辑读从几千降到几十的成就感，比堆一堆功能代码实在得多。日常维护脚本提前准备好，出问题时不用临时网上搜，数据库出问题时候每一分钟都很宝贵。

最后分享一个小习惯：我在建表时都会把表和字段的说明加上，用SQL Server的扩展属性功能，或者在表设计器的“说明”列里写清楚。一个人维护的项目可能看不出差别，但团队协作时，注释就是最低成本的知识传递机制。这也算是踩过好几年“代码看得懂，表结构看不懂”的苦头后总结出来的经验。