做 DBA 的朋友们，问你们一个灵魂拷问——你上一次半夜被告警叫起来重建索引是什么时候？
别不好意思，这几乎是每个 SQL Server 管理员的共同记忆。索引碎片化是个慢性病，不治的话查询越来越慢，治的话就得定期跑维护脚本，还要操心资源争用、窗口期够不够……
好消息是，微软终于出手了。Azure SQL 现在推出了 自动索引压缩（Automatic Index Compaction） 功能的公开预览版。一句话总结：以后索引碎片化这事儿，数据库自己搞定，你不用管了。 🎉
📌 这东西到底干了什么？
传统索引维护方式有两种：REBUILD（重建）和 REORGANIZE（重组）。它们都能解决碎片化问题，但都有代价——要么锁表、要么吃资源，而且你得自己写脚本、自己调度、自己监控。
自动索引压缩走了一条完全不同的路：
- 它是一个 后台持续运行的进程，不会像维护作业那样一次性大扫除
- 它只处理 最近被修改过的页面，而不是扫描整个索引
- 它会自动把半空的数据页合并、回收空闲空间
- 开销极低，对在线业务几乎没有感知
简单说，就像给数据库配了一个自动保洁员，不用你操心，它自己就把碎片收拾了。
🚀 开启方式：一条 SQL 就够了
不用装补丁，不用改配置文件，不用写 Agent Job：
ALTER DATABASE [你的数据库名] SET AUTOMATIC_INDEX_COMPACTION = ON;
就这一句，完事儿。
📊 效果有多猛？看数据说话
微软官方用 OLTP 压测场景做了对比测试，数据很能说明问题：
| 指标 | 工作负载前 | 工作负载后 | 自动压缩后 | |------|-----------|-----------|-----------| | 逻辑读次数 | 25 ✅ | 1,610 ❌（暴增60倍） | 35 ✅（降低98%） | | 页面密度 | 99.51% ✅ | 52.71% ❌ | 96.11% ✅ | | 数据页数 | 962 ✅ | 4,394 ❌（膨胀4.5倍） | 1,065 ✅ |
翻译成人话就是：
- 工作负载跑完后，因为大量 UPDATE/DELETE 操作和页分裂，索引膨胀严重，查询性能断崖式下降
- 自动压缩介入后，几分钟内就把页面密度从 52% 恢复到 96%，逻辑读降低了 98%，性能基本恢复到初始状态
- 全程零人工干预
对于持续运行的在线业务，这个功能是持续工作的——不是跑一次就完，而是一直在后台默默维护索引健康度。
🔍 哪些平台支持？
目前公开预览支持以下平台：
- ✅ Azure SQL Database
- ✅ Azure SQL Managed Instance（需开启 always-up-to-date 更新策略）
- ✅ Fabric 中的 SQL 数据库
💡 国内用户关心的问题
Q: 自建 SQL Server 能不能用？
目前这个功能是 Azure SQL 和 Fabric 专属的，自建 SQL Server 暂不支持。如果你还在用本地 SQL Server，还是得老老实实维护索引……或者考虑上云？😏
Q: 跟阿里云 RDS / 腾讯云 CDB 的自动优化比怎么样？
阿里云 RDS SQL Server 版和腾讯云 CDB 也有类似的自动空间回收和碎片整理能力。不过微软这次的做法更底层——直接在数据库引擎层面实现了持续压缩，而不是定时任务式的。具体效果差异还需要实测对比。
Q: 开了之后会不会影响业务？
根据官方描述，后台压缩进程只作用于最近修改的页面，资源开销远低于传统维护作业。但毕竟是预览版，建议先在非生产环境验证。
Q: 要不要马上开？
如果你用的是 Azure SQL Database 或 MI，且 workloads 写操作频繁导致索引碎片化严重——强烈建议开。一条命令的事，关掉也方便。预览期间免费体验，还有专门反馈渠道（sqlaicpreview@microsoft.com），有问题直接跟产品组沟通。
📝 小结
自动索引压缩可能是今年 Azure SQL 最实用的 DBA 友好功能。它解决的不是什么高大上的架构问题，而是每个 DBA 日常最烦琐的体力活——索引维护。
如果你正在管理 Azure SQL 实例，这条命令值得试试：
ALTER DATABASE CURRENT SET AUTOMATIC_INDEX_COMPACTION = ON;
原文链接：https://techcommunity.microsoft.com/t5/azure-sql-blog/stop-defragmenting-and-start-living-introducing-auto-index/ba-p/4500089 发布日期：2026-03-18
