SDSS DR20 — 三百万条光谱与它背后的查询边界

斯隆数字巡天从 1998 年 5 月第一次开光起，用一种近乎固执的方式反复拍摄同一片天空：先用一台广角相机把五分之一的天区拍成五波段底图，再把光纤一根根插到选定天体的位置上，让它们的光同时进入光谱仪。二十八年之后，这套流程的产出被压缩成第二十次数据发布，2026 年 7 月 30 日上线。它包含 2,767 万条光谱、4.69 亿个唯一的测光天体，以及 169 幅来自新一代积分视场仪器的拼块。

这次发布最容易被误读的地方，是它看起来像一个「又一个巡天版本」。实际上，从第四代到第五代之间，SDSS 的产出结构换过一次骨架：成像不再增加，光学光谱上了一个数量级，而红外光谱这一次原地不动。发布页把这一层说得相当直白，但版本号连续排列的惯性会让人以为一切都在增长。

下面的速览把最该先知道的数字与口径排在一起，后面各章再逐项展开。

项目	数值	口径与来源
发布日	2026-07-30	官方新闻页四条同日公告
所属代际	SDSS-V 第三次发布	DR20 数据访问页
累计光谱条目	27,671,504	allspec v1.0.2 汇总表
其中光学光谱	23,046,726	同上
其中红外光谱	4,613,505	同上，沿用 DR19 未更新
SDSS-V 拼块	169	LVM 六个目标区
唯一测光天体	469,050,976	PhotoPrimary
测光检出记录	794,328,715	PhotoObj
SDSS-V 光谱表行数	5,357,037	spAll
增值星表	18 份	官方 What’s New 页
取数主路径	SkyServer SQL 接口	匿名可用，无需注册
许可状态	开放访问，未声明 SPDX	致谢模板与技术论文引用为硬要求
光谱归档截止	2025-02-02	数据访问页

§1 速览：它是什么，也不是什么

1.1 一句话定义

SDSS DR20 是一份按「一次观测」而不是「一个天体」来组织行的多产品光谱档案，外加一张自 2018 年起就没再增行的测光底表；它把二十八年里南北两座天文台、三代光谱仪、上千个观测夜的结果，统一到一套可以写 SQL 查询的关系型数据库里。

它不是一份可以下载下来解压就用的机器学习数据集。全量文件以科学归档服务器上的 FITS 树状目录形式存在，量级远超单机存储；实际工作方式是在服务端用 SQL 把需要的子集捞出来，去取少的那些行，而不是把全部搬回本地。

1.2 为什么它不像「普通星表」

把 SDSS DR20 当成一张普通星表，会在三处栽跟头，而这三点恰好是它区别于一般天文数据集的原因。

第一，同一份数据有多个名字。数据库里叫「测光天体」的东西有三份：PhotoObj、PhotoObjAll、PhotoPrimary。三者行数分别是 7.94 亿、12.31 亿与 4.69 亿。它们不是三个不同的天体样本，而是同一批观测在三种去重规则下的投影。选哪一个，直接决定「天体数」是接近五亿还是接近十三亿。

第二，「行」的单位随表而变。测光侧一行是一次检出，光谱侧一行是一次曝光或若干曝光的合并，SDSS-V 侧一行是某个星场某个夜晚的每日合并。跨表做任何计数之前，先要问清楚这张表的行代表什么时间尺度。同一个物理天体在 spAll 里出现的次数，取决于它在几个夜晚被观测过。

第三，版本内部并不齐步走。DR20 的光学光谱更新到 2025 年 2 月，红外光谱却是 DR19 的原样拷贝，测光基表更是自 DR18 起完全没动。一次发布之内，三块内容的「新鲜度」可以相差七年。引用时若笼统写「DR20 的数据」，实际指哪一块并不明确。

1.3 三十秒决策卡：你的处境，它能帮你什么

你手上要解决的问题	它能给你什么
训练一个从光谱到物理量的回归模型	530 万条 SDSS-V 光学光谱，含逐条信噪比与红移拟合质量位
做跨星表的实体匹配练习	同一批天体的测光行、老光谱行、SDSS-V 行三套编号并存
需要一个五波段测光的标准底图	4.69 亿个唯一天体，u/g/r/i/z 齐备，缺测以哨兵值标记
研究黑洞吸积的多历元变化	黑洞映射项目的重复观测，光学光谱跨多个夜晚
需要一个「大表 SQL 优化」的真实题目	七亿行基表配十余个预计算视图，选错视图就是数倍代价
想一次性下载全库做离线训练	不现实，见 §5；必须走分区查询或服务端计算
想要一份明确的商业可用许可	给不了，官方未声明 SPDX 许可，见 §8

这张表的每一行都对应一个具体动作，而不是一句宣传。读它的正确方式是反过来用：先在自己的需求里找到最像的那一行，再看右列给出的条件能不能满足。如果某一行的条件在项目里无法满足，那么换一个数据源通常比勉强凑合更省时间。

1.4 不适合谁

如果需求是高分辨率成像，这份发布不提供新增内容。成像部分沿用 SDSS 广角相机在 2009 年结束的旧成果，像素尺度约 0.396 角秒。想要更深的成像底图，要去看其他巡天的叠加产品。

如果需求是逐历元光变曲线，主表没有。测光侧的 PhotoObj 虽然按观测区段拆成多行，但那是「同一片天空被不同次扫描」的痕迹，不是对同一颗天体做的定期监测，行与行之间的时间间隔由扫描计划决定，不由科学目标决定。真正的时序来自 SDSS-V 的重复光谱，且只覆盖被专门立项的目标。

如果需求是红外观测，要先看日期。APOGEE 数据是上一代发布的原样拷贝，官方明确写了这一次不含新的红外光谱、也不含对既有红外光谱的重新分析，这批内容要等下一次发布。

如果需求是明确的开放许可，官方页面给不出协议名。能核实的只有致谢模板与论文引用清单，把它们当作使用条件比当作许可条款更贴近实际。

如果需求是小而干净、开箱即用的标注集，要接受一件事：这份数据的每一张表都带着哨兵值与质量位，清洗逻辑必须自己写。官方提供的是规范，不是已经清洗好的成品。

1.5 贯穿本文的案例：为黑洞映射项目挑选可信红移样本

后面的章节会反复回到一个具体任务上：某支团队要为一个「用类星体光谱做红移估计」的模型准备训练集，数据源锁定在 SDSS-V 的黑洞映射项目。

这个任务看上去简单：拿到所有类星体光谱，取红移标签，切分训练与验证。它的每一个看似无害的步骤，都会撞上这份发布的结构性特征——用哪张表、按哪个键去重、红移有多可信、坐标从哪里取、怎么把数据取出来、用什么话写致谢。下面各节的每个选择点，都会回到这个任务上说明后果。

§2 数据构成：一次发布里装着四代产品

2.1 全量规模的两种口径

官方给出的规模有两套口径，差别不在误差，而在「数什么」。

第一套按目标天体数。官方口径是：光谱覆盖超过四百万颗恒星、三百万个星系、两百万个类星体。这三个数字按巡天代际拆开列在一张三行表里，是理解 SDSS 二十年积累最直观的一张表。恒星一栏分光学与红外两列，因为近红外光谱是另一台仪器、另一条管线。

