企业官网建设流程全解析

简介：本资源是一份系统、详实的SQL Server入门级学习笔记，面向数据库初学者、转行人员及运维/开发岗位中需快速掌握SQL Server核心概念与操作的从业者。笔记覆盖数据库基础理论（关系模型、实体-联系、数据约束）、关键DDL/DML语句（CREATE/DROP/ALTER/INSERT/UPDATE/DELETE）、权限管理（用户/角色/授权）、系统数据库作用（master/model/tempdb/msdb等）、物理存储结构（.mdf/.ndf/.ldf文件与文件组）以及各类约束（主键、外键、CHECK、UNIQUE等）的原理与实践要点。资源为1个499KB的Word文档（.doc），内容组织清晰，知识点归类明确，含大量结构化条目与典型示例，便于逐章研读与随查随用。目前已有440人学习下载，适合作为SQL Server知识体系搭建的首份手边参考，亦可作为备考认证或日常开发运维的速查备忘。

1. SQL Server 学习笔记：不是装完 Management Studio 就算入门，而是从「连不上数据库」开始的真实战场

很多刚接触 SQL Server 的开发者，第一反应是下载安装包、点下一步、打开 SSMS（SQL Server Management Studio），看到“已连接”就以为学完了。结果一写SELECT * FROM users就报错：“对象名 'users' 无效”；一建表就卡在“无法添加外键约束”；半夜跑个备份脚本，第二天发现日志文件暴涨到 200GB 却没留任何告警——这不是操作失误，是知识断层在真实生产环境里发出的尖锐警报。这份《SQL Server 学习笔记》不讲“数据库是什么”这种教科书定义，而是聚焦一线工程师每天要面对的六个硬核场景：如何让本地实例真正可连接、怎么把 Excel 表安全导入成带主键和索引的表、为什么DELETE FROM比TRUNCATE TABLE慢十倍还锁表、事务隔离级别怎么选才不丢数据也不卡死、备份策略怎么配才能保证 RPO＜5 分钟且恢复不翻车、以及最常被忽略的——查询计划里那个红色感叹号到底在警告什么。它适合两类人：一类是刚转岗 DBA 的后端开发，手上有业务库但不敢动；另一类是正在准备 SQL Server 认证或企业内训的技术骨干，需要可验证、可复现、能立刻用在今天下午上线前的 checklist。全文所有命令、配置、截图逻辑均基于 SQL Server 2019（兼容模式 150）实测，不依赖 Azure 或云托管服务，纯本地 Windows Server / Win10 环境可完整复现。

2. 从“已连接”到“真可用”：本地 SQL Server 实例的最小化连通性验证路径

SQL Server 安装完成后，SSMS 显示绿色“已连接”只是表象。真正的连通性必须通过三层验证：服务进程存活、TCP 端口可达、登录凭据与权限闭环。跳过任一层，后续所有 T-SQL 操作都可能在关键时刻静默失败。

2.1 验证 SQL Server 服务是否真正运行并监听 TCP

仅靠 Windows 服务管理器里显示“正在运行”不够。SQL Server 默认启用命名管道（Named Pipes），但远程连接和多数应用驱动（如 JDBC、pyodbc）强制走 TCP/IP。若 TCP 协议未启用，本地 SSMS 能连（走共享内存），但 Python 脚本就会报Network error: Connection refused。

# 步骤1：确认 SQL Server 服务名（常见为 MSSQLSERVER 或 SQLEXPRESS） sc query | findstr "MSSQL" # 输出示例：SERVICE_NAME: MSSQLSERVER → 对应默认实例 # 步骤2：检查 SQL Server 配置管理器中 TCP/IP 是否启用（需 GUI） # 手动路径：SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for [实例名] → 右键 TCP/IP → 启用 # ⚠️ 注意：启用后必须重启 SQL Server 服务！否则端口不监听 # 步骤3：验证端口是否实际监听（推荐 PowerShell，免 GUI） Get-NetTCPConnection -LocalPort 1433 -State Listen | Select-Object LocalAddress, LocalPort, State, OwningProcess # 若无输出，说明端口未监听 → 检查 SQL Server 配置管理器 + 服务重启

