SQL Server数据库设计实战：从表结构到索引与性能优化

1. 为什么数据库设计要先于建表：真实业务场景的倒逼

我早期接手过一个校园物流管理系统，C#为前端、SQL Server为后端。当时团队成员觉得表结构嘛，照着业务需求文档建就完了，快递单号、收件人、站点、入库时间、出库时间往表里一放，数据往里插就行。结果系统上线第三周就出了一连串问题——查询通知记录时同一个收货人关联出好几条重复数据，站点维度的月度统计拖到秒级超时，后来要增加一个"包裹滞留天数"报表，发现当初压根没有设计时间戳字段的默认行为和索引策略，改造一次动到几百行存储过程。

那段时间我最大的体会是：数据库设计踩的坑，几乎全都是在建表之前的决策阶段埋下的。这也正是我想围绕"SQL Server 数据库设计"这个主题，把整套从需求分析到物理落地的链路重新梳理一遍的原因。本文不会只讲三范式那几条干巴巴理论，而是把设计决策背后的业务逻辑、以及后期运行中才暴露出来的问题串在一起讲。适合正在做毕业设计、刚转行做后端开发、或者被公司存量系统烂表结构折磨过的同学参考。

设计工作本质上是一道翻译题：把业务语言翻译成结构化数据模型。翻译得好不好，不看建表的DDL写得漂不漂亮，而看后续的查询、更新、统计、迁移是否顺畅。我见过太多项目，ER图画得高大全，一上线就崩——崩不是在功能层面，而是在数据效率和数据质量层面。下面我按自己实际操盘项目的顺序，把每一个环节展开讲。

2. 从需求到模型：订单、物流与权限场景下的设计决策

2.1 抓住业务实体与关系，不要急着建表

做SQL Server数据库设计第一步，不是打开SSMS（SQL Server Management Studio）建库建表，而是先把业务里的实体找出来。什么叫实体？就是业务过程中需要被记录、被查询、被统计的"人和事物"。拿我那个校园物流系统举例，核心实体包括：学生/收件人、快递单、站点、入库记录、出库记录、管理员账号、角色。

有了实体之后，必须画清楚实体之间的关系：

• 一个收件人对应多张快递单（一对多）
• 一个快递单对应多次状态流转记录（一对多）
• 一个站点对应多个管理员（一对多）
• 管理员和角色之间是多对多

这些关系直接决定了外键如何设置。很多人喜欢在建表时一刀切，把所有可能用到的字段全部塞进一张大宽表里。短时间看确实省事，查询不用JOIN，一个SELECT全出来了。但等数据量上来之后，更新异常、删除异常、重复存储这些问题会接踵而至。我在那个物流项目里最开始也走过这条路——站点名称、站点负责人、站点电话、包裹量全都放在快递单表里。后来站点负责人换了，我得写一条UPDATE语句把所有属于该站点的快递单记录一起改，数据一多，要么漏改，要么并发改出脏数据。

正确做法是拆分：站点有自己的独立表，快递单通过SiteId外键关联。这样站点信息只存一份，改动只动一处。这就是所谓"第三范式"在真实场景中的体现——范式不是考试用的，是帮你规避数据冗余带来的更新异常。

2.2 流程类需求要设计流水表与日志表

像物流系统这种强流程业务，光有业务主表远远不够，还必须设计状态流水表。什么意思？快递单的状态从"已到达站点"到"已短信通知"到"已签收"，这中间每个节点的变化时间、操作人、变更原因，都是重要的业务数据。如果只在主表里放一个CurrentStatus字段，那么历史状态就丢失了，后续想统计"包裹平均在站点滞留多少天"、想排查"某包裹为什么状态跳变异常"，根本无据可查。

我当时的设计是：主表存当前状态，流水表存每一次状态变更。流水表大致包括：

• 包裹单号（和主表关联）
• 变更前状态
• 变更后状态
• 变更时间
• 操作人
• 备注