第二套按光谱条目数，也就是实际交付的「一张光谱」有多少。这一套的总数是 2,767 万，同样按代际拆开。官方特意提示：这张表同时收录单次曝光的原始光谱与由它们合并出的条目，因此存在重复计数，同一次曝光既是独立条目、又被算进了它参与合并出的那条光谱里。

两套口径的差别可以用一句话概括：前者问「多少个天体被观测过」，后者问「多少份光谱文件被交付」。做数据集统计时用第一套，做存储规划时用第二套。

把三行表读细一点，还能看出代际之间的结构变化。第一代与第二代合起来贡献约一百六十五万个天体目标与一百八十四万条光谱，光谱条目略多于天体目标，因为同一目标被重复观测的次数不多。第三代与第四代合起来贡献约四百一十六万个天体目标与七百三十六万条光谱，条目比目标多了八成，因为这一阶段的巡天设计就包含重复曝光以提高信噪比。第五代单独一代就贡献约三百七十九万个天体目标与一千八百四十七万条光谱，条目与目标的比值接近五，因为多历元重复观测是这一代的核心设计——黑洞映射要追踪吸积变化，银河系映射要测双星与变星，重复是方法本身而不是手段。

这个比值的变化，是理解这份发布最有用的一条线索。它解释了为什么「天体数只涨了三成，光谱条目涨了六倍」会同时写在同一份材料里——两个数字都没有错，它们描述的是同一件事的两面：观测策略从「尽量多看不同的东西」转向「对更少的东西看得更久」。

2.2 SDSS-V 在这次发布里贡献了什么

官方 What’s New 页把新增内容列成一份清单，其中与数据规模直接相关的有五条。

其一是光学光谱的主角化。黑洞映射项目贡献约五十万条星系与类星体的光学光谱，其中首次包含来自南半球的、与 X 射线源星表协调观测的目标。银河系映射项目贡献约一百五十万颗恒星的光学光谱，同样首次包含南天恒星。

其二是南天首束。拉斯坎帕纳斯天文台的 BOSS 光谱仪在杜邦望远镜上投入使用，这是 SDSS 历史上第一次把多目标光纤光谱搬到南半球。两座台址的合流是这次发布在结构上最实质的变化。

其三是增值星表。十八份由科学团队整理的产品，涵盖恒星参数、丰度、径向速度等派生量。

其四是本地宇宙映射的 169 幅拼块，覆盖六个目标区，官方措辞是「为未来的发布做预览」。这 169 幅拼块对应的约三十万条光谱不计入目标天体总数，因为它们测绘的是延展区域，不是点目标。

其五是意外目标的首次纳入。官方把这一条单独列出，说明它此前从未出现在公开数据里。它的机制是：当某个突发天体出现时，望远镜临时改换观测计划去拍它，这类观测不遵循预先设计的目标清单，因此过去的发布流程无法容纳。这一次把它纳入了正式产品线。

其五是可视化工具的更新，其中一项新工具专门用于浏览积分视场数据，并附带一张全天空发射线强度的层级图产品。

2.3 频谱的两个层次：老表与新表

数据库里并存着两套光谱表，它们在物理含义上并不等价。

SpecObj 是 SDSS-I 到 SDSS-IV 时代的汇总视图，5,112,724 行。它的字段体系成熟，包含红移、误差、质量位、分类、子分类、速度弥散、逐波段的信噪比中位数，以及与测光对象关联的键。这张表里能查到的最早记录来自 DR7 时代，最新的是 DR17 时代的数据。

spAll 是 SDSS-V 的每日合并光谱表，5,357,037 行。它的字段更多地面向观测管理：观测星场的编号、曝光夜、曝光次数、总曝光时长、光纤编号列表、参与合并的配置编号，以及一整组来自测光与外部星表的前置星等。它还带一列 sdss_id，这是 SDSS-V 跨仪器、跨白天体的统一标识。

两张表的关系值得说清楚：它们在时间上不重叠，SpecObj 停在第四代，spAll 起于第五代。想把两代光谱合并成一个训练集，必须自己定义统一的特征集，因为两张表的同名列含义并不总是一致。

一个具体的例子足以说明这件事有多麻烦。z 这个列名在两张表里都有，含义也确实是红移，但来源不同：老表里的值来自 BOSS 管线对单条合并光谱的模板拟合，新表里的值来自第五代管线对当日全部曝光的合并结果。两者的模板库版本、拟合自由度、警告位的编码方式都不保证相同。把它们直接拼起来做回归，等于假设两套管线的系统偏差为零——这个假设没有任何官方材料支持。

更麻烦的是 subClass。老表里它是字符串，取值随巡天阶段而变（不同阶段的分类词表不统一）；新表里更细的分类信息并不落在这一个列上，而是分散在若干目标选择标志与增值星表里。想做统一的类别标签，必须从两个方向各自归一化，而不是简单地取同名列。

2.4 哪些表在这次发布里没有变

这是阅读 DR20 时最容易漏掉的一段。发布首页用一个小标题直接讲明：这一次没有新的近红外光谱，也没有对既有近红外光谱的重新分析；上一代的红外数据被原样拷进这一代的目录，目的是把最新的公开数据集中到一处。官方同时预告，下一次发布才会给出南天台址的第一批近红外光谱以及更新后的分析管线结果。

测光侧同理。测光检出表的 794,328,715 行与老光谱表的 5,112,724 行，与上一代发布完全一致，因为它们记录的观测早已结束，重新发布不会改变行数。任何一个把这些数字当作「本次新增」的说法，都在把累计量误读成增量。

这条边界对使用者有非常实际的含义：如果你的项目只关心近红外光谱，那么这一次发布的文件树对你而言没有任何新信息，直接沿用上一代即可，唯一的变化是目录前缀。如果你的项目关心光学光谱，那么这一次发布是必须升级的，因为南天数据只在这里。混在一起规划「要不要迁移到新版」容易得出错误的结论。

2.5 一行记录到底代表什么

回到 §1.5 的案例。团队要提取类星体光谱，第一件要决定的事是：从哪张表取。

如果他们取 SpecObj，拿到的是第四代及更早的光学光谱，其中 class 为类星体的有 1,105,286 条。这些光谱的红移标签来自旧版管线，与第五代的管线版本不同。

如果他们取 spAll，拿到的是第五代光谱，按目标项目分组。黑洞映射项目在 spAll 中有 1,054,228 行，银河系映射项目 1,835,963 行，运维与开放光纤两个项目合计约 240 万行，调试期约 5 万行。这些行里既有真正的科学目标，也有用于定标的天空光纤与校准目标——programname 里带 sky 字样的行就是一例。

两组数字量级相近但含义完全不同：前者是「有多少条类星体光谱」，后者是「某个科学项目的全部光谱行，含非类星体」。混用会让训练集里混进大量定标用的天空光谱，而天空光谱的红移拟合结果毫无物理意义，只是管线对噪声的强行解释。

审阅上面四个数字还能发现一个常被忽略的事实：spAll 的 5,357,037 行里，真正属于两个科学目标项目的是 2,890,191 行，占一半多一点。剩下的一半是运维、定标、调试与开放光纤。任何「第五代有多少条科学光谱」的陈述，都必须先把这一半剔掉。

§3 标识层：三套编号与它们各自的用途

3.1 测光侧的键：objID

objID 是测光对象的编号，64 位整数。它在 PhotoObj 与 PhotoPrimary 中唯一，是测光侧唯一可靠的连接键。