提示：默认端口 1433 可被防火墙拦截。即使端口监听，Windows Defender 防火墙也可能阻止入站连接。临时放行命令：

New-NetFirewallRule -DisplayName "Allow SQL Server TCP 1433" -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow

2.2 用sqlcmd绕过 SSMS 做原子级连接测试

SSMS 是图形外壳，自带连接池、缓存和 UI 层错误掩盖。sqlcmd是微软官方命令行工具，直连 SQL Server 协议栈，报错信息更原始、更可信，是排查连接问题的“后悔药”。

# 测试 Windows 身份验证（本地管理员组成员默认有 sysadmin 权限） sqlcmd -S localhost -E -Q "SELECT @@VERSION AS Version; SELECT name FROM sys.databases;" # 测试 SQL Server 身份验证（需提前创建登录名） sqlcmd -S localhost -U sa -P 'YourStrong@Passw0rd' -Q "SELECT SUSER_NAME() AS LoginName;" # 关键参数说明： # -S：服务器名（localhost / . / (local) / 127.0.0.1 均可，但不要用 .\SQLEXPRESS 这种带反斜杠的格式，易触发解析错误） # -E：Windows 身份验证（免密码，依赖当前 Windows 用户权限） # -U/-P：SQL Server 身份验证（sa 密码必须符合复杂度要求：大+小+数字+符号，长度≥8） # -Q：执行单条语句后退出（避免进入交互模式，适合脚本集成）

逻辑说明：该命令同时验证三件事：① TCP 连接建立成功；② 身份验证通过；③ 用户至少有public角色权限（能执行SELECT @@VERSION）。若失败，错误码直接指向根因：

• Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Login failed for user 'sa'.→ 密码错误或 sa 账户被禁用；
• Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : A network-related or instance-specific error...→ TCP 未启用或端口被占；
• Msg 229, Level 14, State 5, Server ..., Line 1: The SELECT permission was denied on the object 'databases'...→ 用户权限不足，需授权。

2.3 创建首个业务登录名与数据库用户：权限最小化实践

很多新手直接用sa跑应用，这是高危操作。真实项目必须遵循“最小权限原则”：应用账号只能访问指定数据库的指定表，且只拥有SELECT/INSERT/UPDATE，禁用DROP/ALTER/CREATE。

-- 步骤1：在 master 数据库创建登录名（Login），作用域为整个 SQL Server 实例 USE master; GO CREATE LOGIN app_user WITH PASSWORD = 'AppP@ssw0rd2024!', CHECK_EXPIRATION = ON, CHECK_POLICY = ON; -- 启用 Windows 密码策略（强制复杂度、历史记录） -- 步骤2：切换到目标业务数据库（如新建的 SalesDB），创建数据库用户（User） USE SalesDB; GO CREATE USER app_user FOR LOGIN app_user; -- 步骤3：授予最小必要权限（非 db_owner！） -- 允许读写 SalesDB 中所有用户表 ALTER ROLE db_datareader ADD MEMBER app_user; ALTER ROLE db_datawriter ADD MEMBER app_user; -- ⚠️ 关键限制：禁止删除表、修改结构 -- 显式拒绝危险权限（即使角色继承了，DENY 优先级高于 GRANT） DENY ALTER ANY DATABASE TO app_user; DENY CONTROL SERVER TO app_user;

参数说明与血泪经验：

• CHECK_POLICY = ON是安全基线，但会导致app_user密码受 Windows 域策略约束（如 90 天过期）。若应用需长期稳定运行，可设为OFF，但必须配合定期人工轮换；
• db_datareader/db_datawriter是预定义角色，比逐个GRANT SELECT ON table1更易维护，且自动适配新表（只要新表属dbo架构）；
• DENY必须显式声明——因为db_owner角色隐含CONTROL DATABASE，而CONTROL权限会覆盖所有GRANT，所以不用DENY就等于没限制。