这套设计成本极低，一张表就搞定，但带来的价值非常大。后来学校要求统计各站点包裹滞留超48小时的数量，我直接对流水表做分析，一个JOIN加GROUP BY就出来了。没有流水表的话，这个需求基本只能靠人工翻记录。

2.3 权限设计：角色与用户分离

管理员和角色之间是多对多关系，所以必须有三张表：管理员表、角色表、管理员角色关联表。这是非常经典的设计，但实际执行中很多小项目会偷懒——直接在管理员表里加一个RoleName字段，用逗号分隔多个角色。这样做短期没问题，后期扩展权限点（比如某个角色能访问报表，某个角色能修改站点信息）的时候，就只能写一堆字符串匹配逻辑，SQL里满是CHARINDEX和LIKE，性能崩得快。

我在另一个项目里甚至遇到过更激进的做法：直接在代码里写死角色判断，if(user.Role == "admin")。这种设计看似省略了数据库层面的关联表，实际上是把系统的可维护性架在火堆上。数据库设计的职责边界就在这里——你需要在存储层面就把数据结构的合理性定下来，而不是指望应用层来弥补。

3. 表结构落地的关键选择：命名、类型、约束与关系

3.1 命名规范：宁可现在约束，不要以后骂街

命名规范是SQL Server数据库设计里最容易被忽略，但长期影响最大的部分。以我自己的习惯为例：

• 表名用复数或单数均可，但一定要统一。我统一用单数：Order、Package、Site、User
• 主键统一命名为Id，外键命名为"关联表名+Id"（比如SiteId）
• 时间字段统一用CreatedAt、UpdatedAt这种动词过去式加At
• 状态字段统一用Status，枚举值统一用0/1/2并在备注里写明含义
• 禁止使用中文拼音缩写、禁止大小写混用的无意义缩写

我接手过一个旧系统，里面有张表叫"Tbl_DD_Info"，DD是"快递单"的拼音缩写，还有字段叫"sjly"（时间来源的缩写），每个字段都是个谜。后来做数据迁移的时候，几乎每个字段都要去代码里翻对应关系，效率极低。命名规范这件事不涉及技术深度，但它决定了你的数据库是否可长期维护。规范的命名成本极低，混乱的命名代价极高，这个账怎么算都划算。

3.2 主键与外键：代理主键与业务主键的正确用法

在SQL Server里，主键设计有两个派别：

• 自然主键：直接使用业务唯一值，比如快递单号、身份证号
• 代理主键：使用自增Id或GUID，业务唯一值单独加唯一约束

我强烈建议绝大多数场景使用代理主键。为什么？因为业务唯一值经常会发生你意想不到的变化。快递单号在快递公司之间可能重号，身份证号涉及隐私不该直接作为关联键到处使用。而自增Id是一个无业务含义的整数，稳定、短、索引效率高，最适合作为关联查询的桥梁。

代理主键的具体选型上，我一般这样判断：

物流项目里我用的是BIGINT自增——校园场景数据量没那么夸张，但考虑到流水表日积月累，BIGINT更稳妥。关联表的主键我通常不单独建自增Id，直接用两个外键联合作为主键，再在两个外键上分别建索引。

外键约束很多团队会弃用，理由是影响插入性能、维护麻烦。我的观点是：OLTP系统必须保留外键约束。SQL Server的外键约束能在数据库层面防止脏数据，比如你把一个快递单指向一个不存在的站点，有外键直接报错拦下，没有外键就让脏数据静默落库，业务逻辑晚几天才炸，排查难度翻倍。性能影响是存在的，但可以通过合理索引抵消大部分。再说，谁愿意天天靠人肉检查数据完整性？

3.3 字段类型选型：把每一分存储都花在刀刃上

字段类型选型看起来基础，但我见过大量匪夷所思的用法。最常见的是：