这个编号的构成方式决定了它不能被当作无序的随机数使用：它编码了该对象所在的天空区段、相机列与视场，以及在该视场内的像素位置。因此在 objID 上排序，等价于按天空位置排序。如果按这个顺序切分训练集与验证集，切出来的两半在地理上是分开的，模型学到的会包含天区特有的系统误差。

对 §1.5 的案例来说，这意味着不能用 objID 排序后取前百分之八十做训练，而要在天球坐标上做分组。这个坑在别的星表里并不显眼，因为多数星表的主键是随机分配的。

3.2 光谱侧的老键：specObjID 与 bestObjID

SpecObj 的主键是 specObjID，同时还有三个指向测光对象的指针：bestObjID、fluxObjID、targetObjID。三者语义不同，最常被误用的是把 targetObjID 当作「这条光谱对应哪个测光对象」。

bestObjID 才是「最佳匹配的测光对象」，它把光谱位置映射到测光表里位置最接近的那个主检出。官方示例查询里几乎都用 s.bestObjID = p.objID 这个连接条件。用错指针会导致一部分光谱连不上测光行，或者在多检出区域连到错误的行上。

SpecObjAll 是 SpecObj 的超集（5,801,200 行），包含了被分类为「不主用」的重复导星观测。做天体统计用 SpecObj，做「有哪些光谱被拍到过」用 SpecObjAll。

3.3 SDSS-V 侧的新键：sdss_id

第五代引入了一套新编号。spAll 里的 catalogid 与 specobjid 都是 SDSS-V 体系内的数，其中 specobjid 是一串拼接出来的长度可变的数字，不能与其他表的 specObjID 直接比较。

真正把第五代与外部世界连起来的是 sdss_id。官方为其单独准备了说明页，它的设计目标是把同一目标在不同仪器、不同波段、不同观测次数下的记录归到同一个标识下。在 spAll 的 5,357,037 行中，sdss_id 全部非空。

对新老两代都要用的项目，可行的桥接方式只有两种：一是通过位置做球面匹配，二是通过项目自带的交叉匹配星表。没有一把现成的键可以直接把两代光谱联起来。

这带来的成本是可以量化的。球面匹配需要一个容差，而容差的选取是个两难：放得松，密集星场里会有一对多；收得紧，本身位置误差稍大的目标就会漏配。第五代的位置精度取决于目标在光纤上的对准情况，与老一代的光纤插板方式不同，两者把同一个容差用在两边，混淆率不可能一致。

交叉匹配星表倒是现成的，但它的口径由星表编制者决定，不是由使用者决定。用它做桥接，等于把别人的匹配规则接受为自己的匹配规则，而这条规则未必对当前任务成立。

3.4 用错键的代价

仍以 §1.5 的案例为例。团队想统计「黑洞映射里有多少个不重复的类星体目标」，最直观的写法是对 spAll 按该项目的标识过滤后数 catalogid 的去重数。这个数字会接近官方口径的「约五十万个目标」，因为 catalogid 在设计上就是每个目标一个编号，重复观测不会改变它。

但如果误用了 specobjid，每一条光谱都会被算成一个独立目标。黑洞映射在这一次发布里的光谱条目是目标数的两倍多，于是「有多少个目标」会被误报成「有多少条光谱」。

反过来，如果目标是「有多少条可用光谱」，那就必须数行而不是数去重目标。同一个字段，数行与数去重之间差的是观测策略。

还有第三种错误更隐蔽：拿 sdss_id 去对老表的 objID。两者都是大整数，位数相近，看起来像同一个体系。它们不是。跨代联表只能走位置，见本节开头。

§4 结构层：视图、基表与选错的代价

4.1 三张测光表的行数关系

数据库里有三张名字接近的测光表，行数如下。

表	行数	含义
PhotoObjAll	1,231,051,050	全部检出，含各类特殊模式对象
PhotoObj	794,328,715	标准检出，去掉了部分特殊处理对象
PhotoPrimary	469,050,976	每个天体的唯一主检出
PhotoTag	1,231,051,050	与 PhotoObjAll 同行数，但列更少、查询更快

这四条线之间的关系是层层收窄：最宽的一张含所有被相机记录下来的东西，中间一张去掉特殊对象，最窄的一张只留每个天体的代表行。PhotoTag 不是第四种对象，而是最宽那张表的精简投影，官方文档明确建议用它替代 PhotoObjAll 做探索性查询，因为它列少、索引更友好。

从最宽到最窄，被去掉的是两类东西。一类是特殊处理模式下的对象，例如被拆开重新拟合的复合源、被标记为疑似伪影的检出。另一类是重复扫描产生的副本：同一片天区在不同观测夜被扫过时，每一次都会产生独立的检出行，PhotoPrimary 只在其中选一次。

选哪一次不是随机的。官方用若干条判据（在足迹内的位置、图像质量标记、是否与其他观测冲突）决定主检出，这意味着不同扫描之间的质量差异已经被这套规则吸收了一部分，但不可能完全吸收。如果项目对图像质量极其敏感，只看 PhotoPrimary 会丢掉「另一个扫描里其实有更好的测量」这种情况。

对规模判断最直接的影响是：说「SDSS 有七亿九千万个天体」与说「SDSS 有十二亿个天体」用的是不同口径，而只有 4.69 亿这个数是「天体数」。三个数字都没有错，错的只是把它们互换。

4.2 分类视图与它们的加总关系

Star 与 Galaxy 是按形态分类预先筛好的视图，分别 260,562,240 行与 208,476,804 行。二者相加是 469,039,044，比 PhotoPrimary 少 11,932 行。这个差额不是错误，而是还有第三类对象没有被这两个视图收录——在唯一天体表里，另有一批行被标为「无法归类」。

这意味着一个常见写法会得到略微偏小的总数：用两张分类视图的计数相加，当作「银河系内外的天体总数」。差额一万一千九百多行，占比极低，但它说明这两个视图不是完全划分，而是互斥但不穷尽。

这一万多个无法归类的对象在物理上是什么？它们绝大多数是形态介于点源与延展源之间的模糊目标：足够暗、足够小、信噪比又不足以判定。少数是紧邻亮星的伪影。

对 §1.5 的案例，如果团队要做类星体与恒星的二分类，而单纯用这两个视图构建正负样本，就需要额外处理这批未归类对象，否则它们会在训练与验证之间制造标签缺口。更实际的做法是：不要依赖这两个视图，而是从唯一天体表出发，用形态分类标志自己划界，并且把边界处的对象显式标记为「不确定」。

4.3 预连接视图：省一次 JOIN 的代价

官方示例里反复推荐用 SpecPhoto 而不是自己写光谱表与测光表的连接。这张视图把两张表的关键列预先连好，行数 4,618,753。

它与主用光谱表不是同一行数的原因很直接：连接条件是「光谱能匹配到测光主检出」，而有一部分光谱没有匹配对象——例如只在光谱表里存在的校准目标、或者落在测光足迹之外的方向。于是它的行数比主用光谱表少约五十万。

这个差额本身就是一个信息：如果你用它做光谱统计，会系统性地丢掉那五十万条没有测光对应的光谱。对以测光为特征的模型这无所谓，对「完整光谱清单」这种需求就是硬伤。

还有一个更细的差别值得注意：即便是在这张视图内部，一条光谱也只连到一个测光对象。如果某条光谱的纤维落在两个测光主的交界处，这种一对多的情形会被强行压成一对一的。做需要精确对应关系的任务时（例如把光谱通量与测光星等做定标），这个压缩会引入误差。

