直接结论：用 sys.dm_os_volume_stats 关联 sys.master_files 动态查各数据库文件所在卷的剩余空间，比依赖 xp_cmdshell 或 Windows 性能计数器更安全、免配置、权限要求低；但注意该 DMV 在 SQL Server 2012+ 才可用，且需 VIEW SERVER STATE 权限。
直接结论：用 sys.dm_os_volume_stats 关联 sys.master_files 动态查各数据库文件所在卷的剩余空间，比依赖 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去重聚合，避免同一磁盘被多个数据库文件重复统计 - 把
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)截断毫秒，导致后续按时间分组不准
为什么不能只靠 xp_fixeddrives 或 xp_cmdshell
xp_fixeddrives 只返回驱动器剩余空间（KB），没有总容量，无法算使用率；xp_cmdshell 虽能调用 fsutil 或 df 获取完整信息，但需开启高危扩展，且依赖 Windows 权限和路径配置，一旦权限收紧或路径变更就失效。
-
sys.dm_os_volume_stats是 SQL Server 原生 DMV，只要数据库在线、有VIEW SERVER STATE权限就能跑，不依赖外部命令或服务 - 但它只返回“有数据库文件挂载的卷”，如果某盘（如备份盘
E:\）没建任何数据库文件，就不会出现在结果里——这时得临时建个占位库（比如TEMP_BT），让 SQL Server “感知”到该卷 - 建占位库后记得设
AUTO_CLOSE = OFF和RECOVERY = SIMPLE，避免干扰事务日志和自动关闭行为
真正容易被忽略的是：即使你用了 sys.dm_os_volume_stats，也得确保所有目标卷上至少有一个在线数据库文件；否则监控表里永远缺那块盘。这不是 DMV 的 bug，而是设计使然——它只反映 SQL Server 实际使用的卷，不是操作系统意义上的“所有磁盘”。
