SQL Server索引碎片整理：测量、重建重组与锁风险控制

1. 片段化到底在伤什么先把问题看透数据库跑了两三年某张核心表的查询从 200 毫秒涨到 4 秒索引重建完立刻回落到 180 毫秒过两个月又开始变慢——这种反复出现的现象十有八九不是硬件不行也不是 SQL 写得烂而是索引碎片在悄悄拖后腿。SQL Server 碎片整理这件事听起来像是个老掉牙的运维动作但真正做对的人并不多有人每周无脑重建全部索引把生产库锁到业务超时有人看到碎片率 30% 就慌其实那张表只有 200 行还有人只盯着碎片率压根没看页密度结果整理完空间没省下、性能也没涨。我先把这篇文章要讲清楚的东西摆出来什么是 SQL Server 的索引碎片、它为什么会拖慢查询、碎片率怎么测、重建和重组到底怎么选、分区表和大表怎么处理、整理过程中怎么避免锁库、以及整理完之后为什么还会再碎。适合谁看日常要维护几套业务库的运维、后端开发、以及被“数据库越来越慢”这个问题困扰过的技术负责人。哪怕你只会写SELECT跟着走一遍也能上手如果你已经在定期跑维护计划那更值得看看里面有几处是常见误区。需要先建立一个基本认知SQL Server 存储数据的最小单位是页Page一个页 8KB页里放行数据或索引键。当页写满了、又要插入新行时SQL Server 会做页拆分Page Split把一页拆成两页新页通常拿一半数据。问题就出在这里——新页在物理磁盘上未必紧挨着原页于是逻辑上连续的索引物理上却散落在文件的各个角落。这就是外部碎片。另一种情况是页里的数据被删除后留下空洞页的填充度下降同样 8KB 只装了 30% 的数据这是内部碎片也叫页密度问题。这两种碎片带来的代价不一样。外部碎片影响的是预读效率SQL Server 做范围扫描时会按逻辑顺序发起预读但如果物理不连续磁盘磁头机械盘或闪存页SSD就得来回跳一次本该 4 次 IO 读完的连续 8 页可能变成 8 次离散 IO。内部碎片影响的是缓存和带宽同样的行数占用了更多页缓冲池里装的页数变少命中率下降扫描时读取的字节数也变多。用个生活化的类比外部碎片像把一本书的页码顺序打乱了装订你想读第 10 到 20 页得满屋子找内部碎片像每页只印了三行字剩下全空白书变厚了三倍翻起来自然更累。还有一类容易被忽略的转发记录Forwarding Pointer。堆表没有聚集索引的表上更新变长列导致行变长、当前页放不下时SQL Server 会在原位置留一个指针把行搬到别处。查询时读一次转发记录等于多一次 IO碎片率指标里那个“转发记录数”就是干这个的。很多人只盯索引碎片结果堆表的转发记录堆到几万条性能照样崩。所以碎片整理的核心目标从来不是“把碎片率降到 0”而是在可接受的锁开销和 IO 开销下让页的物理顺序尽量贴近逻辑顺序、让页密度回到合理区间。理解了这个目标后面所有关于“重建还是重组”“阈值定多少”的争论都会变得有据可依而不是抄别人的脚本。2. 碎片率怎么测才算数三个视图和一个坑动手之前必须先能量化。SQL Server 提供了几个系统视图用对了能省很多事用错了会得出完全相反的结论。2.1 三张核心视图的分工最常用的是sys.dm_db_index_physical_stats这是动态管理函数能返回索引的碎片率、页数、页密度、转发记录等关键指标。它支持五种扫描模式LIMITED、SAMPLED、DETAILED、NULL还有默认的LIMITED行为。这里的取舍非常关键很多人不看文档直接跑DETAILED在几百 GB 的库上能把 IO 打满。扫描模式采样方式适用场景代价LIMITED只扫页级元数据不扫行日常巡检、小表最低SAMPLED按 1% 采样页大表快速估算中等DETAILED全扫所有页和行精确诊断、小表最高我的习惯是日常巡检用LIMITED只有当某张表确认变慢、且LIMITED显示碎片可疑时才对单张表跑SAMPLED或DETAILED。原因很实际——DETAILED在 100GB 的表上跑十几分钟是常事期间还会占大量 IO业务高峰期跑等于自找麻烦。另外两个视图是配套的sys.indexes提供索引的基本信息是否禁用、是否唯一、填充因子sys.partitions提供分区和行数信息。三者关联起来才能得到“哪些索引该处理、处理哪个分区”的完整画像。一个典型的查询长这样SELECT 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, ps.index_type_desc, ps.avg_fragmentation_in_percent, ps.avg_page_space_used_in_percent, ps.page_count, ps.fragment_count, ps.record_count FROM sys.dm_db_index_physical_stats( DB_ID(), NULL, NULL, NULL, LIMITED) AS ps JOIN sys.indexes AS i ON ps.object_id i.object_id AND ps.index_id i.index_id WHERE ps.page_count 1000 ORDER BY ps.avg_fragmentation_in_percent DESC;这里有个必须加的过滤条件page_count 1000。为什么是 1000因为 1000 页大约 8MB低于这个规模的索引页本身就没几页碎片率算出来 90% 也毫无意义——扫描 8 页的成本差异用户根本感知不到。反过来你为了它去重建锁表、写日志、消耗 CPU 的时间成本远大于收益。微软在很多版本的文档里给的建议都是把注意力放在大表上这个经验值经过无数生产环境验证可以直接用。2.2 一个容易踩的坑碎片率不等于页密度新手最典型的问题就是只看avg_fragmentation_in_percent。这个指标在聚集索引和堆上是外部碎片页的逻辑顺序与物理顺序不一致的程度在非聚集索引上也是外部碎片但它不反映页内空洞。页内空洞要看avg_page_space_used_in_percent也就是页密度。为什么两者都要看举个例子一张日志表每天插入大量数据几乎不删除它的外部碎片可能很低顺序写入页是连续的但页密度也可能只有 60%——因为插入时按填充因子预留了空间。这种情况下重建能提升页密度但收益有限而如果一张表频繁删除历史数据外部碎片 40%、页密度 50%那才是真正需要处理的对象。还有一个坑堆表的碎片率参考价值很低。堆表没有聚集索引的键顺序avg_fragmentation_in_percent在堆上反映的是区Extent的连续性而不是页的顺序。真正该看的是转发记录数。堆表的正确指标是SELECT OBJECT_NAME(object_id) AS table_name, forwarded_record_count, record_count, ROUND(100.0 * forwarded_record_count / NULLIF(record_count,0), 2) AS forward_pct FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, SAMPLED) WHERE index_id 0 AND page_count 1000;转发记录占比超过 10%、且绝对数量上千的堆表建一个聚集索引或者定期ALTER TABLE ... REBUILD收益往往比整理索引还大。这个点在很多教程里被略过了实际生产里堆表一堆转发记录的场景非常常见尤其是那些老系统里懒得建主键的表。2.3 测量时的锁与并发影响DETAILED模式会触发表级扫描在 SQL Server 2016 之前它会对表加共享锁Sch-S如果表上还有长时间未提交的事务扫描会被阻塞更糟的是LIMITED模式虽然轻但在某些版本下依然会申请意向共享锁。所以测量动作本身也要挑时间。提示大表的碎片检测尽量放在业务低峰或者用SAMPLED替代。测量本身不是目的别为了诊断把线上服务拖慢。我在一个中等规模的业务库上做过对比DETAILED扫一张 60GB 的订单表耗时约 8 分钟期间该表的查询平均延迟上升 40%换成SAMPLED后耗时 40 秒延迟影响不到 5%碎片率误差在 3 个百分点以内对决策完全够用。这个结论我建议你也在自己的环境里验一下因为不同版本的实现细节和硬件差异都会影响结果。3. 重建还是重组阈值背后的取舍逻辑这是碎片整理最核心的决策点也是争议最多的地方。网上流传最广的是微软文档里那句经典建议碎片率 5% 到 30% 之间用重组REORGANIZE超过 30% 用重建REBUILD。这句话没错但它是有前提的直接无脑照抄会出问题。3.1 两种操作的本质差异先把机制说清楚。**重组REORGANIZE**是联机操作它按逻辑顺序逐页读取把页内的行重新填满并就地调整页的顺序。它不重建索引结构日志写入量被严格控制使用了日志压缩所以事务日志不会暴涨对业务阻塞很小。代价是它只能处理页级对于大量页顺序错乱的情况效果一般且速度慢。**重建REBUILD**是重新构建整个索引结构新建一棵索引树把数据按正确顺序写进去再删掉旧的。结果最彻底碎片率基本归零、页密度回到填充因子设定值统计信息也随之更新这是一个非常实用的附带收益。但代价是操作期间需要大量日志空间如果走完整日志模式并且会对表申请排他锁Schema Modification 锁即 Sch-M在默认的联机选项下重建期间表是只读的业务写入会被阻塞。维度重组 REORGANIZE重建 REBUILD联机性完全联机阻塞极小企业版可 ONLINEON标准版默认锁表日志开销小日志压缩大等于索引大小量级碎片处理效果中等页顺序改善有限彻底碎片归零统计信息不更新自动更新全扫中断恢复可中断已做部分保留中断需回滚代价高适用规模中小碎片率、大表高频整理高碎片率、可接受窗口关键点是那句标准版默认锁表。SQL Server 的企业版支持ONLINE ON在线重建业务读写基本不受影响而标准版的在线重建能力在不同版本上支持范围有限2016 之前基本只能离线很多公司用的就是标准版。这意味着在标准版上对大表重建必须放到维护窗口里做不能像企业版那样随意。这一点如果不提前确认直接照搬脚本很可能在业务高峰期把一张热表锁死几分钟到几十分钟。3.2 阈值到底怎么定的三个修正因素微软的 5% / 30% 建议是一个统计意义上的经验值落到具体环境要按三个因素修正。第一表的大小。前面说过 1000 页以下的索引直接忽略。对于 1000 到 10000 页的索引可以放宽阈值——比如 30% 以下都只重组或者干脆不处理因为规模小、收益小、风险也小。对于超过 100 万页的大表碎片率 10% 就应该动手了因为即使 10% 的碎片在亿级行数上也会导致明显的预读代价。第二访问模式。如果这张表是纯 OLTP 的点查根据主键查单行外部碎片几乎不影响性能——因为它是索引查找Seek只读少数几页页在哪无所谓。碎片真正伤的是范围扫描Range Scan和全表扫描比如报表查询、批量导出、BETWEEN ... AND ...这类。所以对点查为主的表碎片率 50% 都可以先放着对分析型查询频繁的表20% 就值得处理。第三写入频率。一张每秒插入几百行的表你今天整理完明天碎片又回来了。对它来说固定阈值的定期整理是一种浪费——真正该做的是调整填充因子给页面预留插入空间让页拆分发生得晚一些、均匀一些。基于这三点我通常采用的策略是分层的页数小于 1000不看碎片只保证统计信息更新。页数 1000 到 10000碎片超过 50% 才处理优先重组。页数超过 10000碎片超过 20% 处理20% 到 40% 重组超过 40% 考虑重建在维护窗口内。高频写入表重点调填充因子碎片整理降频或交给自动维护。注意这套阈值不是标准答案是基于收益与风险平衡的工程判断。你的环境里如果维护窗口很宽裕完全可以更激进如果是 7×24 不允许断的业务就应当更保守优先在线重组。3.3 填充因子被大多数人跳过的真正解法说到碎片反复出现就必须提填充因子Fill Factor。它的含义是建索引或重建时每页最多填充到百分之多少剩下的空间留给未来的插入。默认值 0等价于 100意味着页写满才拆分页拆分必然发生且拆分出来的两页各占一半碎片迅速累积。把填充因子设成 80 到 90等于每次插入都有一点余量页拆分频率显著下降碎片增长速度变慢。代价是同样的数据占用更多页扫描时读的页更多缓存效率略降。这是一个典型的空间换稳定的权衡。我一般这样定只读或极少写入的维度表、历史表填充因子保持 100不浪费空间高频随机插入的表订单、日志、流水聚集索引设 80 到 85顺序插入的表自增主键比如流水号递增其实 90 就够因为插入都集中在最后一页前面的页不会拆。这个判断需要看主键生成方式自增和随机 GUID 的差别非常大——随机 GUID 做主键是碎片的头号制造机因为它把插入分散到整棵树的任意位置。提示填充因子是索引级属性重建时如果不显式指定会沿用索引上已保存的值如果用脚本重建却没带FILLFACTOR而索引上原本设了 80重建后会保持 80这点不用担心。但如果用删除再创建的方式就会丢。4. 整理脚本怎么写才不出事理论说完进入可落地的部分。很多人整理碎片的方式是打开维护计划向导勾一个重新组织索引/重新生成索引就完事。这个做法在小库上没问题在大库上有两个隐患一是它会对所有索引无差别处理包括那些根本不需要动的二是它不区分在线离线标准版上照样锁表。所以更稳妥的方式是写自己的脚本可控、可审计、可分批。4.1 一个可直接用的智能整理脚本下面这个脚本的思路是先筛出满足条件的索引页数阈值 碎片阈值再按碎片率决定用重组还是重建同时跳过禁用索引、系统表和非聚集索引之外的边缘情况。SET NOCOUNT ON; DECLARE db_id int DB_ID(), min_pages int 1000, reorg_thr decimal(5,2) 20.0, rebuild_thr decimal(5,2) 40.0; DECLARE sql nvarchar(max) N; SELECT sql STRING_AGG( CASE WHEN ps.avg_fragmentation_in_percent rebuild_thr THEN NALTER INDEX QUOTENAME(i.name) N ON QUOTENAME(OBJECT_SCHEMA_NAME(i.object_id)) N. QUOTENAME(OBJECT_NAME(i.object_id)) N REBUILD WITH (ONLINE ON, MAXDOP 4); ELSE NALTER INDEX QUOTENAME(i.name) N ON QUOTENAME(OBJECT_SCHEMA_NAME(i.object_id)) N. QUOTENAME(OBJECT_NAME(i.object_id)) N REORGANIZE; END, NCHAR(10)) FROM sys.dm_db_index_physical_stats(db_id, NULL, NULL, NULL, SAMPLED) AS ps JOIN sys.indexes AS i ON ps.object_id i.object_id AND ps.index_id i.index_id WHERE ps.page_count min_pages AND ps.avg_fragmentation_in_percent reorg_thr AND i.is_disabled 0 AND i.type IN (1, 2) -- 聚集索引、非聚集索引 AND OBJECTPROPERTY(i.object_id, IsSystemTable) 0; IF sql N EXEC sp_executesql sql;这段脚本有几个设计点值得说明。STRING_AGG需要 SQL Server 2017 及以上老版本换成FOR XML PATH拼接。ONLINE ON在标准版上可能报错取决于版本和索引类型所以上线前一定要先在测试库跑一遍确认版本支持不支持就把ONLINE去掉并把执行时间挪到维护窗口。MAXDOP 4是限制并行度避免一个大索引重建把 CPU 全吃光——这个值要按你的核数调4 到 8 是常见范围。还有一个细节脚本对每个索引单独执行没有包事务。这是有意的——一个事务包住所有重建日志会爆且中途失败全部回滚。分批执行、每批做完提交是更稳的做法。4.2 大表分批避免一次性锁死对于超过 5000 万行的表即使重建一次做完也可能耗时半小时以上。更稳的策略是按分区或按范围分批处理。SQL Server 2016 之后支持ALTER INDEX ... REBUILD PARTITION n分区表可以逐个分区重建每次只锁一个分区其余分区仍然可读写。非分区表怎么办一种实用做法是配合WAIT_AT_LOW_PRIORITY选项2014 起支持让重建操作在拿不到锁时自动降级等待不阻塞业务ALTER INDEX IX_Order_CreateTime ON dbo.Orders REBUILD WITH (ONLINE ON, MAXDOP 4, WAIT_AT_LOW_PRIORITY (MAX_DURATION 10 MINUTES, ABORT_AFTER_WAIT BLOCKERS));这个选项的意义在于重建需要 Sch-M 锁如果此时有长事务占着表默认行为是无限等待把后面的所有请求全堵住。加上WAIT_AT_LOW_PRIORITY后最多等 10 分钟之后按ABORT_AFTER_WAIT的策略处理——BLOCKERS是杀掉阻塞者SELF是放弃本次重建NONE是不处理继续等。生产环境我更倾向SELF宁可这次不整理也不要误杀业务连接。4.3 日志空间最容易被低估的风险重建索引的日志量大致等于索引数据量完整恢复模式下。一个 50GB 的索引重建日志可能涨 50GB。如果数据库的日志文件设了自动增长但磁盘空间不够重建跑到一半日志满了整个操作回滚回滚时间可能比正向操作还长——这个场景我见过不止一次凌晨维护窗口被一个失败的重建拖到早上。规避手段有四个一是重建前查一下日志空间余量留足 1.5 倍索引大小二是把重建分批三是考虑临时切到简单恢复模式但要评估对备份链的影响这个操作要谨慎做完立刻切回来并做一次完整备份四是用SORT_IN_TEMPDB ON把排序的临时数据放到 tempdb减少用户库日志压力代价是 tempdb 要够大。ALTER INDEX IX_Order_CreateTime ON dbo.Orders REBUILD WITH (ONLINE ON, SORT_IN_TEMPDB ON, MAXDOP 4);注意SORT_IN_TEMPDB只是在排序阶段减少用户库日志最终的索引变更日志仍然写入用户库日志。它不能替代日志空间规划。5. 分区表、列存与特殊索引的处理差异常规行存索引的整理逻辑相对统一但一旦涉及分区表、列存索引、XML/空间索引规则就不一样了照搬通用脚本很容易出问题。5.1 分区表的碎片边界分区表的关键概念是碎片是分区级别的不是表级别的。一个表有 24 个月度分区可能只有最近两个热分区碎片严重其余历史分区几乎不变。这时候全表重建是巨大的浪费。正确做法是先按分区查碎片SELECT OBJECT_NAME(ps.object_id) AS table_name, i.name AS index_name, ps.partition_number, ps.avg_fragmentation_in_percent, ps.page_count FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, SAMPLED) AS ps JOIN sys.indexes AS i ON ps.object_id i.object_id AND ps.index_id i.index_id WHERE ps.page_count 1000 AND ps.avg_fragmentation_in_percent 20 ORDER BY ps.avg_fragmentation_in_percent DESC;注意这个查询没有按partition_number聚合返回的是每个分区的明细。拿到结果后只对高碎片分区执行REBUILD PARTITION n。还有一个常被忽略的点分区切换SWITCH后再整理。如果你用分区切换来做数据归档切换过来的分区数据是新写入的碎片情况未知最好在切换完成后针对该分区单独整理一次。另外分区表上重建单个分区时如果该表上有非对齐索引索引的分区函数与表不一致是无法按分区重建的会直接报错。这种情况必须先对齐索引或者退回整表重建。这个限制在做分区表设计时就应该考虑到。5.2 列存索引不要用行存的思路列存索引Columnstore的碎片含义和行存完全不同。列存按列存储、按行组分段Row Group理想状态是每个行组接近 100 万行且经过压缩。碎片体现在两方面一是行组过小比如大量小批量插入导致行组只有几千行压缩率低、扫描效率差二是删除标记过多deleted rows 比例高查询时要跳过这些行。列存索引不支持 REORGANIZE 的常规碎片整理语义也不能简单用avg_fragmentation_in_percent判断。正确的做法是查sys.dm_db_column_store_row_group_physical_stats关注deleted_rows和total_rows的比例以及行组大小分布。对于小行组用ALTER INDEX ... REORGANIZE会触发行组合并Tuple Mover把小行组合成大行组对于删除标记过多的行组需要REBUILD可以按分区。SELECT OBJECT_NAME(object_id) AS table_name, row_group_id, state_desc, total_rows, deleted_rows, ROUND(100.0 * deleted_rows / NULLIF(total_rows,0), 2) AS deleted_pct FROM sys.dm_db_column_store_row_group_physical_stats WHERE state_desc COMPRESSED ORDER BY deleted_pct DESC;经验上删除比例超过 10% 就应该考虑重建该分区。列存的重建代价比行存大得多要重新压缩所以频次一定要低通常按月或按季度做配合分区切换来降低单次成本。5.3 其他索引类型的注意事项全文索引、XML 索引、空间索引的整理规则各不相同。全文索引有独立的填充Population机制和常规碎片整理不是一回事空间索引的碎片指标参考价值有限通常靠重建来处理。这些类型在业务库里占比不高但如果你维护的库里有记住一个原则先用官方文档确认该索引类型支持哪些 ALTER INDEX 选项不要假设行存的参数能通用。还有一类特殊情况是禁用索引is_disabled 1。禁用的索引在sys.dm_db_index_physical_stats里也可能出现但重建它等于重新启用这会带来额外影响比如唯一索引重建时可能因数据重复失败。脚本里加i.is_disabled 0过滤掉是必要的保险。6. 整理完还是慢排查思路与常见问题实录经常有人问索引重建完了碎片率也归零了为什么查询还是慢这个问题背后通常不是碎片整理失败而是把碎片当成了性能问题的唯一原因。下面把我实际遇到过的典型情况和排查路径整理出来。6.1 常见问题速查表现象最可能的原因排查动作重建后查询仍慢统计信息过期或参数嗅探查执行计划看是否估算行数严重偏离实际重建后短时间更慢计划缓存里的旧计划失效正在重编译观察 10 到 30 分钟通常会恢复整理脚本执行超时大表全量重建日志或锁等待改分批、加WAIT_AT_LOW_PRIORITY碎片率整理后很快回升填充因子过低或主键为随机 GUID调填充因子考虑改主键生成方式重组跑了很久没进展大表高碎片重组本身慢改用重建或按分区处理整理时业务报超时标准版重建锁表确认版本是否支持ONLINEON挪窗口堆表性能差但索引无碎片转发记录过多查forwarded_record_count考虑建聚集索引6.2 三个真实踩坑记录坑一以为重建会自动更新所有统计信息。索引重建确实会更新该索引上的统计信息用全扫描但非索引列的统计信息不会更新。一张表如果查询条件用的是非索引列重建索引对它毫无帮助。我就遇到过重建完整张表索引、查询依然走错计划的情况最后发现是多列统计信息过期。这种情况要用UPDATE STATISTICS单独处理或者开启AUTO_UPDATE_STATISTICS并配合AUTO_UPDATE_STATISTICS_ASYNC。坑二在 Always On 可用性组上重建导致 Secondary 落后。可用性组的主副本上做重建所有日志都要传到辅助副本重做。一个大索引重建产生的日志量可能让辅助副本的重做队列暴涨延迟几分钟到几十分钟。如果辅助副本承担只读查询这段时间的读延迟会很明显。处理办法是控制单次重建的规模或者把整理安排在辅助副本负载低的时段并监控sys.dm_hadr_database_replica_states里的redo_queue_size。坑三维护计划里的重建全部索引把小表也带上锁等待连锁反应。有些维护计划模板会对数据库里所有索引重建包括几十张只有几百行的小表。这些小表的重建本身很快但它们可能被高频访问重建瞬间的 Sch-M 锁会导致大量请求排队进而把连接池占满引发连锁超时。后来我把脚本改成按页数过滤只处理大表问题消失。这个教训说明碎片整理不是越全面越好精准比全面重要。6.3 整理之后的监控闭环碎片整理不是一次性任务做完要有验证。我的做法是整理前后各采一次基线记录目标表的碎片率、页密度、关键查询的逻辑读次数和执行时间。整理后逻辑读应该下降页密度提升的直接体现执行时间在高碎片场景下会有改善但如果逻辑读没变说明这张表的瓶颈根本不在碎片。建立监控时重点关注三个指标的趋势目标索引的碎片率周环比、页密度、以及关键查询的 reads 平均值。如果碎片率每周都快速回升到 30% 以上那不是整理频率不够而是填充因子或主键设计有问题应该从根上改而不是加大整理频次。7. 我个人在长期维护中的几点体会做了这些年数据库维护关于碎片整理有几条体会是踩过坑才明白的。第一不要追求碎片率归零。碎片是 B 树结构在动态写入下的自然产物归零只是瞬间状态。把目标定成控制在阈值内比追求完美更实际也更省资源。第二先确认瓶颈再动手。碎片整理有效的场景是有明确的范围扫描代价如果瓶颈是缺少索引、SQL 写法差、内存不足整理碎片一点用没有。我见过太多人把性能问题归因于碎片整理完发现没变化又回头怀疑硬件。先看执行计划、看等待类型再决定要不要整理。第三脚本要能审计。整理动作必须留痕什么时候、对哪个库哪张表的哪个索引、用了重组还是重建、耗时多久、影响多少行。出了问题能回溯也方便评估整理的实际收益。我习惯把每次执行结果写进一张维护日志表长期看这张表的趋势比任何单次诊断都有价值。第四区分业务库和分析库。OLTP 库的碎片整理要克制重点是保证点查性能别为了碎片率把业务锁了分析库或报表库的整理可以激进一些因为它的查询以扫描为主对碎片更敏感而且通常有明确的跑批窗口。第五别忘了统计信息这个孪生问题。索引和统计信息是查询优化的两条腿。碎片整理解决的是物理存储统计信息解决的是优化器估算。两者要一起维护只做其中一个效果都会打折。我现在的维护节奏是碎片按阈值触发统计信息按数据变更量触发变更行数超过表行数的 20% 就更新两者在同一个维护窗口内完成互相不冲突。最后分享一个实用的小技巧如果你的库不大几十 GB 以内维护窗口充裕其实不必纠结阈值每周固定窗口做一次高碎片重建 低碎片重组的全量整理也不会有大问题。真正需要精打细算的是那些 TB 级、7×24 不允许中断的库——那种场景下碎片整理已经从运维动作变成了需要排期和预案的变更阈值、分批、锁策略、回滚方案一个都不能少。把这个心态摆正碎片整理这件事就不会变成生产事故的源头。