4.4 两层的本质：基表与投影

把上面几节合起来看，SDSS 的数据库设计是一套标准的「基表 + 派生视图」结构。

基表记录原始检出与原始光谱，字段多、行数大、随观测不断追加。派生视图按不同用途做过滤与预连接：去重的、分类型的、连好测光的、精简列的。视图不增加信息，只改变组织方式。

因此「用错视图会重复计数」这句话的准确含义是：基表里同一物理对象的多条检出是真实存在的行，视图的职责就是决定保留哪一条。绕开视图直接用基表，等于放弃这层去重逻辑。

4.5 缓存与索引的现实约束

官方文档对性能的提示相当具体：示例查询普遍带 TOP n，并反复警告去掉它「可能超时」；建议用预计算好的位掩码常量替代逐行调用位函数；建议用空间索引函数做随机采样而不是 ORDER BY 随机排序。

这些提示背后的现实是：一次查询有服务端时限，跨七亿行的全表扫描无法在时限内完成。所有大查询都必须先做空间或属性上的分区，把扫描范围压下来。§5 会给出具体的分区写法。

§5 取数层：SQL 是主路，文件树是旁路

5.1 为什么没有「下载全库」这个选项

先看体量。仅测光基表 PhotoObj 就有 7.94 亿行，光谱合并后 2,767 万条，再加上 SDSS-V 的每日合并、逐次曝光、积分视场立方，全量已远超单机磁盘可以容纳的范围。官方没有提供「整包下载」的入口，提供的是三条各有分工的通道。

再补一层：即便磁盘放得下，逐条光谱的像素也比派生的星表大两到三个数量级。一条光学光谱约两千个波长采样的通量、误差与掩码，文件体积在数十千字节到数百千字节之间；两千万条的量级对应的就是若干 TB。而积分视场立方的每条数据不是一维光谱，而是三维数据块——两个空间维加一个波长维，单个目标的立方就可达数百 MB。

因此「先下全库再说」在这个数据集上不是习惯问题，而是不可行。可行的做法只有两种：要么先想清楚要哪些行，再用查询把行圈出来；要么把计算搬到数据旁边。

第一条是 SkyServer 的 SQL 接口，即关系型数据库的网页查询入口。它返回表格，支持把结果以 CSV、JSON、XML、VOTable、FITS 等格式导出，匿名使用、无需注册。这是绝大多数人实际的取数方式。

第二条是 科学归档服务器的文件树，即按产品类型组织的 FITS 目录。它适合按文件批量取，例如「把所有 SDSS-V 光学光谱的汇总星表取下来」，这个文件约 985 MB，一条命令即可。同一目录下还有按星场历元合并的版本（约 891 MB）与全历元合并的版本（约 95 MB）——三份汇总表的行数关系正是 §2.5 讨论的那件事的另一种表现。

第三条是 服务端计算环境，把 Notebook 跑在数据所在的数据中心，数据不出机房。它适合需要遍历大量文件又不想传输的场景。

三条通道之间还有一条不成文的搭配规律：用最窄的通道做筛选，用最宽的通道取内容。筛选阶段只需要星表，走 SQL 最快；取内容阶段需要像素，走文件树或服务端。反过来做，就会在筛选阶段下载大量用不上的像素，或者在取内容阶段反复查询已经确定的清单。

5.2 SQL 接口的实际形态

接口是一个网页表单，提交后返回结果表。要把它接进脚本，需要按表单的实际字段提交。

一个可以直接运行的批量查询封装如下，它抓取会话令牌、按表单要求提交，并返回 CSV 风格的表：

#!/bin/bash
## 用法: ./sdss_query.sh "SELECT COUNT(*) AS n FROM PhotoPrimary"
BASE="https://skyserver.sdss.org/dr20"
JAR=$(mktemp)
TOK=$(curl -s -m 60 -c "$JAR" -b "$JAR" \
  "$BASE/en/tools/search/sql.aspx" \
  | grep -o '__RequestVerificationToken" type="hidden" value="[^"]*"' \
  | head -1 | sed 's/.*value="//;s/"$//')

curl -s -m 300 -c "$JAR" -b "$JAR" -X POST "$BASE/SearchTools/sql" \
  -H "Referer: $BASE/en/tools/search/sql.aspx" \
  --data-urlencode "__RequestVerificationToken=$TOK" \
  --data-urlencode "searchtool=SQL" \
  --data-urlencode "TaskName=Skyserver.Search.SQL" \
  --data-urlencode "syntax=NoSyntax" \
  --data-urlencode "ReturnHtml=true" \
  --data-urlencode "TableName=" \
  --data-urlencode "format=CSV" \
  --data-urlencode "cmd=$1"

rm -f "$JAR"

这段脚本有两个与直觉相反的细节，值得说明。其一，查询语句放在名为 cmd 的字段里提交，而不是任何叫 query 的字段；表单里虽然有一个 cmd 的隐藏输入，但真正承载 SQL 的也是这个名字。其二，syntax 的取值要用 NoSyntax，与直觉里的 SQL 不同。表单的提交按钮会把语法字段覆写成这两个值之一，脚本照抄按钮的行为即可。

返回体不是纯 CSV，而是带一行 #Table1 前缀的小段文本，解析时跳过首行即可。

5.3 分区查询的写法

查询时限决定了所有大的统计都必须先分区。两条可用的分区维度是空间与属性。

空间分区用天球坐标做区间裁剪。下面这条统计一个三十度乘十度天区在测光主表里有多少天体，单次返回约需数十秒：

SELECT COUNT(*) AS n
FROM PhotoPrimary
WHERE ra BETWEEN 170 AND 200
  AND dec BETWEEN -5 AND 5

这条查询在 PhotoPrimary 上返回 6,868,863 行；同样的条件在 PhotoObj 上返回 10,274,367 行。同一片天空，两个口径差出五成，这正是 §4.1 讲的多重检出在计数上的体现。

这两个数字并列还有一个教学作用：它给出了一次「选错视图」的实物样本。如果你的任务是「估算这片天区有多少个天体」，用第二张表会高估五成，而查询不会报错，结果也完全合理——它是一个真实存在、只是含义不同的数。

分区查询的写法有几条经验规则。窗口不要开得太大，赤经差三十六度、赤纬差十度已经是单次查询能顺利返回的舒适区间。分区之间要有重叠或留缝，取决于任务：做普查要无缝拼接，做不重复抽样要有边界处理。分区的形状最好与数据在数据库里的物理组织方式一致，也就是按观测区段切，而不是按任意经纬度矩形切。

属性分区按分类或星等区间切。下面的写法把结果分批取回，适合需要几千到几万行的抽样任务：

SELECT TOP 1000 objID, ra, dec, u, g, r, i, z
FROM PhotoPrimary
WHERE g BETWEEN 16 AND 18

5.4 文件树的旁路价值

SQL 接口解决的是「星表级」的需求，文件树解决的是「像素级」的需求。光谱的逐像素通量、积分视场立方的每个体素、成像的每个像素，都不在数据库里，只在 FITS 文件里。

两者之间靠文件名里的字段衔接。SDSS-V 光学的单条光谱文件命名是 spec-星场-曝光夜-目标编号.fits，数据库里对应的就是 field、mjd、catalogid 三列。老一代的命名是 spec-板号-曝光夜-光纤号.fits，对应 plate、mjd、fiberID。用不同的键去拼文件名，会拼出不存在的路径。

