sql server 2012+ 中可用 sys.dm_os_volume_stats 关联 sys.master_files 动态获取各数据库文件所在卷的总空间、可用空间及使用率，需 view server state 权限，排除系统库并去重 volume_mount_point，结果宜插入监控表供告警消费。
直接结论：SQL Server 里用 sys.dm_os_volume_stats + sp_executesql 动态查各数据库文件所在卷的剩余空间，比依赖 xp_cmdshell 或 Windows 性能计数器更安全、免配置、权限要求低；但注意该 DMV 在 SQL Server 2012+ 才可用，且需 VIEW SERVER STATE 权限。
怎么用 sys.dm_os_volume_stats 获取磁盘剩余空间
这个 DMV 不查 Windows 层面的全盘信息，而是返回每个数据库文件（.mdf、.ldf）所在卷的总空间、可用空间、文件系统类型等。关键点是：它不接受数据库名或文件名作为参数，必须传入 database_id 和 file_id —— 所以得先从 sys.master_files 关联查出所有在线数据库的主数据文件和日志文件。
实操建议：
- 用
SELECT DISTINCT volume_mount_point, total_bytes, available_bytes FROM sys.dm_os_volume_stats(database_id, file_id)去重聚合，避免同一磁盘被多个数据库文件重复统计 - 把
available_bytes转成 GB（除以 1024.0/1024/1024），并计算使用率：(total_bytes - available_bytes) * 100.0 / total_bytes - 加
WHERE database_id > 4排除系统库（master、model、msdb、tempdb），除非你真要监控它们
存储过程里怎么动态覆盖所有数据库文件
不能硬写死 database_id，因为新库上线后不会自动进存储过程逻辑。必须用游标或 STRING_AGG（SQL Server 2017+）拼接查询，但更轻量的做法是用 CURSOR 遍历 sys.master_files，对每个 (database_id, file_id) 调用 sys.dm_os_volume_stats —— 注意：该 DMV 对每个参数组合执行一次，频繁调用有轻微开销，但日常每小时跑一次完全没问题。
常见错误现象：
- 漏加
WHERE state_desc = 'ONLINE'，导致查到离线库的文件，sys.dm_os_volume_stats返回 NULL - 没处理
tempdb的file_id = 1（数据）和file_id = 2（日志）分别对应不同卷，但实际常在同卷 —— 去重时靠volume_mount_point即可，不用按file_id拆 - 用
GETDATE()记录时间但没用datetime2(0)截断毫秒，导致后续按时间分组不准
怎么让结果能被告警程序消费
别只 SELECT 然后看 SSMS 输出。生产环境需要结构化输出，比如返回带列名的结果集，或插入到监控表供外部轮询。推荐建一张 DBA_DiskSpaceHistory 表，字段包括：volume_mount_point、used_percent、available_gb、capture_time。
实操建议：
- 存储过程末尾加
INSERT INTO DBA_DiskSpaceHistory SELECT ...，再加DELETE FROM DBA_DiskSpaceHistory WHERE capture_time 控制历史长度 - 如果下游用 PowerShell 或 Python 告警，存储过程开头加
SET NOCOUNT ON，避免触发行计数消息干扰解析 - 阈值判断放应用层，不要在存储过程中
RAISERROR—— 同一磁盘可能被多个库共用，告警策略（比如连续3次超90%才发）应由调度器控制
真正容易被忽略的是 tempdb 文件路径变更后，sys.dm_os_volume_stats 不会自动刷新缓存 —— 它每次都是实时读取 Windows API，所以只要 SQL Server 服务账户对目标卷有读取权限，就一定准；但如果磁盘是网络映射驱动器（如 Z:），该 DMV 可能返回 0，此时得换用 xp_cmdshell 调用 df 或 dir，但那是另一套权限和安全模型了。
