`SELECT` 输出列

SELECT 输出列决定查询结果对外暴露什么：列的顺序、名称、类型、空值语义和计算规则。类型转换不仅发生在 WHERE 或 JOIN 中，也发生在每一个输出表达式上。输出列一旦被视为报表、视图或 API 的数据接口，类型稳定性就和列名一样重要。

输出列的基本组成

SELECT
  o.order_id,
  CAST(o.total_amount AS DECIMAL(14, 2)) AS total_amount,
  CASE WHEN o.status = 'paid' THEN TRUE ELSE FALSE END AS is_paid
FROM orders AS o;

选择列表中的每个表达式都会生成一列，可以是：

表列或限定列名；
字面量、参数和 NULL；
算术、比较、字符串和日期表达式；
函数、聚合函数和窗口函数；
CASE、COALESCE、CAST 等条件/转换结构；
返回单个值的标量子查询。

数据库会分别解析这些表达式的类型，再把结果类型交给客户端或外层查询。

列的顺序和名称

输出列顺序就是选择列表顺序：

SELECT customer_id, name, created_at
FROM customers;

应用程序最好按列名读取，但列名也必须稳定、唯一且有业务含义。计算表达式应明确使用别名：

SELECT unit_price * quantity AS line_amount
FROM order_items;

不写别名时，数据库可能生成实现相关的名称，例如表达式文本、函数名或空名称。驱动和报表工具对这些名称的处理也可能不同。

`NULL` 和未知字面量作为输出

单独输出 NULL 时，数据库可能无法确定其类型：

SELECT NULL AS reserved_value;

如果结果要用于视图、UNION、客户端绑定或插入另一张表，应显式指定类型：

SELECT CAST(NULL AS VARCHAR(100)) AS reserved_value;

字符串字面量也可能先处于未知类型：

SELECT 'pending' AS status;

在简单查询中通常会得到文本，但进入集合操作、函数调用或视图定义时，推导上下文可能不同。公共接口中最好显式 CAST，让结果类型不会因查询重写而变化。

输出表达式中的数值转换

SELECT
  completed_count,
  total_count,
  CAST(completed_count AS DECIMAL(12, 4))
    / NULLIF(total_count, 0) AS completion_rate
FROM task_summary;

这里显式把整数提升为精确小数，并用 NULLIF 避免除零。输出列还应考虑：

任一输入为 NULL 时结果是否应为 NULL；
结果是否需要固定精度和小数位；
中间运算是否可能溢出；
客户端是否能准确接收 BIGINT 或 DECIMAL。

只在展示层格式化金额：

SELECT TO_CHAR(total_amount, 'FM999999990.00') AS amount_text
FROM orders;

amount_text 是文本，不应再被下游当作数值计算。若同一结果既要展示又要计算，输出原始数值列和单独的展示列。

别名的可见范围

输出别名不是同一 SELECT 列表中的变量：

-- 通常无效：amount 在同层尚未成为可引用名称
SELECT unit_price * quantity AS amount,
       amount * tax_rate AS tax_amount
FROM order_items;

可以增加一层查询，使前一层的输出列成为后一层的输入列：

SELECT amount,
       amount * tax_rate AS tax_amount
FROM (
  SELECT unit_price * quantity AS amount, tax_rate
  FROM order_items
) AS item_amounts;

ORDER BY 通常位于逻辑上的较后阶段，可以引用输出别名；WHERE 通常不能。不同数据库对同名输入列和输出别名的解析细节可能不同，避免重名最稳妥。

`SELECT *` 与类型契约

SELECT * FROM customers;

星号会展开当前表表达式的所有可见列。它适合交互式探索，不适合作为长期接口，因为新增列、列类型变化或连接重复列都会改变输出结构：

SELECT c.*, o.order_id
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.customer_id;

稳定查询应显式列出字段，尤其是视图、报表、导出任务和 API 查询。这样可以控制敏感列、固定类型和减少不必要的数据传输。

聚合和窗口输出列

聚合查询中，每个非聚合输出列必须是分组键或由分组唯一确定：

SELECT customer_id,
       CAST(SUM(total_amount) AS DECIMAL(14, 2)) AS customer_total
FROM orders
GROUP BY customer_id;

聚合函数的返回类型可能与输入类型不同，SUM、AVG、COUNT 的空输入行为也不同。需要作为接口输出时，显式固定类型，并决定没有数据时返回 NULL 还是默认值。

窗口函数不会合并行：

SELECT order_id,
       total_amount,
       SUM(total_amount) OVER (PARTITION BY customer_id) AS customer_total