对 §1.5 的案例，这条路径的意义在于：如果模型要直接吃原始光谱像素而不是红移标签，那么数据库只负责选出目标清单，真正的取数是在文件树上逐文件下载。从「一条 SQL」变成「一个带队列与断点续传的下载工程」。

5.5 三条路径的代价对照

路径	适合	主要约束
SkyServer SQL	星表级筛选、抽样、统计	单次查询有时限，须分区
归档文件树	逐条光谱、立体立方、成像像素	需自建清单与下载队列
服务端计算	遍历大量文件	依赖平台提供的环境与配额

三条路不是替代关系，而是分工。绝大多数项目的实际形态是「SQL 选清单、文件树取内容」。

§6 坐标层：天球与像元不是一回事

6.1 ra 与 dec 是什么

ra 与 dec 是赤经与赤纬，单位是度，参照系是 J2000 赤道坐标。这是天文学里最通用的球面坐标，任何两个天体的角距离都可以由它们的 ra/dec 直接算出，无论这两条记录来自哪张表、哪一代观测。

正因为通用，它是跨表、跨代、跨星表匹配的唯一可靠基础。SpecObj 里有 ra/dec，PhotoObj 里有 ra/dec，spAll 里有多个位置列，匹配时用它们做球面距离计算，才是物理上正确的做法。

6.2 cx 与 cy 是什么

cx、cy、cz 是另一套东西：相机焦平面上的像元坐标。

在 SDSS 的成像相机里，每个 CCD 的输出会被映射到一套规范化坐标上，cx 与 cy 的取值范围大致在零到一之间，cz 是与之配套的第三个分量。它们记录的是「这个天体落在该次扫描的焦平面上的哪个位置」，用来做仪器层面的一致性检查与像元级分析。

关键在于：这套坐标以「每一次扫描」为基准。不同的 run 有不同的相机几何、不同的指向、不同的旋转角。同一个 cx 值在两次扫描里指向的天球位置不同。

更细一层：即使在同一次扫描内，像元坐标也只是「在该次扫描的局部坐标系里」有意义。它经过了若干步校正——去除了相机光学畸变、对齐了焦平面、按扫描方向做了旋转——每一步的变换参数随仪器状态而变。这些步骤的存在，正是 cx 与 ra 之间无法用一个全局公式互换的原因。

既然如此，它为什么还留在表里？因为仪器层面的分析需要它。判断某个天体是否落在 CCD 边缘、检查焦平面上是否存在系统性的光度梯度、做点源扩散函数的径向轮廓拟合，这些工作必须在像元坐标下做，天球坐标反而帮不上忙。

6.3 混算会发生什么

从光谱表取三条记录看，ra 在 214.20 到 214.25 度之间，dec 在 54.05 到 54.08 度之间，三者相距不到 0.03 度；对应的 cx 是 -0.4855、-0.4853、-0.4850，cy 是 -0.3300、-0.3303、-0.3302。这组数据说明两点。

好的一面：同一片天区里，cx/cy 的微小变化与 ra/dec 的微小变化方向一致，二者确实在描述同一组位置。

坏的一面：这种一致性只在同一组观测内成立。一旦跨扫描取数，cx/cy 的数值就没有可比的基准，用它们的差算距离会得到与角距离无关的散点。

有一个具体的反例可以说明误差量级。假设两次扫描的旋转角相差九十度，同一个 cx 差在两次扫描里对应的是两个互相垂直的方向。用像元差算出的「距离」在数学上仍然是个正数，看起来完全正常，但方向已经错了；若任务是找邻居，结果会是「在一条与真实方向垂直的线上找邻居」，命中率随机。

6.4 角距离该用哪个函数

数据库提供了一套空间检索函数，按天球坐标做邻近搜索。示例查询里最常见的形式是给定赤经、赤纬与半径，返回附近的对象。它们的输入是度，输出按距离排序。

不要自己用欧氏距离算 ra/dec 的差。赤经在高赤纬处会被压缩，直接取差会把极区附近的天体误判为很近。要么用官方函数，要么自己写球面余弦公式，并且把赤经差先乘以赤纬的余弦。

还有一个折衷写法值得推荐：用矩形预筛选加球面精筛。先用赤经区间与赤纬区间把候选集压到几十条，再在这几十条上算球面距离。这样既避免了对全表调用空间函数，又保证了最终距离的物理正确。赤纬区间的写法要注意，靠近极点时赤经区间的宽度会发散，此时应换成按极点距离筛。

6.5 回到案例：坐标取错会怎样

§1.5 的案例里，团队要做一件事：把黑洞映射的类星体与外部 X 射线星表做交叉匹配。

正确做法是从 spAll 取 ra 与 dec（或从它与测光匹配后的 ra/dec），与 X 射线位置在球面上算距离，按角秒级容差配对。

错误做法有两种，都很常见。一种是把 spAll 里的光纤坐标当成天体坐标——光纤位置与天体位置之间有偏移，在密集星场里这个偏移足以造成误配。另一种是在老表上用 cx/cy 做近似，因为看起来「也是坐标」。

两种错误的共同点是：它们都不报错，只是安静地给出错误的匹配率。

§7 质量层：红移的可信度与它的标记体系

7.0 阅读本节的认知校正

在讨论红移质量之前，需要先把一个常见预设拆掉：红移有值，不等于红移对。

光谱管线对每一条光谱都会给出一个红移值，即使这条光谱的信号很弱、模板拟合很勉强、甚至实际上是一条定标灯光谱。红移值不是「测出来的物理量」，而是「用一组模板拟合出来的最优解」，拟合质量另有一套编码。

因此任何把 z 直接当监督标签的做法，都必须先经过质量筛选。这一步在本数据集里的做法有明确的官方约定，下面逐层展开。

7.1 红移、误差与警告位

光谱表里与红移直接相关的列有三组。

z 是拟合出的红移。zErr 是它的形式误差，只反映拟合内部的统计不确定性，不含模板选择的系统偏差。zWarning 是一个位掩码，为零表示管线没有报告任何异常。

此外还有一套「去类星体后」的平行结果：z_noqso、zErr_noqso、zWarning_noqso。它的含义是「把类星体模板从拟合里去掉之后，这条光谱会得到什么红移」。当一条光谱既像星系又像类星体时，两套结果的差异就是判断依据。

还有一组人工复核结果 z_person 与 class_person，只对一部分光谱非空，记录的是人工检查的结论。在需要高纯度标签的场景里，这一列的价值高于自动结果。

7.2 零警告的覆盖率

对 5,112,724 条老光谱做筛选，zWarning=0 的有 4,283,507 条，占比约 83.8%；其余 829,217 条带非零警告。

按类别拆开看得更清楚。2,965,945 条星系光谱中零警告 2,639,535 条，1,105,286 条类星体光谱中零警告 753,228 条，1,041,493 条恒星光谱中零警告 890,744 条。

三类的零警告比例差异很大：星系约 89%，恒星约 86%，类星体只有约 68%。这不是管线的问题，而是类星体的光谱形态更难拟合——宽发射线、吸收系统、以及低信噪比的暗弱目标，都会推高警告率。类星体作为一个类别本身也是「由光谱形态定义」的：一个天体被标成类星体，往往正是因为它有一条宽线，而宽线恰恰让模板拟合的自由度变大、解不唯一。