3. 把 Excel 表变成生产级表：从数据导入到索引优化的完整链路

Excel 是业务部门最常用的原始数据载体，但直接SELECT * FROM OPENROWSET(...)或复制粘贴进 SSMS，得到的是“数据存在”，不是“可运维的表”。真实场景要求：主键自增、时间戳自动更新、关键字段加索引、空值严格校验。本节以销售订单表SalesOrder为例，演示从 Excel 到生产表的七步法。

3.1 准备 Excel 源文件：字段规范与类型对齐

Excel 不是数据库，没有类型约束。导入前必须人工约定：

• 第一行必须为列名（无合并单元格）；
• OrderID列全为数字，且无重复（将作为主键）；
• OrderDate列格式为YYYY-MM-DD或MM/DD/YYYY（避免DD/MM/YYYY引发区域解析歧义）；
• Amount列禁止货币符号（如$1,234.56→ 改为1234.56）；
• 空单元格统一填NULL文本（便于后续识别）或留空（SQL Server 默认转为NULL）。

注意：Excel 2007+ 文件（.xlsx）不能被OPENROWSET直接读取，必须先另存为.xls（Excel 97-2003 格式），或改用ACE.OLEDB.12.0提供程序（需安装 Microsoft Access Database Engine）。

3.2 用 SQL Server Import and Export Wizard 生成可复用脚本

GUI 向导易操作，但无法版本化、无法审计。正确做法是：先用向导完成一次导入，勾选“编写脚本”，再保存为.sql文件，后续全部用该脚本执行。

-- 向导生成的核心脚本片段（已精简，保留关键逻辑） -- 步骤1：创建目标表（注意：向导默认不加主键和索引！必须手动补） CREATE TABLE [dbo].[SalesOrder]( [OrderID] [int] IDENTITY(1,1) NOT NULL, [CustomerName] [nvarchar](100) NULL, [OrderDate] [date] NULL, [Amount] [decimal](18, 2) NULL, [CreatedTime] [datetime2](7) DEFAULT (getdate()) NOT NULL, CONSTRAINT [PK_SalesOrder] PRIMARY KEY CLUSTERED ([OrderID] ASC) ) ON [PRIMARY]; -- 步骤2：插入数据（向导用 BULK INSERT，比 INSERT INTO ... SELECT 快 10 倍） BULK INSERT [dbo].[SalesOrder] FROM 'C:\Data\SalesOrder.xls' WITH ( FORMATFILE = 'C:\Data\SalesOrder.fmt', -- 格式文件定义列映射 FIRSTROW = 2, -- 跳过标题行 CODEPAGE = '65001', -- UTF-8 编码 DATAFILETYPE = 'widechar' -- Unicode 支持中文 ); -- 步骤3：为高频查询字段添加非聚集索引（向导不生成！） CREATE NONCLUSTERED INDEX [IX_SalesOrder_OrderDate] ON [dbo].[SalesOrder] ([OrderDate] ASC);

参数说明：

• IDENTITY(1,1)实现主键自增，避免 Excel 中OrderID重复导致导入失败；
• DEFAULT (getdate())自动填充CreatedTime，无需应用层传值；
• CODEPAGE = '65001'是 UTF-8，解决中文乱码；若 Excel 为 ANSI 编码，需改为CODEPAGE = 'ACP'；
• FORMATFILE是关键：向导生成的.fmt文件明确定义 Excel 列与数据库列的顺序、类型、长度，避免列错位。

3.3 导入后必做的三重校验：数据完整性、性能、一致性

导入完成不等于结束。必须立即执行以下检查，否则上线后才发现数据错位或查询慢，代价巨大。

