这个问题我之前也碰到过类似的情况，本质是MariaDB 10.2版本的查询优化器在处理DISTINCT+ORDER BY DESC组合时的特定优化逻辑导致的，具体拆解如下：

1. 优化器的"升序去重+反转"策略 #

当你的查询同时包含DISTINCT和ORDER BY column DESC时，MariaDB 10.2的优化器会优先选择一条性能导向的执行路径：

• 先对目标数据按排序键做升序排序：因为升序排序后重复值会集中相邻，能大幅降低去重操作的复杂度，提升执行效率；
• 再对去重后的结果集进行反转，以此模拟DESC的降序效果。

但这里的问题在于：如果你的预期排序依赖数据的原始插入顺序、或是非排序键的隐含关联关系，这种"先升序再反转"的结果就会和直接执行DESC排序的结果不一致。数据量越大，优化器越倾向于选择这条性能优先的路径，异常表现也就越明显。

2. 无DISTINCT时正常的核心原因 #

当去掉DISTINCT后，优化器不需要处理去重逻辑，会直接按照ORDER BY column DESC的要求对全量数据做降序排序，自然就符合你的预期结果。

3. 你的场景佐证 #

你提到的两个案例完全贴合这个逻辑：

• 小数据量场景：预期foo;baz（对应id 4、3的降序），实际得到baz;foo，说明优化器先按id升序排序（3、4）去重后，没有正确执行反转步骤（或是反转逻辑出现了版本性偏差）；
• 大数据量场景：预期foo;bar;baz，实际得到bar;baz;foo，本质是升序排序去重后的结果是foo;bar;baz，反转后本该是baz;bar;foo，但实际却直接返回了升序去重的结果——这大概率是MariaDB 10.2版本的一个优化器bug，导致反转步骤被意外跳过。

验证方法 #

你可以用EXPLAIN查看查询的执行计划来验证这个结论：

EXPLAIN SELECT DISTINCT your_columns FROM your_table ORDER BY sort_column DESC;

如果执行计划中显示的排序方式为升序，就能坐实这个原因。

内容的提问来源于stack exchange，提问作者michelek