对 §1.5 的案例，这意味着：直接用 class='QSO' 取样本，会有三成的行带着质量警告；只取零警告的样本，样本量会从一百一十万降到七十五万。前者污染标签，后者牺牲规模，中间没有免费的选项。

还有第三条路：保留全部样本，但把警告位当作特征或样本权重输入模型。这样做的前提是标签噪声与警告位相关，而不是随机。从上面的比例差异看，这个前提是成立的——模型可以从警告位学到「这条标签大概有多可信」，代价是它必须自己学会这件事，而不是由使用者提前清洗掉。

7.3 警告位不是二值

zWarning 的分布高度长尾。绝大多数行是零，其次是一条或两条低位被置起，再往上是非常零散的高位组合。这说明它不是「好坏」二分，而是一组彼此独立的失败模式：模板不匹配、信噪比不足、只有单条发射线、吸收线主导等等。

正确的处理方式不是「非零就丢」，而是先查清每一位的含义，再按项目需要决定哪些位可以容忍。官方为这张位掩码准备了单独的说明页，逐位解释。

7.4 其它质量列

除了红移，光谱表里还有几组值得注意的量。

snMedian 是整条光谱的逐像素信噪比中位数，另有一组 snMedian_u 到 snMedian_z 的分波段值。它们是判断光谱能否用于精细分析的第一道筛子。

rChi2、rChi2Diff 是拟合的卡方与卡方改善量，DOF 是自由度。它们与 zWarning 互补：警告位是离散判断，卡方是连续证据。

velDisp 是速度弥散的拟合值，只对星系有实际意义。对恒星而言它是无效值，对类星体则没有物理定义。

7.5 DAIMS 评估：把它当数据管理对象看

这里借一个通用的数据管理成熟度框架做一次横向对照。

维度	成熟度	依据
唯一标识	中	测光与老光谱各有稳定主键，但跨代无统一键，须靠位置匹配
元数据描述	极高	每张表有独立数据模型页，逐列给出单位与哨兵值
数据溯源	高	可从光谱回溯到观测夜、星场、管线版本
数据质量声明	极高	红移警告位有专页逐位解释，已知问题单列
版本管理	高	发布累积且旧版保留，版本边界在官网页明写
许可清晰度	低	未声明 SPDX，只有致谢与引用清单
商业可用性	未定义	无标准化授权流程，也无禁止性条款
机器可读格式	极高	统一的 SQL 接口，所有表同构可查
可复现性	中	星表可复现，但数据库会随新发布变化，查询需钉版本
文档可达性	高	数据模型、教程、Notebook 齐备

综合来看，它的强项集中在「可查、可溯、可解释」，弱项集中在「许可与跨代一致性」。对一个要做论文复现的项目，前者是必需；对一个要做产品的项目，后者必须先解决。

§8 许可与引用：开放访问不等于没有条件

8.1 官方页面到底写了什么

逐页查阅 DR20 的总览页、内容页、数据访问页与致谢指引页，能读到的是这样几件事。

数据访问不设门槛：SQL 接口匿名可用，文件树可直接下载，服务端计算环境对公众开放。官方新闻稿的措辞是「向全球天文学界与公众开放，遵循开放使用原则」，并引述数据产品协调人的话——数据不仅应当公开可获取，也应当可公开使用。

但没有任何页面给出协议名称。没有出现某一版知识共享协议的标识，也没有出现公有领域声明或数据 DOI。这一点需要说清楚，因为把公开可访问直接等同于某一版许可，是这类数据集最常见的引用错误。

还有一层需要区分：数据库本体与数据文件在性质上是两种东西。数据库由平台方运营，使用上受服务条款约束，条款内容不在这几份页面里；而光谱与测光文件是科研产出的原始数据，其使用条件由学术惯例与致谢要求界定。把两者混在一起谈「许可」，往往谈不到点子上。

8.2 唯一成文的硬要求：致谢

官方致谢指引给出的原文相当长，核心结构是四段：资助方（斯隆基金会、海辛-西蒙斯基金会、美国国家科学基金会与参与机构）、计算资源（犹他大学高性能计算中心）、两座台址（阿帕奇点天文台与拉斯坎帕纳斯天文台各自的运营方）、以及参与机构名单。官方同时提供了 LaTeX 版本，可直接粘进论文。

这段致谢不是建议，原文用的是「我们请求」的措辞，落点是「任何使用 SDSS-V 数据或软件的论文」。对数据集使用者而言，这是最接近「使用条款」的东西。

注意「或软件」三个字。如果项目用了官方提供的分析软件或 Notebook 模板，即使没有直接引用数据表，致谢义务同样成立。实际使用中这条常被漏掉，因为软件往往被视为「工具」而不是「数据」。

8.3 必须引用的论文

除致谢外，官方另有一份技术论文清单，按产品分三组。

任何 SDSS-V 论文都须引用综述论文。银河系映射与黑洞映射相关的须再引四篇仪器论文：望远镜本体、杜邦望远镜、BOSS 光谱仪、APOGEE 光谱仪。本地宇宙映射相关的须引五篇，涵盖概览、仪器、望远镜、数据处理管线与光谱仪。

这构成了一个在使用前容易被忽略的事实：同一份数据，不同子产品的引用义务不同。只用了光学光谱的项目，不应把红外仪器的论文列为必引。

8.4 老一代数据的致谢另有模板

SDSS-I 到 SDSS-IV 各自有独立的致谢模板，链在致谢指引页的底部。对一个同时使用两代光谱的项目，致谢段需要叠加。

§1.5 的案例就属于这一类：黑洞映射属于第五代，但如果模型还用了 SpecObj 里的老类星体光谱做预训练，致谢就必须同时覆盖两代。

8.5 对下游项目的实际含义

把上面的内容组织成一句可操作的话：开放访问给了使用权，致谢与引用给了使用方式，而商业条款处于未定义状态。

这意味着三件事。学术项目可以放心使用，但必须照抄致谢并核对引用清单。数据集的再分发不受明文限制，但再分发时把致谢一并带上是唯一稳妥的做法。商业产品需要先与项目方沟通，因为既没有许可授权，也没有禁止条款，法律状态是空白而非默许。

§9 生态位：与盖亚星表的分工

9.1 两者测的不是同一件事

盖亚星表测量的是位置：天体在天空中的精确坐标、由视差推出的距离、由多年观测推出的自行。它靠的是一台专门为天体测量设计的卫星，对全天反复扫描。

斯隆巡天测量的是光：把天体的光色散成光谱，读出谱线、红移、恒星参数与化学丰度。它的产出是「这个天体发出什么颜色的光」而不是「这个天体在哪里」。

这个分工决定了它们的互补方式：盖亚给出位置与距离，斯隆给出物理量。一个天体若能同时在两边找到，就有了完整的「在哪、多远、是什么」。

9.2 交叉匹配已经是现成的

SDSS-V 的前置星表体系在构建目标清单时，就已经把盖亚、红外星表、以及其他巡天的位置信息并入。spAll 里就有盖亚的三波段星等、红外星表的四波段星等与目标编号列。

这意味着做两边的交叉匹配不需要自己写球面匹配。绝大多数 SDSS-V 目标已经带着盖亚标识，直接从 spAll 取这些列即可。

这件事有一个容易忽略的后果：连接的方向决定了哪一边是主表。spAll 里的盖亚标识是「从斯隆目标出发去找盖亚对应」，它能回答「这个斯隆目标在盖亚里是谁」；它不能回答「这个盖亚源有没有对应的斯隆光谱」，因为没被选中观测的盖亚源根本不出现在 spAll 里。

