SQL Server索引碎片诊断与REORGANIZE/REBUILD维护策略

1. 先搞清楚“碎片”到底碎的是什么很多人第一次接触这个概念是从一句“索引碎片高了要重建”开始的然后就在维护计划里勾一个“重新组织索引”任务跑完看到日志里写着“成功”就以为万事大吉。我在早期也这么干过直到某次一个报表查询突然从 2 秒变成 40 秒查了执行计划、看了统计信息都没问题最后才发现那个索引的逻辑碎片已经接近 90%——整理任务确实每天都跑但它跑的是“组织”不是“重建”对一个页密度已经烂掉的索引来说等于拿扫帚扫一堆已经压实的垃圾扫不动。所以第一篇我想先把概念捋清楚碎片的本质不是“数据乱了”而是页面利用率下降和页序与键序不一致这两件事的叠加。SQL Server 存储数据的最小单位是 8KB 的页索引的叶子层由一连串页组成每一页里装着若干行。当你在索引中间位置插入一行如果那一页已经满了SQL Server 就要做页拆分把原来一页的数据对半分到两页里然后新行插进去。一页变两页每页只用了一半这就是内部碎片页密度低。如果这个过程发生在聚簇索引上那么所有非聚簇索引里指向这一行的指针或者键值也得跟着变而更麻烦的是如果拆分出来的新页在物理磁盘上被分配到了别处页与页之间的顺序就和索引键的逻辑顺序脱节了这是外部碎片页乱序它直接导致范围扫描时预读失效本来连续读 100 个页现在要跳着读 100 个位置。用一个生活化的比喻内部碎片像是你有一排书架每本书只占半格剩下的半格空着不让别人用外部碎片像是这些书架格子被管理员随机挪到了楼层的不同角落你要找齐一套书得满楼跑。前者浪费空间、降低单页能装的行数导致同样的行数要多读几页后者让顺序读变成随机读机械盘上这个差别尤其致命SSD 上影响会小一些但也不是没有因为预读和内存里的页缓存依然依赖连续性。理解这两类碎片的区别直接决定了后面所有操作的选择逻辑。sys.dm_db_index_physical_stats这个 DMV 返回的两个关键指标正好对应它们avg_fragmentation_in_percent是外部碎片页乱序百分比avg_page_space_used_in_percent是内部碎片的反面页平均填充率。很多教程只说“碎片超过 30% 就重建”但没说清这个 30% 指的是哪个值。实际上大多数语境下说的是avg_fragmentation_in_percent因为它是 SQL Server 自己给出的一个综合判断依据而填充率低往往是页拆分的副产品会随着重建一起被修好。还有个常被忽略的点堆表没有聚簇索引的表也有碎片。堆的碎片表现形式是“页不连续 转发记录forwarding record”。如果你对一张堆表做过更新尤其是把变长列改大行在原页放不下了SQL Server 会在原位置留一个转发指针真实数据挪到新页。转发链一长扫描性能会断崖式下跌。这个问题重建索引解决不了因为堆没有索引可重建只能建一个聚簇索引再删掉也就是常说的“重建堆”。我在一次对账系统优化里就遇到过一张 800 万行的流水表因为长期只插不改一直没人管后来业务加了个补录功能更新状态字段三个月后全表扫描慢了五倍查sys.dm_db_index_physical_stats看到forwarded_record_count是六位数那一刻才意识到堆表不是“不需要维护”是“维护方式不一样”。下面这张表是我平时用来快速判断该做什么动作的对照可以直接抄走观察到的现象大概率原因优先动作avg_fragmentation_in_percent 5查询正常无需处理什么都不做5 ~ 30 之间扫描量上升轻度外部碎片REORGANIZE 30范围扫描明显变慢重度外部碎片REBUILD评估窗口avg_page_space_used_in_percent长期低于 60频繁中间插入调填充因子或改键设计堆表forwarded_record_count很大变长列更新建聚簇索引或重建堆碎片不高但查询仍慢统计信息、参数嗅探、缺索引别瞎整理先看执行计划最后一行是我特别想强调的碎片只是性能问题的候选原因之一不是默认答案。我见过太多“查询慢就重建索引”的操作重建完没变化浪费了维护窗口还锁了一堆资源。判断顺序应该是先看等待类型、看执行计划、看统计信息更新时间和行数估算偏差最后才轮到碎片。碎片高是“可能有问题”碎片高且恰好是范围扫描慢才是“大概率是它”。2. 两个命令的边界REORGANIZE 和 REBUILD 不是强弱关系网上流传一个说法“碎片小于 30% 用组织大于 30% 用重建”。这个规则本身不算错但把它当成铁律就会踩坑因为它掩盖了这两个操作的本质差异——它们不是同一个动作的不同强度而是两种完全不同的算法适用场景并不只是碎片百分比。ALTER INDEX ... REORGANIZE是在线的、单线程的、页级别的操作。它从叶子层开始把页里的行按照键顺序重新排列把后面页的行往前挪填空隙填满一页再处理下一批同时在过程中交换页在文件里的物理位置修复页乱序。它的关键特性是不持长期锁只在很短的时间片内持锁可以中断中断后已完成的部分会保留有并发上限受MAXDOP影响但在旧版本里实际上是单线程的日志量小。代价是慢而且对一个已经严重乱序的大索引它可能需要跑几个小时甚至更久因为它是一页一页挪的。ALTER INDEX ... REBUILD是重新构建扔掉原来的索引结构按键顺序重新写一份新的。它的关键特性是速度快得多相当于一次顺序写 排序结果是完全紧凑的默认离线Standard 版下会锁表Enterprise 版可以WITH (ONLINE ON)日志量大完整记录所有页的写入除非是分区表的某些场景或用了大容量日志恢复模式会重置统计信息这是很多人没注意到的隐藏收益。为什么 REBUILD 能顺带修好内部碎片因为它写新页的时候会按照索引定义的填充因子FILLFACTOR来控制每页留多少空位。默认填充因子是 0 或 100意思是叶子页写满、只在非叶子层留空。也就是说如果你不指定填充因子重建出来的索引依然会在下次中间插入时立刻开始分裂。这是我踩过的第一个大坑。那次是给一个订单表做优化重建完所有索引碎片清零第二天早上一看又回到 40%。我一开始以为是重建没生效后来才想明白这张表的主键是自增 ID但业务查询大量基于“订单号 状态”做范围扫描而订单号是随机生成的字符串插入位置完全随机所以每次插入都落在索引中间填充因子 100 意味着每页都是满的一插就裂。这不是重建的错是我的填充因子没配对。填充因子的估算逻辑其实很简单但需要你了解这张表的写入模式。假设一张表 10000 行每行 200 字节一页可用约 8060 字节那每页能放约 40 行总共 250 页。如果填充因子设为 80%每页只放 32 行需要 313 页多占 25% 的空间。这 25% 的空间换来的是在两次维护之间的这段时间里中间插入不需要立刻触发页拆分——每页有 8 行的缓冲空间。那这 8 行什么时候用完取决于这个索引键上“落在中间位置”的插入频率。如果每天中间插入 2000 行平均到 313 页上每页每天分到 6 行多一点那么大约一天半之后开始分裂。所以维护频率应该和这个消耗速度对齐。我一般给的建议是这样顺序插入自增 ID、时间戳单调递增的索引填充因子保持 100 没问题因为插入永远在最后一页不会分裂随机插入或范围插入频繁的索引80~90 之间比较稳具体看每天中间插入的量如果用 GUID 做主键那问题就更严重因为 GUID 的随机分布会让所有插入都落在中间我强烈建议改用NEWSEQUENTIALID()或者干脆用自增 业务唯一键的组合从根上避免这个场景。还有几个 REBUILD 的细节容易被忽略SORT_IN_TEMPDB ON重建需要按键排序如果排序在 tempdb 里做可以减轻用户库的 IO 压力代价是 tempdb 的 IO 上去了。如果 tempdb 和用户库在不同的盘或者至少不同的磁盘队列开这个通常能缩短总时间。ONLINE ON不是没有代价它确实不阻塞读写但会在重建期间产生更大量的日志并且需要额外的空间来存放新旧两份结构同时会短暂地在开始和结束时各拿一次锁。如果空间紧张或者维护窗口足够离线重建反而更省资源。大表分批次对超大表比如上亿行一次性重建可能撑爆日志或者跑不完窗口可以用WITH (MAXDOP n)控制并行度或者按分区逐个重建只支持分区表。重建会重置统计信息但不会重置增量统计如果之前开了NORECOMPUTE或者有增量统计要重新评估。REORGANIZE 的适用场景我总结成一句话当你在线、不能锁表、碎片又不算太离谱的时候用它。它的另一个好处是对LOB数据类型text、nvarchar(max)、varbinary(max)支持更好——在较老的版本里REBUILD 遇到包含 LOB 列的索引会失败而 REORGANIZE 可以处理。这个限制在较新版本里已经放开但如果你维护的是老版本实例这条得记住。3. 用 DMV 摸清家底别凭感觉动手真要动手之前我习惯先跑一遍体检把“哪些索引碎片高、多大、多少页、上次什么时候动过”全列出来而不是一上来就对整库重建。这一步的意义在于优先级排序一个碎片 70% 但只有 20 页的小索引重建它带来的收益还不如重建一个碎片 35% 但有几百万页的大索引。核心 DMV 是sys.dm_db_index_physical_stats它的第三个参数是模式LIMITED、SAMPLED、DETAILED三档差别巨大LIMITED只扫非叶子层和堆的 IAM 页速度极快适合整库快速筛查但它返回的avg_fragmentation_in_percent对堆来说不准堆在这个模式下不计算碎片。SAMPLED如果表小于 10000 页行为等同于 DETAILED大于 10000 页则采样 1% 的页速度快但有误差。DETAILED全扫最准但也最慢最耗 IO对大库要慎用。我一般的做法是日常巡检用LIMITED加过滤条件只查page_count 1000的月度深度体检用SAMPLED只有确认某个索引要处理时才针对那一个索引用DETAILED复核。下面这段查询我用了很多年改改就能用SELECT DB_NAME() AS db_name, OBJECT_SCHEMA_NAME(i.object_id) AS schema_name, OBJECT_NAME(i.object_id) AS table_name, i.name AS index_name, i.type_desc, s.partition_number, s.page_count, s.avg_fragmentation_in_percent AS ext_frag_pct, s.avg_page_space_used_in_percent AS page_full_pct, s.forwarded_record_count, s.record_count, ps.last_user_update, ps.last_user_seek, ps.last_user_scan FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, SAMPLED) AS s JOIN sys.indexes AS i ON i.object_id s.object_id AND i.index_id s.index_id LEFT JOIN sys.dm_db_index_usage_stats AS ps ON ps.database_id s.database_id AND ps.object_id s.object_id AND ps.index_id s.index_id WHERE s.page_count 1000 AND i.type_desc IN (CLUSTERED, NONCLUSTERED) AND s.index_id 0 ORDER BY s.page_count * s.avg_fragmentation_in_percent DESC;这里有几个设计意图值得说明。page_count 1000约 8MB这个门槛不是随便定的。小于这个量的索引即使碎片 100%扫描它也就多读几十个页IO 收益微乎其微而重建的开销和锁的时间却是实打实的。我见过有人清一色把所有索引都重建结果一个 5 万张表的小库跑了 40 分钟全是小索引在拖时间。ORDER BY s.page_count * s.avg_fragmentation_in_percent是个粗糙但好用的“收益打分”。它不精确但能有效把“又大又碎”的顶到前面。真正严密的成本模型要考虑顺序读和随机读的代价比、缓冲区命中率、查询模式那属于另一个话题了。sys.dm_db_index_usage_stats的关联是我认为最有价值的一步——它告诉你这个索引到底有没有人用。如果last_user_seek、last_user_scan、last_user_lookup全是 NULL说明从实例启动到现在这个索引一次都没被查询用过注意这个视图的数据在实例重启后会清空所以对刚重启不久的实例不可信。一个从没用过的索引碎片再高也不需要管甚至应该考虑删掉它——它只在写的时候产生维护开销。这个 DMV 还有个陷阱它不统计仅由外键约束或统计信息引发的使用也就是说last_user_*全 NULL 不代表绝对安全尤其是你可能用它来支撑唯一性约束。我的判断标准是全 NULL 且不是唯一索引先观察一个完整业务周期再决定。另外提一下sys.dm_db_index_operational_stats这个视图能给出每个索引的锁等待、闩锁等待、页争用情况。重建索引时如果发现某个索引的闩锁等待特别高说明它是热点那维护窗口的安排就要更谨慎可能要避开业务高峰或者干脆考虑用在线重建。体检完之后我会做一件事按收益排序列出本次要处理的对象估算总时长。估算方法是看page_count粗略按每秒能处理 500~2000 页来估机械盘取低值SSD 取高值有SORT_IN_TEMPDB可以再快一些。比如一个 200 万页的索引按 1000 页/秒算就是 2000 秒33 分钟。这个估算当然不精确但能防止出现“以为十分钟搞定结果跑了三小时锁到天亮”的事故。4. 维护脚本的写法比脚本本身更重要很多人用现成的脚本网上一搜一大把复制过来改个阈值就跑。问题在于这些脚本的阈值通常是拍脑袋定的“大于 30 重建5 到 30 组织”而这些阈值对不同的表、不同的写入模式、不同的硬件有效性完全不同。我现在的写法是按“收益”驱动而不是按“固定阈值”驱动逻辑大概是先筛出有使用记录、页数够大、碎片超过某个下限的索引然后根据碎片程度和页数决定重建还是组织并且生成的是“待执行清单”而不是直接执行。人工看一眼清单再决定比让脚本无脑跑安全得多。生成清单的脚本核心是这段SELECT QUOTENAME(OBJECT_SCHEMA_NAME(i.object_id)) . QUOTENAME(OBJECT_NAME(i.object_id)) AS qualified_table, QUOTENAME(i.name) AS index_name, s.page_count, CAST(s.avg_fragmentation_in_percent AS DECIMAL(5,2)) AS ext_frag_pct, CASE WHEN s.avg_fragmentation_in_percent 30 AND s.page_count 5000 THEN REBUILD WHEN s.avg_fragmentation_in_percent BETWEEN 5 AND 30 AND s.page_count 1000 THEN REORGANIZE ELSE SKIP END AS suggested_action, ALTER INDEX QUOTENAME(i.name) ON QUOTENAME(OBJECT_SCHEMA_NAME(i.object_id)) . QUOTENAME(OBJECT_NAME(i.object_id)) CASE WHEN s.avg_fragmentation_in_percent 30 AND s.page_count 5000 THEN REBUILD WITH (SORT_IN_TEMPDB ON, ONLINE ON) WHEN s.avg_fragmentation_in_percent BETWEEN 5 AND 30 AND s.page_count 1000 THEN REORGANIZE END ; AS ddl FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, SAMPLED) AS s JOIN sys.indexes AS i ON i.object_id s.object_id AND i.index_id s.index_id JOIN sys.dm_db_index_usage_stats AS u ON u.database_id s.database_id AND u.object_id s.object_id AND u.index_id s.index_id WHERE s.index_id 0 AND s.page_count 1000 AND (u.last_user_seek IS NOT NULL OR u.last_user_scan IS NOT NULL OR u.last_user_lookup IS NOT NULL) AND i.is_disabled 0 ORDER BY s.page_count DESC;几个关键点。i.is_disabled 0一定要加。如果索引被禁用过ALTER INDEX ... DISABLE物理统计里可能还留着数据对它发重建命令会失败。这个坑我踩过一次脚本跑到一半报错还得回头一个个排查。用了JOIN而不是LEFT JOIN关联使用统计是有意为之我只要那些“确认被用过”的索引。代价是可能漏掉一些外键索引但换来的是绝不碰死索引。这里取决于你的取舍如果担心漏可以改成LEFT JOIN并在WHERE里加上OR u.index_id IS NULL但那样就得人工判断了。生成的 DDL 里带ONLINE ON是因为我接手的库多数是业务连续性的不能接受锁表。但你要注意ONLINE ON有几个硬限制——不能用于XML索引、不能用于空间索引、不能用于列存索引部分版本而且重建期间会占用更多空间。如果你的索引带 LOB 列且版本较老或者磁盘空间紧张把这一项去掉。阈值不是固定的。我给的是 30/5但这不是普适的。判断标准应该是这个索引主要承受的是范围扫描last_user_scan高还是点查last_user_seek高点查走的是 B 树定位跟页是否连续关系不大碎片高一点影响有限范围扫描和预读才是碎片的直接受害者。所以如果你的库里某个大表以点查为主碎片 50% 也可以先不动反之以报表扫描为主20% 就值得处理。还有一个更“现代”的替代思路如果索引只是碎片高而结构没问题可以试试先REORGANIZE一遍再评估因为REORGANIZE在线且无锁跑完再看还剩多少。这个做法在碎片主要来自“页乱序”而内部填充率还行的时候特别有效成本远低于重建。我经常用它当“先止血后根治”的过渡手段。5. 一次真实事故的完整排查链路说个具体的案例细节我做了处理但排查过程是原样的。某张核心业务表只做插入和按主键更新大约 3000 万行聚簇索引建在自增列上。某天上午收到反馈说“最近一张对账单加载变慢了”从一个报表任务的耗时曲线看从两周前的 4 分钟逐渐涨到 12 分钟。第一步确认是不是数据库的问题。看那段时间的等待统计PAGEIOLATCH_SH明显升高其余等待都比较平稳。这说明瓶颈在“把数据页从磁盘读进内存”这一环而不是 CPU 或锁。到这一步我排除了网络和应用层的嫌疑往 IO 方向走。第二步看这次任务的实际执行计划。这个报表用一个覆盖索引做范围扫描估计行数和实际行数基本吻合偏差在 10% 以内说明统计信息没有大问题也没有参数嗅探的典型迹象。执行计划里出现了一个明显的Index Scan扫描的是一个非聚簇索引且带Ordered False。第三步查这个索引的物理状态。用DETAILED模式查结果page_count约 12 万页avg_fragmentation_in_percent58%avg_page_space_used_in_percent62%fragment_count很高说明页被切得很零碎。同时看了sys.dm_db_index_operational_stats这个索引的page_io_latch_wait_in_ms很高。到这一步结论很明确外部碎片 58%范围扫描在机械盘上这个实例用的还是普通阵列导致随机读放大预读效率崩了。第四步也是关键的一步问自己“为什么它会碎成 58%”。这个索引的键是“业务日期 状态 单据号”业务日期虽然大体递增但补录功能会让历史日期的数据不断插进来插入位置随机分布在整个索引范围内。而它的填充因子是默认的 100。这就解释了为什么它只涨不降——每天都有中间插入每插就裂。第五步处理。我在维护窗口做了两件事一是REBUILD WITH (FILLFACTOR 85, SORT_IN_TEMPDB ON, ONLINE ON)二是把这个索引的填充因子固化下来重建时指定的填充因子会写入元数据后续重建不指定的话会沿用。重建后碎片降到 0.3%页填充率 83%。第六步验证。报表任务耗时从 12 分钟回到 4 分 20 秒比原来的 4 分钟略慢属于正常波动。等待统计里PAGEIOLATCH_SH回落到背景水平。第七步防复发。这是最容易被跳过但最重要的一步。我把这个索引纳入了按周度的维护清单同时观察了三周碎片每周涨大约 6~8%也就是大约 4 到 5 周会回到 30% 的临界线。所以我把它的维护频率定为每两周一次REORGANIZE在线、轻量每季度一次REBUILD重置填充。这样就不再依赖“出问题再修”的模式。这里有个我认为很多人会犯的错只处理指标不处理成因。如果那次我只是重建了事填充因子还是 100那两个月后同样的问题会再次发生而且是同一张表、同一个索引。真正的修复是“降低页密度 建立维护节奏”这两件事一起做缺一不可。顺便说一下 85 这个值的来历。我算了一下这个索引总共 12 万页按 85% 填充多占约 2.1 万页约 165MB 空间。每天中间插入约 8000 行每行约 180 字节一页约 44 行85% 填充后每页能再容纳约 6~7 行的缓冲。8000 行分摊到 12 万页里每天每页的中间插入远小于 1 行所以理论上缓冲能用很久。之所以选 85 而不是 80是因为 80 意味着 20% 的空间浪费对一个大索引来说磁盘占用不小85 已经够覆盖几个月的增长。这个计算不需要很精确量级对了就行核心是别让填充因子停在 100。6. 填充因子、分区表、在线重建几个容易翻车的边界6.1 填充因子是索引级属性不是库级开关实例级的fillfactor配置项只影响“创建索引时不指定填充因子”的默认值它不会追溯修改已有的索引。很多人改了服务器配置就以为生效了实际上已有的索引还是按旧的填充因子在跑。要改某个索引必须ALTER INDEX ... REBUILD WITH (FILLFACTOR X)而且这个动作要定期重复因为如果后续有人重建时没带这个参数会沿用元数据里的值好消息是不会被重置成默认值坏消息是新建索引会拿默认值。另一个隐患填充因子只作用于叶子层中间层根页和中间页按固定规则留空除根页固定留一行空位外中间页会被填满。所以填充因子调得太大中间层的分裂依然会发生只是影响相对小。6.2 分区表的重建粒度决定了锁的范围如果表做了分区ALTER INDEX ... REBUILD默认重建整个索引所有分区。可以指定PARTITION n只重建某个分区这在维护窗口很短的时候非常有用——比如只重建最近三个月活跃的分区。但要注意单独重建某个分区不会自动修复跨分区的页乱序因为分区本身就是物理独立存储的。另外分区表的在线重建限制更多某些版本下只能以ONLINE ON重建一个分区不能全部。6.3 在线重建的空间代价被严重低估ONLINE ON需要同时在库里保留旧结构和新结构直到重建结束。这意味着至少需要额外一份索引大小的可用空间。我有一次在一个存储快满的实例上开了在线重建结果重建到 80% 时报“磁盘空间不足”事务回滚然后还得清理半天。所以开在线重建之前先看一眼索引大小和剩余空间留出 1.2 倍余量比较稳妥。另外在线重建会产生大量日志如果在完整恢复模式下可能让日志文件迅速膨胀。有这个风险的话可以配合日志备份在中途截断或者干脆选离线重建。6.4 REORGANIZE 在超大索引上可能“永远跑不完”REORGANIZE基于LOB_COMPACTION或页交换进行它的进度可以用sys.dm_exec_requests里的percent_complete观察但这个百分比在某些版本和某些场景下不准甚至显示为 0 一直到结束。对于几十 GB 的索引REORGANIZE跑十几个小时是常事而且它是可中断的——中断后已完成的部分有效。我的经验是超过 10GB 的索引别指望 REORGANIZE 解决重度碎片直接安排窗口重建或者接受它的碎片从查询端优化调整索引、加覆盖列、改写查询。6.5 别忽视“重建后的统计信息”很多人知道重建会重置统计信息但不知道重建只更新该索引上的统计信息列统计、过滤统计不一定跟着更新。如果你的慢查询更依赖是某个列上的统计比如带WHERE的估算重建索引可能帮不上忙。我的习惯是维护窗口的最后一步对着核心表跑一次UPDATE STATISTICS ... WITH FULLSCAN尤其是那些有过滤条件、有计算列的表。这一步花的时间不多但常常能解释“索引重建了为什么还是慢”。7. 我实际在用的维护策略讲完原理和坑说点我实际落地的做法。这些不是标准答案是多年试错后留下的、我觉得比较稳的一套。第一层日常不做任何碎片维护。小库、写少读多、数据量不大的系统碎片涨得慢影响小我根本不安排任务。这类库真正的问题通常是缺索引和统计过期不是碎片。花时间在碎片上属于自我安慰。第二层按索引的“使用画像”分类管理。我把核心索引分成三类类型特征维护方式热点范围扫描型last_user_scan高、页数大、有中间插入每周 REORGANIZE季度 REBUILD 重置填充因子点查型last_user_seek占绝对主导碎片 60% 以下不处理只写不读型last_user_*全 NULL、非唯一评估删除不维护这个分类表贴在我的运维文档里每次上线新表就对照着填。它最大的价值不是精确而是逼我思考“这个索引到底怎么被用的”。第三层维护窗口内的执行顺序。先做 REORGANIZE在线、快、风险低再做 REBUILD重、可能要锁最后跑UPDATE STATISTICS。如果窗口时间不够宁可跳过 REBUILD 也不要在时间紧张的情况下开一个可能跑不完的任务——半途中断的 REBUILD 会留下一个不可用的索引除非用了在线重建但中断后也会回滚浪费时间。第四层监控而不是事后救火。我写了一个轻量的巡检脚本每天凌晨跑一次把page_count 10000且碎片 30% 的索引记到一张日志表里连续三天上榜的才告警。这样避免了一次性波动导致的误报也避免了我需要天天看报表。第五层接受不完美。不是所有碎片都要消到 0。有些大表因为写入模式特殊碎片永远在 20~40% 之间震荡重建完下周就回到 30%。这种情况下我的选择是把填充因子调到位、把维护频率定下来、从查询端覆盖索引、改写、分页去优化而不是和碎片无限较劲。碎片管理是手段查询性能是目的搞反了就变成给 DMV 打工。最后分享一个我用了很久的小习惯每次重建完把重建前后的page_count、avg_fragmentation_in_percent、关键查询的实际耗时记下来攒成一张表。时间长了这张表会告诉你很多参数该怎么定——哪种表重建收益最大、填充因子多少最划算、维护间隔多长合适。这些数据比任何文章里的推荐值都更贴合你自己的库。