PostgreSQL 的 ORDER BY time DESC, id ASC 多重排序会有以下结果：

* time DESC（时间倒序）是主要排序条件： PostgreSQL 会首先根据 time 列的值进行排序。DESC 表示降序，所以时间最新的记录会排在前面。
* id ASC（ID 升序）是次要排序条件： 当有多条记录的 time 值相同时，PostgreSQL 才会使用 id 列作为第二个排序条件。ASC 表示升序，所以这些 time 值相同的记录会按照它们的 id 从小到大的顺序排列。

如果 time 优先，那么 id 又有什么意义？

id 的意义在于 打破平局（Tie-breaking）。

想象一下，你有一批数据，其中有几条数据的发布时间（time）是完全相同的。如果不使用 id ASC 作为次要排序条件，那么这几条 time 相同的记录在结果集中的顺序是不确定的。PostgreSQL 可能会根据其内部存储的顺序或其他因素来决定它们的相对位置，但这种顺序不是我们可控的，并且在不同的查询、不同的数据库版本或不同的数据插入顺序下可能会发生变化。

通过添加 id ASC，我们为这些 time 相同的记录提供了一个稳定且可预测的排序。当 time 相同时，我们确保了拥有较小 id 的记录会出现在拥有较大 id 的记录之前。这使得查询结果在逻辑上更加一致，方便开发者进行调试、测试和业务逻辑的处理。

总结 time DESC, id ASC 的含义：

1. 最重要： 按时间从新到旧排序。
2. 次要： 在时间相同的情况下，按 ID 从小到大排序。

如果发布时间从旧到新，而回复时间要从新到旧，又该如何排序？

这种情况需要你定义清楚是哪个表的哪个字段代表“发布时间”以及哪个表的哪个字段代表“回复时间”，并且这两者很可能属于不同的表，或者同一个表但使用不同的字段。

假设：
* posts 表有一个 publish_time 字段，代表发布时间。
* replies 表有一个 reply_time 字段，代表回复时间。

并且你希望查询的是一个综合性的列表，其中既包含帖子，也包含回复，并且按照发布时间（旧到新）和回复时间（新到旧）进行排序。

这通常需要一个 UNION 或 UNION ALL 操作来合并来自不同表（或同一表的不同部分）的数据，然后在一个统一的上下文中进行排序。

方案一：使用 UNION ALL 合并不同来源的数据

如果你需要合并帖子和回复，并且它们的结构有一些共同点，或者你可以创建一些共同的结构：

sql
SELECT
'post' AS item_type,
p.post_id AS item_id,
p.title AS item_description,
p.publish_time AS main_time, -- 发布时间
NULL AS secondary_time -- 帖子没有回复时间，这里设为NULL
FROM
posts p

UNION ALL

SELECT
'reply' AS item_type,
r.reply_id AS item_id,
r.content AS item_description,
r.post_id AS main_time, -- 可以是关联帖子的ID，但这里不是主要排序依据
r.reply_time AS secondary_time -- 回复时间
FROM
replies r

ORDER BY
main_time ASC, -- 发布时间 从旧到新
secondary_time DESC; -- 回复时间 从新到旧


解释：

* 'post' AS item_type, 'reply' AS item_type: 添加一个标识符，说明这是帖子还是回复。
* p.publish_time AS main_time: 将帖子的发布时间作为主要排序依据。
* r.reply_time AS secondary_time: 将回复的回复时间作为次要排序依据。
* UNION ALL: 将两个 SELECT 语句的结果合并。UNION ALL 比 UNION 效率高，因为它不去除重复项（在这里通常不是问题，因为数据来源不同）。
* ORDER BY main_time ASC, secondary_time DESC:
* main_time ASC: 首先按发布时间（publish_time）从旧到新排序。
* secondary_time DESC: 这是关键。 当 main_time 相同时（例如，你合并了其他表的数据，或者在某些业务场景下），我们会进一步按照 secondary_time（这里是回复的 reply_time）从新到旧排序。

重要注意事项：

* 数据结构的一致性： UNION ALL 要求所有 SELECT 语句的列数和数据类型必须匹配。上面的例子为了演示，为 main_time 和 secondary_time 赋予了不同的含义，这可能需要根据你的实际数据模型调整。
* 排序逻辑的理解： 如果你的需求是：
1. 优先按发布时间（旧到新）排列所有帖子。
2. 然后，在每个帖子内部，按回复时间（新到旧）排列该帖子的回复。
那么 UNION ALL 配合 ORDER BY 可能不是最直接的方式，你可能需要更复杂的窗口函数或子查询。

更精确地理解你的需求：

* “发布时间从旧到新”：这是对帖子的排序。
* “回复时间，要从新到旧”：这是对回复的排序。

如果你想得到一个 单一的、混合的列表，并且你希望 所有帖子都排在所有回复的前面，并且帖子之间按发布时间排序，回复之间按回复时间排序，那么 UNION ALL 是一个好的起点，但排序逻辑需要仔细设计。

一个更复杂的、考虑帖子里回复的排序示例：

如果我们假设你有一个 threads 表（包含帖子信息）和一个 messages 表（包含帖子和回复），并且你希望：
1. 所有“帖子”（thread）按照 created_at（旧到新）排序。
2. 所有“回复”（message）按照 created_at（新到旧）排序。
3. 并且在结果中，所有帖子都应该在它们各自的回复之前。

这种情况会变得复杂，通常使用窗口函数来处理。但如果你的问题是“如何对不同字段进行不同方向的排序”，上面的 UNION ALL 示例是一个很好的模型。

总结：

* ORDER BY time DESC, id ASC：先按时间倒序，时间相同时按 ID 升序。ID 的作用是稳定排序，打破时间相同的平局。
* 发布时间（旧到新）和回复时间（新到旧）的混合排序，通常需要 UNION ALL 来合并来自不同源头的数据，然后在合并后的结果集上应用 ORDER BY 子句，并确保 ORDER BY 的字段和顺序符合你的需求。