• 用NVARCHAR(MAX)存所有字符串，包括只存10个字符的站点名称
• 用VARCHAR存日期（"2025-01-01"），导致日期函数全得CAST
• 用FLOAT存金额，出现0.1+0.2不等于0.3的问题
• 用NTEXT存放JSON格式的配置文本

这些用法在数据量小的Demo项目里确实跑得通，一旦数据量上去，占用的存储、索引效率、查询复杂度全都是问题。我在SQL Server中一般这样选：

• 短字符串用VARCHAR(50)，中等用VARCHAR(200)，长文本才用NVARCHAR(MAX)或VARCHAR(MAX)
• 日期时间用DATETIME2，精度高且范围大；只需要日期的用DATE
• 金额用DECIMAL(18,2)，不要用FLOAT和REAL
• 状态标志用TINYINT，配合CHECK约束限定取值范围
• 描述性文本用NVARCHAR是因为要兼容中文等多语言环境，纯ASCII场景才用VARCHAR

有一个非常容易踩的细节：DATETIME和DATETIME2的区别。DATETIME的精度是3.33毫秒，而且范围为1753-9999年；DATETIME2的精度可以到100纳秒，范围为0001-9999年。SQL Server 2016以后我全部用DATETIME2(3)替代DATETIME，避免历史日期溢出问题。

3.4 订单表DDL实例：完整落地一个物流订单表

纸上谈兵这么多，直接上一个简化版的物流快递单表DDL，把我们前面说的设计原则全部落进去：

CREATE TABLE dbo.Package ( Id BIGINT IDENTITY(1,1) CONSTRAINT PK_Package PRIMARY KEY, TrackingNumber VARCHAR(50) NOT NULL, RecipientName NVARCHAR(50) NOT NULL, RecipientPhone VARCHAR(20) NOT NULL, SiteId INT NOT NULL, CurrentStatus TINYINT NOT NULL CONSTRAINT CK_Package_CurrentStatus CHECK (CurrentStatus IN (0,1,2,3,4)), CreatedAt DATETIME2(3) NOT NULL CONSTRAINT DF_Package_CreatedAt DEFAULT SYSUTCDATETIME(), UpdatedAt DATETIME2(3) NOT NULL CONSTRAINT DF_Package_UpdatedAt DEFAULT SYSUTCDATETIME(), CONSTRAINT FK_Package_Site FOREIGN KEY (SiteId) REFERENCES dbo.Site(Id) ); CREATE INDEX IX_Package_SiteId ON dbo.Package(SiteId); CREATE INDEX IX_Package_TrackingNumber ON dbo.Package(TrackingNumber); CREATE INDEX IX_Package_CurrentStatus ON dbo.Package(CurrentStatus);

几个细节我展开说一下：

• TrackingNumber虽然业务上唯一，但我没有把它设为主键，而是建了普通索引。原因前面说了，快递公司之间的单号规则不统一，甚至可能重复，作为业务查询条件建索引即可，不承担主键职责。如果确认业务上绝对唯一，可以再加UNIQUE约束。
• CurrentStatus用了TINYINT配合CHECK约束，而不是字符串。原因很简单：字符串状态在查询和存储上效率低于数字，而且容易因拼写不一致产生脏数据。数字枚举配合CHECK约束，数据库层面就掐掉了非法值。
• CreatedAt和UpdatedAt都用SYSUTCDATETIME()做默认值，确保所有时间存UTC。这样后期做跨时区分析、日志排序都是统一的基准。
• 关于UpdatedAt自动更新，SQL Server没有MySQL那种ON UPDATE CURRENT_TIMESTAMP语法，我在项目里用触发器或让应用层显式更新。小系统用应用层更新更可控，触发器反而容易被遗忘。

4. 索引设计：从"查询快"到"写入不崩"的博弈

4.1 索引不是越多越好，而是越"对症"越好

