FILEGROUP_NAME是SQL Server中仅支持filegroup_id整数参数的名称查表函数，返回对应文件组名，无效ID时返回NULL；它不能直接查表所属文件组，正确方法需联查sys.tables、sys.indexes、sys.data_spaces和sys.filegroups。
FILEGROUP_NAME 不是标准 SQL 函数，它只存在于 Microsoft SQL Server 中，且必须传入有效的 filegroup_id 才能返回文件组名；直接对表查所属文件组不能靠它单干。
FILEGROUP_NAME 的真实用途和调用前提
这个函数本质是个“ID → 名称”的查表工具，不是“对象 → 所属文件组”的反向映射函数。它只接受一个整数参数：filegroup_id，返回对应文件组的名称（如 'PRIMARY' 或 'FG_Indexes'）。如果传入无效 ID（比如负数、超出范围、NULL），它返回 NULL，且不会报错——这点容易误判为“查到了空值”，其实是参数错了。
-
FILEGROUP_NAME(1)通常返回'PRIMARY'（但不绝对，取决于实际部署） - 没有内置办法用
FILEGROUP_NAME直接查某张表在哪个文件组上 - 它不支持对象名、schema 名或表名作为输入，传
FILEGROUP_NAME('Orders')会报错：参数类型不匹配
查表所属文件组的正确路径：JOIN sys.filegroups + sys.indexes + sys.partition_schemes
SQL Server 把表的文件组归属关系藏在索引层级里——堆表（无聚集索引）或聚集索引的存储位置决定了表的物理归属。所以得从 sys.indexes 入手，连到 sys.data_spaces（含文件组/分区方案信息），再连到 sys.filegroups 获取名称。
SELECT t.name AS table_name, i.type_desc AS index_type, fg.name AS filegroup_name FROM sys.tables t JOIN sys.indexes i ON t.object_id = i.object_id JOIN sys.data_spaces ds ON i.data_space_id = ds.data_space_id JOIN sys.filegroups fg ON ds.data_space_id = fg.data_space_id WHERE t.name = 'Orders';
- 注意：非聚集索引可能在不同文件组上，要加
AND i.index_id IN (0, 1)（0=堆，1=聚集索引）才能定位表主体所在 - 如果表启用了分区，
ds.type = 'PS'表示它是分区方案，此时fg.name会是NULL；得查sys.partition_schemes和sys.partition_functions -
sys.filegroups只包含磁盘文件组，不包含内存优化文件组（MEMORY_OPTIMIZED_DATA_FILEGROUP），后者需查sys.database_files的type_desc
FILEGROUP_NAME 在什么场景下真有用？
它适合配合系统视图做聚合统计，比如列出所有启用的文件组及其 ID，或者调试脚本中动态构造 DDL 时补全名称。
-- 查出所有文件组 ID 和名称映射 SELECT data_space_id AS filegroup_id, FILEGROUP_NAME(data_space_id) AS filegroup_name, type_desc FROM sys.data_spaces WHERE type = 'FG';
- 返回结果里
FILEGROUP_NAME(data_space_id)和name字段通常一致，但前者更安全——sys.data_spaces.name对分区方案也返回名称，而FILEGROUP_NAME()对非文件组 ID 返回NULL，可作类型过滤 - 不能用它替代
sys.filegroups.name，因为缺失权限时前者可能返回NULL而后者报错，行为不一致 - 在生成迁移脚本时，有人用它拼
ON [${FILEGROUP_NAME(id)}]，但必须先确认id确实指向文件组，否则生成的语句会语法错误
真正要查表在哪——别指望 FILEGROUP_NAME 单挑；它只是个名字翻译器，背后没存表和文件组的关联关系。漏掉 sys.indexes 这一层跳转，就永远查不到真实归属。
