服务器端如何配置fillfactor，影响数据库性能吗？

fillfactor的配置绝不是一个固定公式，而是基于数据库读写特征权衡空间与性能的动态过程，但SQL Server 90（80%）和MySQL 5.7+（75%）的默认值适配多数场景。

fillfactor是什么，为什么它值得你在意

数据库索引不是一块铁板，而是由叶子节点组成的树形结构，每个叶子节点就像一格货架，默认情况下货架塞满数据页，此时新数据插入，货架没空位，SQL Server只能做页拆分把一半数据移到新页,这个动作代价高昂且会立刻制造索引碎片。

加载中

SQL Server配置

LambAI

412144-

原视频地址

fillfactor的核心逻辑就是：给这个货架预先留出空位，让新数据有地方可放，降低页拆分概率。

设定80的fillfactor，意味着每个数据页只装载80%的行，余下20%留给后续插入，这对频繁做INSERT和UPDATE的表尤其重要，行业共识认为，这个值与数据页写入比率直接挂钩,选定值就是选定空间换性能的交换比例。

理解页面密度与空间余量的博弈

• 高fillfactor（90-100）：页面密度高，更省存储空间，读取连续扫描性能更好，但写入时页拆分频繁,索引碎片增长快。
• 低fillfactor（70以下）：预留空间充足，写入平滑不折腾，但页面密度低，占用磁盘更多，查询时需要读更多页,读性能被拖累。

这个权衡没有标准答案，只有适合场景的答案，OLTP系统高并发写多读少，需要一个相对低的值；数据仓库表很少更新以读为主,可以把值拉高。

fillfactor默认值多少合适、不同数据库怎么设置

或者按场景来理解，你应该问的不是”默认值该改不”，而是”当前数据库的写入模式在制造多少页拆分”。

SQL Server中的fillfactor默认值

SQL Server的填充因子默认值是0，代表100%满载，这让大部分DBA忽略了它的存在，直到索引碎片报告打脸，行版本控制、快照隔离等机制的引入让写放大问题更突出，调整fillfactor的必要性比SQL Server 2008时代更高。

行列存的差异，依据微软官方文档对ALTER INDEX的说明，填充因子仅仅影响索引创建或重建时的数据存放方式，不会动态维护这个比例，随着时间推移和写入累积，预留空间逐渐消耗,密度会回到接近满载。

这意味着fillfactor不是一个配置完就一劳永逸的值，它只是设定了一个类似出厂设置的起点,你需要配合定期维护来让它持续生效。

设置fillfactor的完整操作路径

通过T-SQL设置（推荐）

如果你要设置全库所有索引的fillfactor，可以这样操作，先在SSMS中设置服务器默认值,再对索引执行重建：

-- 设置服务器级别的默认填充因子为80
EXEC sys.sp_configure N'fill factor', N'80';
GO
RECONFIGURE WITH OVERRIDE;
GO
-- 查看当前默认值
SELECT name, value_in_use 
FROM sys.configurations 
WHERE name = N'fill factor';

对单个索引设置：

ALTER INDEX [IX_TableName_ColumnName] 
ON [dbo].[TableName] 
REBUILD WITH (FILLFACTOR = 80);

通过SSMS图形界面

1. 连接实例，展开”数据库”,找到目标表。
2. 右键点击索引，选择”属性”。
3. 左侧选择”选项”，找到”填充因子”。
4. 下拉选择火输入数值，点击确定后执行”重新生成”。

MySQL中的fillfactor类似功能

MySQL的InnoDB引擎没有直接的fillfactor参数，但有一个近似的控制项：MERGE_THRESHOLD，它控制索引页在删除操作后何时合并，默认50，值设低一些会减少索引页合并的频率,适合碎片敏感的写入密集型场景。

-- 查看当前索引的合并阈值
SELECT  FROM information_schema.INNODB_METRICS WHERE NAME LIKE '%merge%';
-- 建表时指定索引页合并阈值
CREATE TABLE t1 (
  id INT NOT NULL,
  col1 VARCHAR(100),
  KEY idx_col1 (col1) COMMENT 'MERGE_THRESHOLD=45'
) ENGINE=InnoDB;

另一个接近的思路是用COMPRESSED页压缩和KEY_BLOCK_SIZE调整InnoDB的页面存储密度,间接实现类似fillfactor的空间与性能博弈。

读写比例决定填满程度

• 90-100区间：适合批处理报表库、数据仓库层,只读或近只读场景可以直接100。
• 70-85区间：OLTP高并发INSERT/UPDATE/DELETE混合场景的标准选择，SQL Server最常见推荐是80，MySQL的索引合并阈值对应45-60。
• 50-65区间：极少使用,除非你的表每天有海量随机写入且对查询延迟容忍度很低。

怎么判断你该不该调整fillfactor观察这些信号

不要人云亦云地说”默认值不够好”,要回到现场证据来判断。

sys.dm_db_index_physical_stats视图（SQL Server 2005+均可使用）可以给出碎片率和页面密度：

SELECT 
    OBJECT_NAME(ips.object_id) AS TableName,
    i.name AS IndexName,
    ips.avg_page_space_used_in_percent AS PageDensity,
    ips.avg_fragmentation_in_percent AS Fragmentation,
    ips.page_count
FROM sys.dm_db_index_physical_stats(
    DB_ID(), NULL, NULL, NULL, 'SAMPLED'
) AS ips
INNER JOIN sys.indexes AS i 
    ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.page_count > 1000
ORDER BY ips.avg_page_space_used_in_percent ASC;