索引设计是SQL Server数据库设计中最像"走钢丝"的部分。很多新手会把索引理解为"查得慢就加索引"，结果一张表上建了十几个索引，写入性能从毫秒级掉到几百毫秒，索引维护成本甚至超过了查询收益。

我的索引设计流程是这样的：

第一步，找出所有高频查询的WHERE条件字段和JOIN字段，记录它们的组合关系； 第二步，分析每个查询的返回列，评估是否需要覆盖索引（把SELECT的列都include进去）； 第三步，对复合索引，把区分度高的字段放前面； 第四步，删除重复索引和长期未使用的索引。

物流项目里一个典型场景：查询某站点的当日包裹列表。WHERE条件是SiteId和CreatedAt范围，那就可以建复合索引（SiteId, CreatedAt），比分别建SiteId索引和CreatedAt索引更高效。因为SQL Server可以用复合索引同时过滤两个条件，而两个单列索引只能选一个做 Seek，另一个做 Lookup。

复合索引的字段顺序是个高频考点。经验法则：等值条件放前面，范围条件放后面。因为索引的有序性，等值条件可以直接定位，范围条件只能部分利用索引顺序。反过来放会导致范围条件后面的字段无法走索引。

4.2 覆盖索引与Include列的实战价值

物流系统的快递单表有个经典痛点：列表页要显示单号、收件人、站点名称、状态、入库时间。如果索引只覆盖查询条件的列，那么每次查询都要根据主键回表拿数据行，再取其他字段。

解决办法有两个：一是把所有要显示的字段全建到索引键列里（但这也太多）；二是建一个复合索引，把需要显示的字段放到INCLUDE里：

CREATE INDEX IX_Package_Site_CreatedAt_Include ON dbo.Package(SiteId, CreatedAt) INCLUDE (TrackingNumber, RecipientName, CurrentStatus);

这种索引叫覆盖索引——查询需要的所有列都在索引页里，SQL Server不需要回表。列表页的查询性能会明显提升。但INCLUDE字段会占索引存储空间，所以只include高频展示且短小的字段，别把大段文本也塞进去。

4.3 写入放大问题：索引数量与写入性能的平衡

每建一个索引，意味着每次INSERT、UPDATE、DELETE都要额外维护这个索引的B+树结构。表上的索引越多，写入放大越严重。物流系统的入库操作是极高频率的——每个包裹到达站点就要插入一条记录，如果表上建了七八个索引，插入速度会肉眼可见地变慢。

我在项目里的取舍标准是：核心查询路径不超过3个复合索引，配合主键自带的聚集索引。其余低频查询如果确实慢，可以接受走扫描或额外设计报表表汇总。用空间换时间可以用，但空间和无用索引是两个概念。

有一类索引我建议坚决不要：把表里每个字段各建一个单列索引。这种"广撒网"策略看似每条查询都能碰到索引，实际效果极差，不仅浪费存储，还会让查询优化器犯选择困难症——走错执行计划比没索引更可怕。

5. 事务与并发控制：从数据安全到业务一致性的防线

5.1 事务的必要性：一个场景说明一切

物流系统里有一个典型操作：包裹入站登记。一步是往Package表插入一条新记录，另一步是更新站点表的收件数统计字段。如果插入成功但汇总更新失败，那么这个站点的统计数据和实际包裹量就对不上了。

这种场景就必须用事务裹起来：

BEGIN TRANSACTION; BEGIN TRY INSERT INTO dbo.Package (...) VALUES (...); UPDATE dbo.Site SET PackageCount = PackageCount + 1 WHERE Id = @SiteId; COMMIT TRANSACTION; END TRY BEGIN CATCH ROLLBACK TRANSACTION; THROW; END CATCH;

事务保证了这两步操作的原子性：要么全部成功，要么全部回滚。没有事务，数据一致性就只能靠事后对账补救，那是成本最高也最不可靠的方案。