只有当目标落在 SDSS-V 目标清单之外、需要反向查询时，才需要自己做球面匹配。这时用 ra/dec 与距离函数，见 §6。

对 §1.5 的案例，这个区别很实际。如果模型需要「负样本」，也就是「有盖亚位置但没有斯隆类星体光谱」的天体，那么从 spAll 出发是取不到的——必须从盖亚那一侧出发，做一次反向查询。而反向查询的代价比正向高得多，因为盖亚的源数是斯隆的全部天体数的四倍。

9.3 库内的分工

站内已有一篇关于盖亚第三次发布的条目。两者的关系可以直接用一句话概括：盖亚告诉你天体在哪儿、多远，斯隆告诉你它是什么。

站内另有一篇较早整理并已入库的斯隆条目，标题落在「南半球第一束光」这个角度上，本稿与它的分工在于更侧重表结构、键与取数边界：光谱与测光各自的口径、跨代键的不兼容、视图选择对计数的影响、以及红移警告位在样本筛选里的实际约束。两份合起来看，一份讲这次发布带来了什么，一份讲拿到之后怎么用。

对一个做多模态天文模型的项目，常见做法是以盖亚的源清单为主表，把斯隆的光谱与测光作为特征挂上去。反过来以斯隆为主表也行，只是主表的行数会小一个量级。

还有第三种用法，在恒星物理里很常见：把斯隆给出的恒星大气参数（有效温度、表面重力、金属丰度）当作标签，把盖亚给出的视差与自行当作约束，两者联合求解银河系结构。这类工作依赖的正是两边各自的强项，而不是任何一边单独的完整性。

9.4 一个具体的对比

项目	斯隆 DR20	盖亚第三次发布
主要产出	光谱与测光	位置、视差、自行
行数量级	测光 4.69 亿，光谱 2,767 万	源 18.1 亿
逐行误差	有，按列给出	有，按列给出
逐历元数据	部分产品有，主表无	变源有，主表无
取数方式	SQL 接口 + 文件树	表访问协议 + 批量下载
许可	未声明协议	明确的知识共享协议

这张表最有信息量的一行是最后一行。同一个天文领域的两个顶级数据集，在许可清晰度上走了两条完全不同的路。

§10 使用指引：三类角色与三个陷阱

10.1 学生与教学场景

目标是理解「光谱长什么样」与「红移如何从谱线读出」。路径是：用 SQL 取一小批高信噪比的星系光谱，到文件树取对应的 FITS，画出来，标出几条已知的谱线，对照官方给出的红移验证峰位。

规模控制在几十到几百条。这个阶段不需要理会 zWarning 的全部含义，只需要知道非零的行不必用。

10.2 研究者的建模场景

目标是把光谱当作输入、物理量当作输出，训练一个映射模型。路径是三段：先用 §5.3 的分区写法圈定样本，再按 §7.2 的口径做质量筛选，最后在文件树上批量取像素。

关键决策点有三个。第一是样本口径：用哪一代光谱，两代混用会引入管线差异。第二是标签定义：用自动拟合结果还是人工复核结果，前者规模大、后者纯度高。第三是切分方式：按天区分组还是随机切分，取决于要测的是「对新天体泛化」还是「对新天区泛化」。

在这三点之外，还有一个容易被忽略的第四点：观测条件是否被记录进了特征。同一条光谱的信噪比既取决于天体亮度，也取决于当晚的大气透明度与月相。如果不把信噪比或观测条件纳进模型，模型可能学到「这条光谱来自一个好夜晚」而不是「这个天体是什么」。这不是数据集的缺陷，而是任何观测数据都要面对的混杂。

10.3 工程团队的数据管道场景

目标是把这份数据变成可持续供给的训练数据管道。路径是把 SQL 变成定时任务，把结果落到自己的存储，把文件下载做成可重入的队列。

关键约束有三条。查询有超时，所以必须分区并且把结果落盘而不是每次重查。数据库随发布变化，所以要把发布版本写死在管道配置里，不要用「最新版」这种指针。致谢与引用要自动化，把版本号与对应的引用清单绑定，避免换版本后引用遗漏。

补第四条：把「这一行从哪来」记进自己的数据表。这份发布的每一行都对应一次观测，而观测的时间、星场、管线版本都可以追。如果下游表只存了数值不存出处，一旦出现质量问题，回溯的成本会远高于当初多存三列的成本。

10.4 三个跨角色通用的陷阱

第一个陷阱是把 PhotoObj 当作天体表。那一串七亿多的数字会出现在无数二手材料里，但它不是天体数。做任何关于「有多少天体」的陈述之前，先确认用的是哪张表。

第二个陷阱是把红移当标签。红移列永远有值，这个「永远有值」正是问题——它掩盖了拟合质量。§1.5 的案例里那个三成的警告率，就是不做这一步筛选的代价。

第三个陷阱是把「公开可访问」当许可。官方页面从头到尾没有给协议名，只给了致谢与引用。在产品化之前先把这件事查清楚，比事后补致谢便宜得多。

这三个陷阱有一个共同点：它们都不报错。表查得出来，值也在合理的范围里，结果图能画出来。错误只在下游的手工核对或复现失败时才暴露，而那时成本已经付掉了。

§11 常见误读（避坑清单）

常见说法	实际情况	证据
「DR20 于 2026 年 1 月发布」	2026 年 7 月 30 日发布，同日四条公告与四条新闻稿	官方新闻页四条同日条目，日期均为 7 月 30 日
「DR20 是 SDSS-V 的第二次发布」	是第三次，前两次为 DR19 与 DR18	DR20 数据访问页写「在 DR19 基础上构建」
「SDSS 有 7.94 亿个天体」	唯一天体为 4.69 亿，7.94 亿是含重复检出的记录行	PhotoPrimary 与 PhotoObj 计数相差 3.25 亿
「SDSS 有 12 亿个天体」	12.31 亿是全部检出（含特殊模式对象），不是天体数	PhotoObjAll 计数
「DR20 新增了 APOGEE 光谱」	DR20 无新红外光谱，DR19 数据原样拷贝，重分析推迟到 DR21	DR20 首页小标题明写
「DR20 更新了成像数据」	测光基表自 DR18 起行数未变	PhotoObj 计数与前代一致
「红移列有值就能用」	5,112,724 条中 829,217 条带非零警告，类星体有告警比例约三成	按 zWarning 分组计数
「cx/cy 是另一种坐标，可以算距离」	cx/cy 是单次扫描的焦平面像元坐标，跨扫描不可比	SpecObj 中同天区三行的 cx/cy 与 ra/dec 对照
「SDSS 数据是公有领域」	官方未声明协议；能核实的是致谢模板与引用清单	致谢指引页与数据访问页全文检索无协议名
「可以 CC BY 标注」	DR20 任何页面均未出现知识共享协议标识	同上
「SPIDERS 是独立巡天」	是黑洞映射下的一个观测项目，与 X 射线星表协调观测	DR20 首页项目列表
「169 幅拼块属于 300 万个目标之一」	拼块测绘延展区域，官方明确不计入目标天体总数	Scope 页脚注二
「allspec 的 2,767 万条是 2,767 万个天体」	同一次曝光既算独立条目又算进合并条目，存在重复计数	Scope 页脚注
「Star 加 Galaxy 就是全部天体」	两者相加比 PhotoPrimary 少 11,932 行，未穷尽	三表计数相减
「LVM 数据在 SkyServer 里能查」	积分视场以立方形式在文件树，观测管理表另有体系	数据访问页 LVM 段落
「两代光谱可以用 specObjID 直接联表」	第五代的是拼接变长数，与第四代语义不同	spAll 字段说明
「匿名查询必须注册」	匿名可用，注册只对批量作业有额外配额	SQL 接口无需登录即可返回结果
「查询可以不加 TOP 随便跑」	官方反复提示大范围查询会超时，须分区	SQL 示例页注释