avg_page_space_used_in_percent直接告诉你页面的实际填充程度。

• 如果这个值长期高于95而你观察到大量页拆分等待,说明fillfactor设高了。
• 如果这个值长期低于60，说明预留空间太多,查询性能被浪费在读取空页上。

业内专家指出，多数碎片问题的根源并非fillfactor本身，而是缺少定期索引维护计划，每周重建或重组一次索引,比调整fillfactor能解决更多问题。

选择合适的维护策略

• 重组（ALTER INDEX REORGANIZE）：轻量操作，碎片率5%-30%区间适用,不对fillfactor生效。
• 重建（ALTER INDEX REBUILD）：重量级操作，碎片率超30%时建议进行,会将fillfactor重置为目标值。

碎片率统计是观察索引健康的风向标，逻辑碎片的产生与fillfactor收纳空间预留息息相关，业内普遍将碎片率30%，视为判读需要行动的分界线，低于它时执行REORGANIZE更划算,高于它时REBUILD的收益更大。

表数据特征也是选择fillfactor的重要依据

以插入为主且数据量持续增长的表

订单表、日志表、流水表属于这类，按时间递增插入,每次插入都落在索引末端。

对策：fillfactor设80，或者对聚集索引的末尾页不做额外预留，因为连续插入时页拆分极少发生在中间位置,低fillfactor反而浪费空间。

更聪明的做法是定期维护时判断末尾页的使用情况尾部几个页密度通常接近100，这是健康状态，不需要为它们预留太多，这种情况下，一个中间偏低的值或默认值配合碎片修复计划,在多数情况下更合理。

随机插入和删除并存的表

会话表、队列表、状态机表属于这类，数据写入的分布是散弹式的,更新涉及多个索引。

对策：将fillfactor调到60-70，预留足够空间吸收随机写入，同时可以为非聚集索引单独设置更低的fillfactor,因为非聚集索引通常比聚集索引更碎片化。

读写均衡但读要求快速响应的场景

大部分SaaS应用的表属于这一档，读多写不少,但用户请求要求低延迟。

对策：表数据规模不大（小于10GB）时，fillfactor设70-80，配合一周一次的重建，能兼顾性能和空间，表数据规模很大时，建议维持80，通过分区来缓解写入压力,而不是继续降低fillfactor。

设置fillfactor时容易被忽略的细节

• 填满因子对索引重建时生效，不是实时调整，如果你期望一个已有索引的Fillfactor从默认值变成80，必须执行重建,除非你删掉重建。
• 离线重建会锁表，在7×24的OLTP系统上慎用，SQL Server企业版可以提交ONLINE = ON参数,但需要额外的版本存储空间。
• 键值重复度高的索引，把页面预留得过高可能导致大量重复页扫描，导致fillfactor分配失效,此时应该使用INCLUDE列减少键列宽度才是正解。



• 压缩索引与fillfactor不冲突，页压缩开启后实际存储密度可能高于fillfactor设定，但只要fillfactor没设满,数据页尾部仍保持物理空位。

一个简洁的工作流参考

1. 收集所有表的大小区间、写入量和碎片率。
2. 将大表、写入频繁的表标记出来。
3. 预估重建或重组的时间窗口，业务高峰避免此类操作,规划好风险预案。
4. 执行调整,第一次调整后观察两周写入延迟与碎片率变化。
5. 根据观测结果微调,保留工作流但不盲目重复。

fillfactor的变动会连锁影响什么

备份文件大小与fillfactor直接相关，低的fillfactor意味着备份体积更大，恢复时间随之变长，如果你每周做全量备份，填满因子设70比90多出约25%的备份体积，好在多数企业云数据库已支持压缩备份,这项影响正在被淡化。

统计信息采样也受影响，页面密度低导致统计抽样需要扫描更多页数据,统计更新耗时变长。

副本同步延迟，在AlwaysOn或镜像环境中，低fillfactor会让数据复制量增加，主节点与副本节点的同步延迟可能被放大，从这个角度说，大胆怀疑那些”把全库所有索引的fillfactor统一调到70″的做法,是有价值的。

Q&A：fillfactor配置的实际问题

Q：SQL Server中fillfactor设置80和90，在性能上有多大差异？

80的配置在写入频繁的环境中页拆分更少，但读取需要多扫描约10%的页，90更节省空间与备份时间，但写入占比超过30%的表中会在高并发下造成大量页拆分等待（可以用sys.dm_os_wait_stats中的PAGEIOLATCH_SH或等待类型观察），写入等待与读性能在一定比例下收益平衡，80与90的实际差异需要针对单个索引监控一段时间才能得出精确判断，整体差异通常不超过15%的IO消耗。

Q：设置了fillfactor后还需要定期重建索引吗？

需要，因为fillfactor只在重建时生效，而且行版本控制、快速插入等操作持续消耗预留空间，重建周期建议每周一次（低写入表可拉长到每月），同时结合碎片率来决定是REORGANIZE还是REBUILD,而不是机械地按时间重复执行。

Q：MySQL没有fillfactor，如何实现类似的效果？

InnoDB使用MERGE_THRESHOLD控制页合并阈值，也支持PAGE_COMPRESSED等压缩特性，在逻辑层面达到接近fillfactor的目的，善用ALGORITHM=INPLACE的在线DDL来执行OPTIMIZE TABLE，但对写多读少的表，把工夫下在连接池设置、事务大小与提交频率上，收益往往比折腾存储参数更直接写放大和锁等待的根源,多数时候在于SQL模式和事务设计。