5.2 隔离级别选择：读已提交与可重复读的权衡

SQL Server默认隔离级别是READ COMMITTED。大多数OLTP场景下这个级别是够用的。但有些业务对一致性的要求更高，典型场景是统计类操作——系统要统计每个站点的包裹分布，如果统计过程中有包裹状态从"在库"变成"已签收"，统计结果就出现快照不一致。

SQL Server里解决这个问题有两类思路：

• 提高隔离级别到REPEATABLE READ或SNAPSHOT
• 在应用层对关键统计加锁

SNAPSHOT隔离级别利用了行版本控制，读操作不阻止写操作，写操作不阻止读操作，而且每次读到的都是一致快照。在用SQL Server 2019做统计报表时，我会特意把报表会话设置成SNAPSHOT：

ALTER DATABASE YourDB SET ALLOW_SNAPSHOT_ISOLATION ON;

这样报表查询不会长时间阻塞正常业务写入，是并发和一致性之间一个很好的折中。

5.3 死锁：谁导致、如何最小化

并发系统里死锁不可避免，但可以降低发生概率。死锁的本质是多个会话互相持有对方需要的锁，互相等待形成环。SQL Server会选择代价最小的会话作为死锁牺牲品，回滚它的整个事务。

我处理过的最典型的死锁场景是：后台任务和前台接口同时对站点表做更新，但更新顺序不一致。比如任务先更新A再更新B，接口先更新B再更新A，两个会话恰好交错执行时就死锁了。

降低死锁的手段：

• 多个事务访问多个表时，固定访问顺序
• 缩短事务时间，不要在事务里做耗时操作（比如远程接口调用）
• 合理使用索引，减少锁的范围（行锁而非表锁）
• 使用READ COMMITTED SNAPSHOT隔离级别，让读不加共享锁，降低死锁概率

6. 视图、存储过程与函数：设计后端的三个层次

6.1 视图：封装复杂查询，但不建议当成万能工具

视图在SQL Server里扮演的角色是"预定义查询"。把复杂JOIN、行列转换、聚合统计封装成视图后，应用层可以像查表一样查视图，简洁很多。物流系统里我建过一个站点周报视图，把包裹表、站点表、流水表JOIN在一起，再按站点和日期聚合。后来报表工具直接SELECT这个视图即可，逻辑清晰，也不用每个报表重复写一大段SQL。

但视图有个容易误用的点：很多人以为视图是"数据快照"，查它会快。实际上视图本质是SQL语句的封装，每次查询都要重新执行内部语句，视图本身没有物化数据（除非建索引视图）。所以视图适合的是逻辑复用和代码整洁，性能上该加索引还得在底层表上加。

索引视图是例外。SQL Server允许在视图上创建唯一聚集索引，把视图结果物理化。建索引视图能带来显著性能提升，但代价是视图依赖的基表更新时，索引视图也要同步维护，所以它更适合数据变化频率低但查询频率极高的场景。

6.2 存储过程：控制访问入口与减少网络往返

存储过程在SQL Server数据库设计中拥有不可替代的位置。虽然ORM框架这些年很流行，很多团队完全不写存储过程，但我始终建议对复杂业务逻辑或高频操作使用存储过程。

理由很直接：

• 存储过程在数据库端编译执行，减少SQL文本在网络上的传输和重复解析开销
• 多个操作可以封装成一个过程，减少应用与数据库之间的往返次数
• 可以做权限隔离，应用账号只授予过程的EXECUTE权限，不直接暴露表结构
• 出问题修改时，数据库端调整不影响应用发布

以物流系统的"包裹批量入库"为例，应用端传一个表值参数给存储过程，过程里循环处理、统一事务管理：