§12 FAQ

Q1：SDSS DR20 一共有多少天体？

唯一测光天体 469,050,976 个，取自 PhotoPrimary。这个数字不含 SDSS-V 新增的光谱目标——那些目标绝大多数落在既有测光足迹内，已被计入；落在足迹外的以光谱为准，不进入测光表。

Q2：为什么官方说「超过三百万条光谱」，而汇总表写 2,767 万？

两个数字口径不同。三百万指的是这次发布新增的光谱，2,767 万是全部代际累计的条目数。前者描述增量，后者描述存量。

Q3：DR20 的光谱能直接下载成一个文件吗？

能下汇总星表，不能下全部像素。SDSS-V 光学光谱的每日合并汇总表约 985 MB，包含红移与分类等派生量；逐条光谱的像素在文件树里按星场分目录。

Q4：PhotoTag 和 PhotoObj 有什么区别？

行数上与 PhotoObjAll 相同（12.31 亿），字段更少。它是为快速查询设计的精简投影，官方建议用它替代 PhotoObjAll 做探索。

Q5：SDSS-V 的光谱在数据库里叫什么？

spAll。它的每日合并版本、按星场历元合并的版本、以及全历元合并的版本在文件树上各有一份汇总表，数据库里主要提供每日合并这一层。

Q6：怎么判断一条光谱的红移可不可信？

先看 zWarning 是否为零，再看 snMedian 是否够高，最后看 rChi2 与自由度。三者结合比任何单一指标可靠。

Q7：能拿这份数据做商业产品吗？

官方未声明许可协议，既无授权也无禁令。稳妥做法是先与项目方沟通，并把致谢与技术论文引用纳入产品文档。

Q8：SDSS 还在观测吗？

在。第五代仍在执行，官方新闻稿提到已在讨论后续两次发布的内容，其中包含拉斯坎帕纳斯天文台的第一批近红外光谱。

术语表

SDSS-V：斯隆数字巡天第五代，2021 年起执行，包含银河系映射、黑洞映射、本地宇宙映射三个科学项目。

BOSS：Baryon Oscillation Spectroscopic Survey 的光谱仪，最初为第三代建造，第五代在两座台址继续使用其双通道光纤光谱能力。

APOGEE：近红外高分辨光谱仪，观测 H 波段，主要用于恒星大气参数与化学丰度。

LVM：本地宇宙映射，以多台商用望远镜各挂一台积分视场单元，扫描连续天区得到高光谱立方。

BHM 与 MWM：黑洞映射与银河系映射，第五代的两个定点目标观测项目。

红移：光谱谱线相对静止波长的位移比例，是距离与退行速度的间接指标。本数据集中由模板拟合得到。

zWarning：红移拟合质量的位掩码，零表示管线未报告异常。

PhotoPrimary：每个测光对象只保留一次主检出的视图，是天体计数的标准口径。

spAll：SDSS-V 的每日合并光谱表。

sdss_id：SDSS-V 的跨仪器、跨白天体统一标识。

allSpec：官方为汇总所有代际光谱而维护的清单文件，当前为 1.0.2 版。

增值星表（VAC）：由科学团队在官方管线之外整理、经审核后随发布一同放出的派生产品。

附录 A 速查卡

-- 唯一天体数
SELECT COUNT(*) FROM PhotoPrimary;            -- 469050976

-- 检出记录数（含重复扫描）
SELECT COUNT(*) FROM PhotoObj;                -- 794328715

-- 老光谱总数与按类型拆
SELECT class, COUNT(*) FROM SpecObj GROUP BY class;

-- 只保留可信红移
SELECT COUNT(*) FROM SpecObj WHERE zWarning = 0;   -- 4283507

-- SDSS-V 光谱按项目拆
SELECT survey, COUNT(*) FROM spAll GROUP BY survey;

-- 分区查询（十个平方度天区）
SELECT COUNT(*) FROM PhotoPrimary
WHERE ra BETWEEN 170 AND 200 AND dec BETWEEN -5 AND 5;

附录 B 主要表清单

表	行数	单位
PhotoObjAll	1,231,051,050	全部检出
PhotoTag	1,231,051,050	精简投影
PhotoObj	794,328,715	标准检出
SpecObjAll	5,801,200	全部光谱
spAll	5,357,037	SDSS-V 每日合并
SpecObj	5,112,724	主用光谱
SpecPhoto	4,618,753	光谱连测光
PhotoPrimary	469,050,976	唯一天体
Star	260,562,240	恒星
Galaxy	208,476,804	星系

附录 C 外部资源对照

官方发布总览、内容页、范围页、数据访问页、致谢指引页、数据释放论文，是最直接的一手材料。SQL 接口的示例查询页本身也是一份很好的结构文档，它按主题列出各类联表写法，比逐表读数据模型更快建立整体印象。

对光谱像素的处理，官方提供了一系列在服务端运行的 Notebook 教程，覆盖从取数到画图到拟合的完整链路。这些教程本身就是可执行文档。

编辑说明

核验时间：2026-10-29。核验方式：逐页抓取 sdss.org 上 DR20 的总览页、内容页、范围页、数据访问页、取数指引页、致谢指引页与新闻页，抓取预印本页面核对数据释放论文摘要与提交日期；通过 SkyServer DR20 的 SQL 接口实际执行计数与分组查询，取得 PhotoObj、PhotoObjAll、PhotoPrimary、PhotoTag、SpecObj、SpecObjAll、SpecPhoto、spAll、Star、Galaxy 各表行数，以及按类别与警告位的分组计数、按项目与台址的分组计数、十个平方度天区的分区计数。未能核实：PhotoPrimary 中 11,932 行未归类的具体构成（数据库内对 type 与 mode 组合的查询返回异常，未能取得可用结果）；积分视场立方的体素级结构与文件数量未逐一核对；致谢指引页列出的全部技术论文未逐篇核对卷期。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• gaia-dr3 — 共享标签：多模态 / 评测基准 / 图像分类 / 影像-文本对齐
• soilgrids — 共享标签：多模态 / 评测基准 / 图像分类
• nasa-exoplanet-archive — 共享标签：多模态 / 评测基准 / 图像分类
• randolph-glacier-inventory — 共享标签：多模态 / 评测基准 / 图像分类
• biomedica — 共享标签：多模态 / 评测基准 / 图像分类 / 影像-文本对齐
• plip — 共享标签：多模态 / 评测基准 / 图像分类 / 影像-文本对齐
• eurosat — 共享标签：多模态 / 评测基准 / 影像-文本对齐
• cern-cms-opendata — 共享标签：多模态 / 评测基准 / 图像分类
• esa-worldcover — 共享标签：多模态 / 评测基准 / 图像分类
• skincap — 共享标签：多模态 / 图像分类 / 影像-文本对齐

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。