-- 校验1：行数一致性（Excel 行数 vs 数据库行数） -- Excel 行数：打开 Excel → 查看右下角状态栏（如“12,345 行”） -- 数据库行数： SELECT COUNT(*) AS RowCount FROM dbo.SalesOrder; -- 校验2：主键唯一性与空值（防止 Identity 插入失败后脏数据残留） SELECT COUNT(*) AS TotalRows, COUNT(OrderID) AS NonNullOrderID, COUNT(DISTINCT OrderID) AS DistinctOrderID, SUM(CASE WHEN OrderID IS NULL THEN 1 ELSE 0 END) AS NullOrderID FROM dbo.SalesOrder; -- 校验3：索引有效性（查看执行计划是否走索引） SET STATISTICS XML ON; SELECT * FROM dbo.SalesOrder WHERE OrderDate >= '2024-01-01'; SET STATISTICS XML OFF; -- 在 SSMS 结果栏点击“Execution plan”，确认 <IndexScan> 被替换为 <IndexSeek>

避坑 / 常见问题 / 排查

1. 现象：BULK INSERT报错Cannot insert the value NULL into column 'OrderID'
   原因：Excel 中OrderID列有空单元格，而数据库定义为NOT NULL IDENTITY，但BULK INSERT默认不跳过空行，尝试插入NULL触发约束。
   解决：在 Excel 中用Ctrl+G→ “定位条件” → “空值” → 填充连续数字；或修改建表语句，先建OrderID int NULL，导入后再UPDATE SET OrderID = ROW_NUMBER() OVER(ORDER BY (SELECT NULL))，最后ALTER COLUMN OrderID int NOT NULL并加主键。

2. 现象：导入后OrderDate全部变成1900-01-01
   原因：Excel 日期格式为“常规”而非“日期”，底层存储为浮点数（如44562.5表示 2022-01-01 12:00），BULK INSERT无法自动转换。
   解决：Excel 中选中日期列 → 右键“设置单元格格式” → “日期” → 选择YYYY-MM-DD；或导入时在.fmt文件中将该列类型设为SQLDATE而非SQLCHAR。

3. 现象：查询WHERE OrderDate = '2024-01-01'很慢，执行计划显示Clustered Index Scan（全表扫描）
   原因：未创建OrderDate索引，或索引创建失败（如表名写错、权限不足）。
   解决：运行SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID('SalesOrder')确认索引存在；若不存在，重新执行CREATE NONCLUSTERED INDEX语句，并检查当前用户是否有ALTER权限。

4. 现象：导入后Amount字段小数位丢失（如1234.56变成1234.00）
   原因：Excel 单元格格式为“数值”但小数位数设为 0，实际存储为整数；或.fmt文件中该列定义为SQLINT4而非SQLDECIMAL。
   解决：Excel 中选中金额列 → 右键“设置单元格格式” → “数值” → 小数位数设为 2；或修改.fmt文件，将Amount列的SQLDECIMAL精度改为(18,2)。

5. 现象：BULK INSERT成功，但SELECT COUNT(*)返回 0
   原因：BULK INSERT默认在隐式事务中执行，若中途出错（如磁盘满），整个操作回滚，但错误可能被忽略。
   解决：显式开启事务并捕获错误：

   BEGIN TRY BEGIN TRANSACTION; BULK INSERT ...; COMMIT TRANSACTION; END TRY BEGIN CATCH ROLLBACK TRANSACTION; THROW; -- 重新抛出错误，不静默 END CATCH

4. 查询性能生死线：读懂执行计划里的“红色感叹号”与三个关键指标

SQL Server 查询慢，90% 的根因藏在执行计划（Execution Plan）里。很多人只看“耗时多少秒”，却忽略计划中那个醒目的红色感叹号（Warning）、“估计行数 vs 实际行数”的巨大偏差、以及“缺少统计信息”的提示。本节教你用三步法，把执行计划从“天书”变成“调优地图”。

4.1 获取执行计划的两种可靠方式：图形化与 XML 模式

SSMS 图形界面最直观，但有时会因网络或权限问题加载失败。XML 模式是底层真相，可复制粘贴、用工具分析，且不受 UI 限制。

