我之前也踩过这个坑！MySQL 5.7和MariaDB 10.x在用户变量结合ORDER BY的执行逻辑上确实有差异，导致你遇到的变量值混乱问题，核心原因就是两者对语句执行顺序的处理不一样：

• 在MySQL 5.7里，ORDER BY通常会先于用户变量的赋值逻辑执行，所以变量能按排序后的顺序正确获取上一行数据；
• 但MariaDB 10.x的查询优化器可能会调整执行顺序，在排序前就开始处理变量赋值，导致变量拿到的不是排序后的上一行值，自然就混乱了。

下面给你两个靠谱的解决方案：

方案1：用子查询先完成排序，再处理变量 #

把需要关联和排序的逻辑放到子查询里，确保排序完全生效后，再在外层处理用户变量的赋值。这样MariaDB就能按排序后的顺序逐个更新变量，正确获取上一行数据：

SELECT 
    curr.*,
    @prev_col AS previous_row_column,
    -- 先获取上一行值，再更新变量为当前行的值
    @prev_col := curr.target_column AS current_row_column
FROM (
    -- 先完成多表关联和排序，确保这里的ORDER BY先执行
    SELECT 
        t1.id, t1.sort_col, t1.target_col,
        t2.name, t2.other_col
    FROM table1 t1
    JOIN table2 t2 ON t1.id = t2.t1_id
    JOIN table3 t3 ON t1.group_id = t3.id
    ORDER BY t1.sort_col ASC, t1.id ASC
) AS curr
-- 初始化变量，避免脏数据
CROSS JOIN (SELECT @prev_col := NULL) AS init_var;

方案2：改用窗口函数（推荐） #

如果你的MariaDB版本是10.2及以上，强烈建议用LAG()窗口函数替代用户变量，这是官方推荐的方式，执行逻辑明确，不会受数据库版本差异影响，代码可读性也更高：

SELECT 
    t1.id, t1.sort_col, t1.target_col,
    t2.name, t2.other_col,
    -- LAG函数直接获取排序后的上一行target_col的值
    LAG(t1.target_col) OVER (ORDER BY t1.sort_col ASC, t1.id ASC) AS previous_row_column
FROM table1 t1
JOIN table2 t2 ON t1.id = t2.t1_id
JOIN table3 t3 ON t1.group_id = t3.id
ORDER BY t1.sort_col ASC, t1.id ASC;

关键注意点 #

• 永远不要在同一个SELECT子句里同时写ORDER BY和用户变量赋值，这种写法的执行顺序依赖数据库优化器，不同版本结果不可控；
• 如果你还在使用MariaDB 10.1及以下（不支持窗口函数），方案1是唯一可靠的选择，一定要确保排序逻辑在变量处理之前完成。

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