SELECT A.FILE_ID, A.name,A.size,b.size
FROM tempdb.sys.database_files b
join sys.master_files A WITH(NOLOCK)
on A.name = b.name and A.size<>b.size
where db_name(database_id) in ('tempdb') 执行结果详细如下：
FILE_ID name size size
2 templog 131528 2064328
3 tempdev01 131072 17910272
4 tempdev02 131072 8950272sys.database_files 和sys.master_files 两个视图中字段size的定义是一样的，并且
查询其他数据库就不会出现size的值不一致的情况，有谁知道哦啊这是为什么，tempdb特殊吗？tempdb database_filesmaster_files数据库SQL
注意：
在删除或重新生成大型索引时，或者在删除或截断大型表时，数据库引擎 将延迟实际页释放及其关联锁，直至事务提交完毕为止。延迟的删除操作不会立即释放已分配的空间。因此，在删除或截断大型对象后由 sys.database_files 立即返回的值可能不反映实际可用的磁盘空间。有关延迟分配的详细信息，请参阅删除并重新生成大型对象。
在删除或重新生成大型索引时，或者在删除或截断大型表时，数据库引擎将延迟实际页释放及其关联锁，直至事务提交完毕为止。延迟的删除操作不会立即释放已分配的空间。因此，在删除或截断大型对象后由 sys.database_files（sys.master_files） 立即返回的值可能不反映实际可用的磁盘空间。有关延迟分配的详细信息，请参阅删除并重新生成大型对象。
当删除或重新生成大型索引时，或者当删除或截断大型表时，SQL Server 2005 数据库引擎将推迟实际的页释放及其关联的锁，直到提交事务后再执行。此实现方法支持多用户环境中的自动提交事务和显式事务，并适用于使用 128 个以上的区的大型表和索引。通过将删除大型对象过程分为以下两个单独的阶段，数据库引擎避免了此过程所需的分配锁：逻辑阶段和物理阶段。在逻辑阶段，将把表或索引使用的现有分配单元标记为释放，并在提交事务之前使它们保持锁定。删除某个聚集索引后，将复制数据行并将它们移到新创建的、用来存储重新生成的聚集索引或堆的分配单元。（在重新生成索引的情况下，还会对数据行进行排序。）如果存在回滚，则只需回滚此逻辑阶段。提交事务后，将发生物理阶段。在此阶段将以物理方式成批删除被标记为释放的分配单元。这些删除操作是在后台中发生的短事务内执行的，不需要许多锁。
由于物理阶段发生在提交事务之后，因此表或索引的存储空间仍显示为不可用。如果在完成物理阶段之前需要使用此空间来扩充数据库，数据库引擎将尝试从标记为释放的分配单元恢复空间。若要查找这些分配单元当前使用的空间，请使用 sys.allocation_units 目录视图。推迟的删除操作不会立即释放已分配的空间，并会在 数据库引擎中带来额外的开销。因此，将删除、截断和重新生成使用 128 或更少的区的表和索引，就像在 SQL Server 2000 中一样。这意味着逻辑阶段和物理阶段都会在提交事务之前发生。但问题是查处来的size的值为什么不一样？？我重新启动数据库，tempdb释放空间后，运行一些作业，重新查询，两个值又是一样的？
还有就是既然这两个sys.database_files和sys.master_files都不能反映真是的实际可用的磁盘空间，那这两个视图还有什么参考价值，直接废弃得了查哪个视图才能获得真实的空间呢？