-- 方式1：图形化执行计划（快捷键 Ctrl+M，执行前开启） -- 在 SSMS 查询窗口中，先按 Ctrl+M，再执行： SELECT o.OrderID, o.OrderDate, c.CustomerName FROM SalesOrder o INNER JOIN Customer c ON o.CustomerID = c.CustomerID WHERE o.OrderDate >= '2024-01-01'; -- 方式2：XML 执行计划（更稳定，适合远程服务器） SET STATISTICS XML ON; GO -- 执行同上查询 SELECT o.OrderID, o.OrderDate, c.CustomerName FROM SalesOrder o INNER JOIN Customer c ON o.CustomerID = c.CustomerID WHERE o.OrderDate >= '2024-01-01'; GO SET STATISTICS XML OFF; -- 结果栏会多出一个“XML”标签页，右键“保存结果为...”可导出 .sqlplan 文件

提示：图形化计划中，节点大小代表相对成本（百分比），但这是“估计成本”，未必反映真实瓶颈。务必右键节点 → “属性”，查看Actual Number of Rows（实际行数）与Estimated Number of Rows（估计行数）的比值。若比值 > 10 或 < 0.1，说明统计信息严重过期，优化器做出了错误决策。

4.2 解析红色感叹号：最常见的三种警告及其修复

红色感叹号不是报错，而是 SQL Server 在说：“我按这个计划执行了，但过程很别扭，可能有更好方式。” 忽略它，就是给未来埋雷。

4.3 三个必看指标：从执行计划定位真实瓶颈

不要被“总耗时 2 秒”迷惑。一个查询可能 99% 时间花在磁盘 I/O，1% 在 CPU。执行计划中的三个指标，直接告诉你资源瓶颈在哪。

-- 步骤1：开启 IO 和 TIME 统计（比执行计划更底层） SET STATISTICS IO ON; SET STATISTICS TIME ON; GO SELECT o.OrderID, o.OrderDate, c.CustomerName FROM SalesOrder o INNER JOIN Customer c ON o.CustomerID = c.CustomerID WHERE o.OrderDate >= '2024-01-01'; GO SET STATISTICS IO OFF; SET STATISTICS TIME OFF;

输出解读（关键行）：

• Table 'SalesOrder'. Scan count 1, logical reads 1250, physical reads 0, read-ahead reads 1248
  →logical reads 1250：内存中读取了 1250 页（每页 8KB，约 10MB），若远大于表实际大小（sp_spaceused 'SalesOrder'），说明没走索引，全表扫描；
• Table 'Customer'. Scan count 1, logical reads 8, physical reads 0
  →logical reads 8：只读了 8 页，说明Customer表有高效索引（如主键聚集索引）；
• SQL Server Execution Times: CPU time = 15 ms, elapsed time = 1250 ms
  →CPU time 15msvselapsed time 1250ms：99% 时间在等待 I/O（磁盘或内存），不是计算慢，应优化索引或增加内存。

血泪经验：某次线上事故，elapsed time从 200ms 突增至 8s，logical reads从 200 跳到 15000。检查执行计划发现，前一天Customer表新增了CustomerType字段并建了索引，但SalesOrder的JOIN条件仍用旧字段c.ID，导致优化器放弃使用Customer主键索引，改用CustomerType索引 + 回表，I/O 暴增。修复只需在JOIN中明确指定c.CustomerID。

5. 备份与恢复：RPO＜5 分钟的实战策略与不可跳过的验证步骤

备份不是“定期点一下‘备份数据库’”，而是构建一套可验证、可审计、可快速恢复的 SLA 保障体系。真实业务要求：任意时刻数据丢失不超过 5 分钟（RPO），故障后 15 分钟内恢复服务（RTO）。本节给出基于 SQL Server 本地部署的最小可行方案，不含云服务或第三方工具。

5.1 三层次备份策略：完整 + 差异 + 日志，缺一不可

单一完整备份无法满足 RPO＜5 分钟。必须组合使用，形成时间点恢复能力。

