为什么有些系统表被判定为“假表”？使用“TableIsFake”对象属性？

Question

我今天查看了 ObjectProperty 列表，发现了 TableIsFake 属性。这个名字让我很有趣，所以我查看了它检查的内容：

该表不是真实的。它由 SQL Server 根据需要在内部具体化。

这究竟意味着什么？例如，当我运行以下查询时：

SELECT [name], xtype
FROM dbo.sysobjects
WHERE OBJECTPROPERTY(object_id([name]), N'TableIsFake') = 1 
ORDER BY [name]

我得到以下结果：

name           xtype
-------------- -----
sysfiles       S 
sysforeignkeys S 
sysindexkeys   S 
sysmembers     S 
sysprotects    S 

但如果我查询数据库中的系统表：

SELECT [name], xtype
FROM dbo.sysobjects
WHERE xtype = 'S'
ORDER BY [name]

我得到以下系统表：

name                xtype
------------------- -----
syscolumns          S 
syscomments         S 
sysdepends          S 
sysfilegroups       S 
sysfiles            S 
sysfiles1           S 
sysforeignkeys      S 
sysfulltextcatalogs S 
sysfulltextnotify   S 
sysindexes          S 
sysindexkeys        S 
sysmembers          S 
sysobjects          S 
syspermissions      S 
sysproperties       S 
sysprotects         S 
sysreferences       S 
systypes            S 
sysusers            S 

是什么使得 sysfiles、sysforeignkeys< /code>、sysindexkeys、sysmembers、sysprotects 系统表“假”？或者换句话说，它们“由 SQL Server 根据需要在内部具体化”是什么意思？这是否意味着它们仅在进程需要时创建，或者如果我调用类似 SELECT * FROM sysfiles 的内容？

Answer 1

假表是一种特殊的“内存中”结构，没有磁盘持久性。 SQL Server 根据需要创建它。

最好的例子是 sysprocesses。

恕我直言：关键是“磁盘上的持久性”：

• sysusers 或 sysxlogins （例如）分别是每个 db/master 中的真实表，并且在备份/恢复中存活
• sysprocesses 或 sysfiles 将无法在备份/恢复中存活，因为没有任何内容可写入或读取到磁盘

Answer 2

sysfiles 表实际上是一个视图，其创建方式是为了向后兼容
请参阅将系统表映射到系统视图以了解您应该使用

什么您应该使用 sys.database_files 而不是 sysfiles