SQLite printf 加同名别名后，整数排序变成文本顺序

SQLite 查询原本按整数从大到小排列，给 printf() 的结果加上与原列相同的别名后，顺序却变成 3、2、1010、1、0。问题出在排序引用发生了变化：ORDER BY x 先匹配输出别名 x，此时排序的是格式化后的文本。

这不会把表里存储的整数改成文本。需要区分原列的值、输出表达式的类型，以及排序实际引用了哪一个表达式。以下针对支持内置 printf() 的 SQLite 3 普通 SELECT，不把同样写法直接套到 UNION 等复合查询。

同一个名字可能指向格式化结果

假设 samples.x 存储整数，下面两条只读查询的排序对象不同：

SELECT printf('%d', x) AS shown_x
FROM samples
ORDER BY x DESC;

SELECT printf('%d', x) AS x
FROM samples
ORDER BY x DESC;

第一条没有名为 x 的输出别名，排序引用输入列。第二条的 x 则被解析为输出列别名，指向 printf('%d', x)。printf() 返回字符串；数字看起来仍是数字，不表示输出值仍按数值排序。

可以在允许读取的样本范围内并列查看实际类型：

SELECT s.x,
       typeof(s.x) AS stored_type,
       printf('%d', s.x) AS shown_x,
       typeof(printf('%d', s.x)) AS shown_type
FROM samples AS s
LIMIT 20;

表名与列名是占位值。预期整数输入的 stored_type 为 integer，格式化结果的 shown_type 为 text。SQLite 排序前不会因为字符串长得像数字就自动把它转换为数值；默认二进制文本比较下，'3' 会排在 '1010' 后面，因此降序时出现在前面。

列声明为 INTEGER 也不能单独证明每行都存着整数。若读取到 text 等其他类型，应先查清已有数据，而不是将所有异常都归因于别名。

明确按原始数值列排序

如果应用需要保留输出字段名 x，可以用表别名限定排序表达式：

SELECT printf('%d', s.x) AS x
FROM samples AS s
ORDER BY s.x DESC;

这里的 s.x 指向输入表列，输出仍叫 x。另一种可读性更好的写法是为展示值起不同名称：

SELECT printf('%d', s.x) AS shown_x
FROM samples AS s
ORDER BY s.x DESC;

修改输出名可能影响应用的字段映射，需要连同调用方核对。不要通过在别名后加一个看不见的空格来绕开重名，那会把问题转移到结果字段名上。

ORDER BY 1 在这些查询里指向第一项输出，也就是格式化后的文本，不等同于按原始数值列排序。如果现有查询用列序号排序，也要一并检查。

排序值与显示值保留各自用途

只为修排序而把 printf() 的结果再 CAST 回整数，容易引入另一套含义。实际格式若带单位、分隔符、补位或小数，转换可能不再对应原值；优先按已有数值列排序，将展示格式留在输出层或应用层。

对真实的小数数据，示例的 %d 本身也不适合作为保留小数的显示规则。应沿用业务要求的格式，并继续按原数值排序。格式化后两个值显示相同，不代表它们原来的数值相同。

查询若已经包在外层子查询中，而外层只收到格式化字符串，就需要让内层额外输出原始排序键，再在外层使用它。不要引用已经不在这一层 FROM 范围内的表别名。

对照大小差异明显的样本

验收时应包含 2、10、100、负数以及业务允许的零值和缺失值，核对的是返回行顺序，而不只是列标题恢复正常。NULL 与整数的排序也应按原业务约定处理，不要为了显示方便把缺失值改写入表。

需要稳定处理并列值时，在数值键之后增加真实唯一键，例如 ORDER BY s.x DESC, s.id，前提是该表确有能唯一标识记录的 id。没有完全确定的排序键时，并列行顺序不应视为固定。

这项修复只改查询，不需要迁移列类型或更新存量数据。保留原 SQL 和输出字段约定；如果调用方不接受改名，回退输出名，使用限定的原列排序，再核对分页及展示结果。