CREATE TYPE dbo.PackageImportType AS TABLE ( TrackingNumber VARCHAR(50), RecipientName NVARCHAR(50), RecipientPhone VARCHAR(20), SiteId INT ); CREATE PROCEDURE dbo.usp_Package_BatchImport @Packages dbo.PackageImportType READONLY AS BEGIN SET NOCOUNT ON; BEGIN TRANSACTION; BEGIN TRY INSERT INTO dbo.Package (TrackingNumber, RecipientName, RecipientPhone, SiteId, CurrentStatus) SELECT TrackingNumber, RecipientName, RecipientPhone, SiteId, 0 FROM @Packages; COMMIT TRANSACTION; END TRY BEGIN CATCH ROLLBACK TRANSACTION; THROW; END CATCH; END;

服务端一次调用即可完成批量入库，不需要应用层逐条INSERT，事务也控制在数据库端完成，代码既简单又安全。

6.3 函数：什么时候用，什么时候别用

SQL Server里的函数分标量函数和表值函数。标量函数最容易被滥用——比如在WHERE条件里调用自定义标量函数来过滤行，这会导致索引完全失效，因为SQL Server必须为每一行计算一次函数值。我在排查慢查询时遇到过不止一次：某个查询原来走索引只要几十毫秒，加了一个WHERE dbo.fnGetSiteName(SiteId) = '某某站'之后，直接跑不动了。

所以我的铁律：WHERE条件、JOIN条件、索引键列里不用标量函数。如果不得不做转换，尽量用内联表达式代替函数，或者把转换结果存为冗余字段并建索引。

表值函数则不同，尤其是内联表值函数，它本质上是一个参数化的视图，查询优化器可以把它提升到外层查询中做优化，性能和视图接近，是可以放心用的。

7. 迁移、备份与大数据量的实战准备

7.1 数据库文件与文件组规划

很多人在SQL Server数据库设计阶段不会主动考虑文件组规划，默认PRIMARY文件组扛一切。这个决定在项目早期看不出问题，数据量到达一定程度后，备份恢复和IO分布都会成为瓶颈。

我习惯于在初始化数据库时就做两件事：

• 为独立的大表创建单独的文件组和文件，分散IO
• 把历史数据表和当前热数据表放在不同文件组，方便后续做分区或备份策略

比如物流系统的PACKAGE流水表逐年膨胀，我把它单独放在一个文件组里，定期把超过两年的数据归档到另一个只读文件组。归档后查询热数据不受历史数据拖累，备份策略也可以分文件组进行。

7.2 备份策略：完整备份、差异备份与事务日志备份的组合

SQL Server数据库设计不只是设计表，还包含可用性设计。备份策略是最典型的可用性设计。我之前接过一个项目，数据库每天做一次完整备份，没有差异备份和日志备份。某天早上数据库磁盘故障，恢复时只能还原昨天的全备，当天生产数据丢了整整一天。

现在我在事务系统上的标配策略是：

• 每周日凌晨做完整备份
• 其余每天做一次差异备份
• 每15分钟到30分钟做一次事务日志备份
• 保留最近14天的备份文件，跨月备份归档

这个策略下，一旦出故障，最多丢失15分钟到30分钟的数据。备份恢复的RPO（恢复点目标）和RTO（恢复时间目标）都是设计阶段就要明确的指标，而不是出故障之后才拍脑袋。

别忘了做恢复演练。备份文件无法还原的情况我遇到过不止一次——磁盘空间不足、版本不匹配、备份文件损坏。定期在测试环境还原一次备份，比什么文档都管用。

7.3 大表的归档策略：数据分区与滑动窗口

物流系统的流水表天生会无限增长。在SQL Server里处理大表，我会优先考虑表分区——按时间字段做分区，每个分区存储一个时间段的数据。做统计任务时，查询优化器天然只扫描目标分区，删除旧数据也变成"切换分区"的元数据操作，不再需要跑DELETE大事务。

分区功能只在SQL Server 2016 SP1及以上的所有版本可用，2019、2022都原生支持。设计阶段我基本按这个思路：以月份为分区边界，提前建好未来一个季度的空分区，每月自动归档历史数据到文件组，保持表结构长期稳定。