FROM orders;

输出仍然每张订单一行，但新增列的类型由窗口函数决定。若要按窗口结果筛选，先放入子查询或 CTE，再在外层引用别名。

`DISTINCT` 不改变列的类型

DISTINCT 对整个输出行去重：

SELECT DISTINCT country, city
FROM customers;

它不会只对第一列去重，也不会把不同类型自动统一成业务类型。NULL 在重复判断中通常按“相同位置的空值可归为同一组”处理，这与 NULL = NULL 的三值逻辑不是一回事。

如果需要“每组保留一行”，应使用窗口函数或数据库专用语法，并明确排序条件，而不是用 DISTINCT 隐藏连接重复。

集合查询的输出类型

UNION 等集合查询的输出列类型由同一位置的多个分支共同决定：

SELECT CAST(id AS BIGINT) AS id, name
FROM current_users
UNION ALL
SELECT CAST(id AS BIGINT) AS id, name
FROM archived_users;

左侧查询通常提供最终列名，但右侧值仍要转换到公共类型。若一侧写数字、一侧写文本，结果可能变成文本或直接失败。对外输出前，在每个分支都显式转换，避免结果类型因新增分支而改变。

输出列与视图定义

视图会保存查询的输出结构，输出列类型变化可能影响依赖它的应用、索引和其他视图：

CREATE VIEW order_summary AS
SELECT order_id,
       CAST(total_amount AS DECIMAL(14, 2)) AS total_amount
FROM orders;

不要依赖视图定义中的隐式类型推导。发布前应检查视图列名、类型、可空性和顺序，并把它们当作版本化接口。修改类型时，评估客户端序列化、缓存和下游报表的兼容性。

客户端和驱动的类型映射

数据库返回的类型还会经过驱动映射：

数据库结果	客户端可能得到的值	需要注意
`DECIMAL`/`NUMERIC`	数字或字符串	字符串常用于避免浮点精度损失
`BIGINT`	大整数或字符串	JavaScript `Number` 可能无法精确表示全部范围
日期/时间戳	日期对象或字符串	时区和格式由驱动设置影响
`NULL`	`null`、`None` 等	不要自动替换成空字符串或零

接口文档应同时说明数据库列类型和序列化类型。仅凭浏览器或命令行显示结果，不能判断数据库内部是否保存了精确数值。

让类型错误尽早暴露

如果输出表达式可能失败，应该在查询边界就处理：

-- 目标数据库支持安全转换时使用方言函数
SELECT TRY_CAST(raw_score AS DECIMAL(8, 2)) AS score
FROM staging_scores;

如果没有安全转换函数，可以把清洗过程放在 ETL/暂存阶段，并将失败记录单独保存。不要依赖客户端收到结果后再猜测并转换，因为那时错误可能已经脱离原始数据上下文。

性能注意事项

输出列中的函数和转换通常不会阻止 WHERE 使用索引，但可能增加 CPU、排序和网络开销：

SELECT CAST(large_text AS JSON) AS payload
FROM events
WHERE event_type = :event_type;

只选择需要的列，避免在 SELECT * 中读取大文本、二进制或敏感字段。对重复使用的规范化结果，可考虑生成列或物化视图，并根据执行计划决定是否建立索引。

输出列检查清单

每列是否有明确、唯一且稳定的名称？
计算列的精度、时区、NULL 和错误行为是否清楚？
是否无意中把数字/日期格式化成文本后再交给下游？
NULL 字面量、CASE 分支和集合分支是否显式指定类型？
是否避免了不必要的 SELECT * 和敏感列暴露？
视图、报表或 API 的列类型变化是否经过兼容性评估？
客户端驱动如何映射 DECIMAL、BIGINT、时间戳和 NULL？

小结

SELECT 输出列是查询结果的接口，列名、顺序、类型和空值语义都应稳定。
NULL、未知字符串、聚合、窗口和集合查询都可能触发额外的类型推导。
展示格式化应与业务计算分离；金额、标识符和日期不要在中途变成文本。
显式 CAST、固定别名、避免 SELECT *，并验证客户端类型映射，能显著减少下游兼容问题。

输出列的基本组成​

列的顺序和名称​

NULL 和未知字面量作为输出​

输出表达式中的数值转换​

别名的可见范围​

SELECT * 与类型契约​

聚合和窗口输出列​

DISTINCT 不改变列的类型​

集合查询的输出类型​

输出列与视图定义​

客户端和驱动的类型映射​

让类型错误尽早暴露​

性能注意事项​

输出列检查清单​

小结​