重建索引本身不改变压缩算法，因WiredTiger在创建.wt文件时即绑定block_compressor配置，升级后需先调高FCV、再用collMod更新集合/索引配置、最后重建索引才能启用新压缩算法。
直接重建索引不会自动启用新版本的压缩算法——WiredTiger的压缩策略由存储引擎配置决定，不是索引元数据的一部分。升级后真正需要做的是：确认FCV已调高、检查并更新wiredTigerCollectionConfig和wiredTigerIndexConfig，再重建索引以触发新压缩参数生效。
为什么重建索引本身不改变压缩算法
索引文件（index-*.wt）和集合文件（collection-*.wt）的压缩方式，由WiredTiger在创建时读取的表级配置决定，而非MongoDB版本号。即使你从4.4升到8.3，旧索引仍按4.4时期写入时的block_compressor设置压缩，不会因版本升级而重算。
常见错误现象：db.collection.stats() 显示 wiredTiger.block-manager.compression 仍是 snappy，即使目标版本默认已切到 zstd；或 mongod 日志里反复出现 using compressor 'snappy' for existing file。
- 压缩算法绑定在单个
.wt文件创建时刻，后续升级不回溯修改 -
db.collection.reIndex()或db.collection.dropIndexes(); db.collection.createIndex(...)只能重建索引结构，不强制继承新全局配置 - 必须显式指定
storageEngine.wiredTiger.collectionConfig.blockCompressor或使用collMod更新已有集合配置
升级后必须执行的三步压缩策略迁移
以从 MongoDB 5.0 升级到 8.3 为例，目标是让所有新索引和集合使用 zstd 压缩：
- 确认 FCV 已设为目标版本：
db.adminCommand({setFeatureCompatibilityVersion: "8.3"})（注意：FCV 必须在升级二进制后、重建前调高） - 停写业务或切只读窗口，对每个需更新的集合执行：
db.runCommand({collMod: "collection_name", storageEngine: {wiredTiger: {collectionConfig: {blockCompressor: "zstd"}}}}) - 重建索引：
db.collection.dropIndexes(); db.collection.createIndex({...}, {background: true})—— 此时新索引文件才会用zstd写入
⚠️ 注意：collMod 不会重写已有数据文件，只影响后续新建/重建的文件。所以“重建”是必要动作，但前提是先改配置。
如何验证压缩是否生效
别只看配置项，要查实际文件行为：
- 用
db.collection.stats().wiredTiger查block-manager.compression字段，值应为zstd - 进入数据目录，用
wt工具检查文件头：wt -C "extensions=[./ext/compressors/zstd.so]" -h . read -r table:index-123--456.wt | head -20（需匹配对应压缩插件路径） - 监控压缩率变化：
db.serverStatus().wiredTiger.cache["bytes currently in cache"] / db.serverStatus().wiredTiger.cache["tracked dirty bytes"]在写入相同数据量时，zstd 下该比值通常更高
容易被忽略的一点：分片集群中，collMod 必须在每个分片上单独执行，mongos 不会自动广播该命令。