8. 从设计到运维：SSMS之外必须掌握的性能体检手段

8.1 执行计划：看三个关键节点就够了

很多初学者打开SSMS的执行计划窗口，看到一堆图标就头皮发麻。我教新人的方法是只看三个关键节点：

• 表扫描（Table Scan）：说明没走索引，数据量一大必慢
• 聚集索引扫描（Clustered Index Scan）：说明查询没有用主键定位，扫全表
• 键查找（Key Lookup）：说明索引没覆盖全部需要的列，每行都要回表

只要执行计划里出现这三个节点重灾区，优先处理它们，其余细节基本不用管。RID Lookup是堆表上的回表，和Table Scan一样需要留意。

我处理过一个典型慢查询：快递单按收件人手机号查询，手机号字段没有索引，SQL Server只能全表扫描，400万行数据跑了12秒。建一个手机号索引后，同样查询降到50毫秒级别。执行计划从Table Scan变成Index Seek，这个变化看一眼就懂。

8.2 动态管理视图：快速定位阻塞与资源消耗

除了SSMS的可视化工具，SQL Server的动态管理视图(DMV)是我日常运维离不开的利器。几个最常用的：

查询当前阻塞链：

SELECT blocking.session_id AS 阻塞会话, blocked.session_id AS 被阻塞会话, blocked.wait_type, blocked.blocking_session_id, blocked.wait_time FROM sys.dm_exec_requests AS blocked LEFT JOIN sys.dm_exec_requests AS blocking ON blocking.session_id = blocked.blocking_session_id WHERE blocked.blocking_session_id > 0;

查询缓存中最耗CPU的批处理：

SELECT TOP 10 qs.total_worker_time AS CPU总耗时, qs.execution_count AS 执行次数, qs.total_worker_time / qs.execution_count AS 平均CPU耗时, SUBSTRING(st.text, (qs.statement_start_offset/2)+1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) AS 语句文本 FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st ORDER BY qs.total_worker_time DESC;

这些DMV的价值在于，你能直接从运行中的系统里捞数据，而不是靠"感觉哪个SQL慢"来猜。排查性能问题最怕的就是凭直觉，索引加了一堆，结果慢的查询根本没动。

8.3 查询提示：慎用，但需要知道存在

SQL Server的查询优化器在绝大多数情况下比人聪明，但偶尔会选错执行计划。查询提示（比如OPTION(RECOMPILE)或OPTION(HASH JOIN)）可以在特定场景下手动修正，但这是最后手段。在SQL Server 2019以后，有个更好的方向：查询存储（Query Store），它会把每个查询的执行计划演变历史记录到数据库，你可以看到某个查询在某个时间点之后计划突变、性能下降，然后强制它走之前的良好计划。

我给的建议是：先开查询存储，再考虑查询提示。查询存储做到了"用数据说话"——你不需要在网上猜为什么优化器抽风，直接看计划演变历史就行。

9. 一套可复用的SQL Server设计自检清单

最后放一套我每次完成数据库设计后都会跑一遍的自检项，照着做至少能避开80%的常见坑：

这套清单不是凭空想出来的，而是我在多个项目里一条条踩出来的。有一次上线前检查，发现一张核心表没有主键，当时数据已经有十几万行了，幸好还没对外发布，否则后面所有关联查询都会带着风险运行。又有一次是金额字段用了FLOAT，统计报表里对不上账，最后全线替换成DECIMAL才解决。

SQL Server数据库设计这件事情，说到底是"结构对了，系统就稳了一半"。表结构一旦上线，修改的代价会越来越大——索引可以重建，字段可以加列，但一张设计混乱的表想要彻底重构，差不多等于重写整个系统。所以在设计阶段多花一点时间，多问几个"以后会不会"的问题，比上线后熬夜救火要划算得多。