-- 示例：创建每日完整备份作业（SQL Server Agent 任务） -- 步骤1：创建备份目录（确保 SQL Server 服务账户有写权限） EXEC xp_create_subdir 'D:\SQLBackup\FULL'; -- 步骤2：T-SQL 备份脚本（带时间戳，避免覆盖） DECLARE @BackupPath NVARCHAR(500); SET @BackupPath = 'D:\SQLBackup\FULL\SalesDB_Full_' + FORMAT(GETDATE(), 'yyyyMMdd_HHmmss') + '.bak'; BACKUP DATABASE [SalesDB] TO DISK = @BackupPath WITH COMPRESSION, -- 必开！减少 60% 存储，提升 20% 速度 CHECKSUM, -- 校验备份完整性，防止磁盘静默损坏 INIT, -- 覆盖同名文件（避免累积） STATS = 10; -- 每 10% 进度输出日志，便于监控 -- 示例：每 5 分钟日志备份（Agent 作业，频率设为 5 分钟） BACKUP LOG [SalesDB] TO DISK = 'D:\SQLBackup\LOG\SalesDB_Log_' + FORMAT(GETDATE(), 'yyyyMMdd_HHmmss') + '.trn' WITH COMPRESSION, CHECKSUM, INIT;

参数说明：

• COMPRESSION：SQL Server 2008+ 原生压缩，无需第三方工具，强烈建议开启；
• CHECKSUM：写入备份时计算校验和，恢复时自动验证，避免“备份文件损坏却不知情”；
• INIT：生产环境必须用INIT（覆盖）而非NOINIT（追加），否则一个.bak文件里混着多份备份，恢复时极易选错；
• STATS = 10：进度反馈，若卡在10 percent processed超过 5 分钟，说明 I/O 瓶颈，需检查磁盘队列长度。

5.2 恢复演练：每月一次，用RESTORE VERIFYONLY+STOPAT验证

备份文件存在 ≠ 可恢复。必须定期验证。真实案例：某公司备份脚本运行 3 年无报错，灾备演练时发现所有.bak文件末尾被截断 1KB，因磁盘配额超限，BACKUP命令静默失败。

-- 步骤1：验证备份文件完整性（不还原，秒级完成） RESTORE VERIFYONLY FROM DISK = 'D:\SQLBackup\FULL\SalesDB_Full_20240520_020000.bak'; -- 步骤2：时间点恢复演练（模拟误删数据后回滚到 5 分钟前） -- 假设 14:25 发生误操作，需恢复到 14:20 RESTORE DATABASE [SalesDB_RestoreTest] FROM DISK = 'D:\SQLBackup\FULL\SalesDB_Full_20240520_020000.bak' WITH MOVE 'SalesDB' TO 'D:\Data\SalesDB_RestoreTest.mdf', MOVE 'SalesDB_log' TO 'D:\Log\SalesDB_RestoreTest_log.ldf', REPLACE, NORECOVERY; -- 保持数据库在 RESTORING 状态，允许后续日志还原 -- 还原差异备份（如有） RESTORE DATABASE [SalesDB_RestoreTest] FROM DISK = 'D:\SQLBackup\DIFF\SalesDB_Diff_20240520_140000.bak' WITH NORECOVERY; -- 还原日志到指定时间点（STOPAT） RESTORE LOG [SalesDB_RestoreTest] FROM DISK = 'D:\SQLBackup\LOG\SalesDB_Log_20240520_142000.trn' WITH STOPAT = '2024-05-20 14:20:00', RECOVERY;

关键逻辑：

• NORECOVERY是链式还原的关键：每次还原后数据库处于RESTORING状态，允许继续还原下一个备份；
• STOPAT必须精确到秒，且必须在日志备份的时间范围内（如14:20:00的日志备份，只能恢复到14:20:00，不能到14:20:01）；
• RECOVERY只在最后一次还原时使用，表示结束还原，数据库上线。

5.3 自动化监控：用 SQL Agent 作业 + 邮件告警守住 RPO

人工检查备份日志不现实。必须自动化：检测最近一次日志备份是否在 5 分钟内，超时即发邮件告警。

-- 创建监控作业（每日运行，检查过去 10 分钟日志备份） DECLARE @LastLogBackup DATETIME; SELECT @LastLogBackup = MAX(backup_finish_date) FROM msdb.dbo.backupset WHERE database_name = 'SalesDB' AND type = 'L' -- L = Log backup AND backup_finish_date >= DATEADD(MINUTE, -10, GETDATE()); IF @LastLogBackup IS NULL OR @LastLogBackup < DATEADD(MINUTE, -5, GETDATE()) BEGIN -- 发送告警邮件（需提前配置 Database Mail） EXEC msdb.dbo.sp_send_dbmail @profile_name = 'DBA_Alert', @recipients = 'dba@company.com', @subject = 'ALERT: SalesDB Log Backup Overdue!', @body = 'No log backup found in last 5 minutes. Current RPO violated.'; END

注意：sp_send_dbmail需提前在 SQL Server 中配置 Database Mail（SSMS → 管理 → Database Mail → 配置向导），否则邮件发送失败且无提示。首次配置后，务必运行SELECT * FROM msdb.dbo.sysmail_event_log确认日志无error级别事件。

6. 生产环境黄金守则：五个必须写进部署文档的硬性配置

学完语法、会写查询、能做备份，不等于能管好生产库。真实世界里，5 个看似微小的配置，决定了系统是稳定如磐石，还是三天两头告警。这些不是“最佳实践”，而是某次凌晨三点救火后，写进团队 Wiki 的血泪条款。

6.1 最大内存：永远不要用默认值，必须锁定物理内存的 70%

SQL Server 默认不限制内存，会吃光服务器所有 RAM，导致 Windows 无内存可用，系统假死。某次事故：16GB 内存服务器，SQL Server 占用 14GB，Windows 无法响应远程桌面，只能硬重启。

-- 正确配置：为 16GB 服务器设置最大内存为 11GB（16 * 0.7 ≈ 11.2 → 向下取整） EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max server memory (MB)', 11264; -- 11GB = 11264 MB RECONFIGURE;

计算公式：

• 总内存 ≤ 16GB：max server memory = 总内存 - 2GB（留 2GB 给 OS）；
• 总内存 > 16GB：max server memory = 总内存 * 0.7；
• 若服务器还跑其他服务（如 IIS、Java 应用），再额外减去该服务所需内存。

6.2 自动增长：文件增长必须设固定大小，禁用百分比

默认10%增长是性能杀手。100GB 数据库增长 10% 就是 10GB，磁盘连续空间不足时，SQL Server 会卡住等待碎片整理，所有请求阻塞。

-- 修改数据文件增长方式（需在数据库空闲时执行） ALTER DATABASE [SalesDB] MODIFY FILE (NAME = N'SalesDB', FILEGROWTH = 512MB); -- 固定 512MB -- 修改日志文件增长方式（日志文件更敏感，建议 256MB） ALTER DATABASE [SalesDB] MODIFY FILE (NAME = N'SalesDB_log', FILEGROWTH = 256MB);

玄学经验：某次日志文件FILEGROWTH = 10%，数据库日志达 50GB，一次增长 5GB。由于磁盘碎片，增长耗时 47 秒，期间所有INSERT/UPDATE请求超时。改为256MB后，增长最快 0.8 秒。

6.3 统计信息：强制每周更新，禁用自动更新（AUTO_UPDATE_STATISTICS）

AUTO_UPDATE_STATISTICS在查询执行中触发更新，会锁表、拖慢查询。生产库必须用计划任务，在业务低峰期主动更新。

-- 创建每周日凌晨 2 点更新统计信息的 Agent 作业 EXEC sp_updatestats; -- 更新所有用户表的统计信息 -- 或更精准：只更新修改行数 > 10% 的表 EXEC sys.sp_autostats 'SalesOrder', 'ON'; -- 为单表开启自动统计（不推荐）

替代方案（推荐）：用 Ola Hallengren 的IndexOptimize脚本（免费开源），它智能判断哪些表需要更新统计，且支持在线更新（@UpdateStatistics = 'ALL'）。

6.4 错误日志：循环日志必须设为 30 个，禁用无限保留

默认只保留 6 个错误日志文件（ERRORLOG），老日

本文还有配套的精品资源，点击获取