为什么 MySQL 5.7 order by 会影响临时排名列？

Question

我需要生成按关闭百分比排名的员工列表。我构建了以下存储过程：

SET @cnt = 0;
SET @percent = 2.0;

SELECT
    CASE
        WHEN stats.close/(stats.open+stats.close) = @percent THEN @cnt
        ELSE (@cnt := @cnt + 1) 
    END rank,
    stats.employee,
    stats.close,
    stats.open,
    (@percent := stats.close/(stats.open+stats.close)) percent
         FROM stats
              WHERE stats.date = CURDATE()
                   ORDER BY percent

它返回

| Rank | Employee | Close | Open | Percent|  
|     1|    Smith|       9|     1|    0.90|  
|     2|    Jones|      75|    25|    0.75|  
|     3|      Zed|       1|     9|    0.10|  
|     3|    Adams|      10|    90|    0.10|

此查询符合其预期目的，但在查看查询后，它看起来不应该正确返回。这就是我这么认为的原因：

MySQL 在处理 ORDER BY 之前处理 SELECT。因此，我假设 MySQL 将按照它决定从数据库中出来的任何顺序分配排名，然后对结果集进行排序。我希望它看起来像这样：

| Rank | Employee | Close | Open | Percent|  
|     3|    Smith|       9|     1|    0.90|  
|     2|    Jones|      75|    25|    0.75|  
|     4|      Zed|       1|     9|    0.10|  
|     1|    Adams|      10|    90|    0.10|

为什么不是这样？

Answer 1

以任何顺序使用@variables 严格来说并不可靠，但它是一种常见的“hack”来模仿 MySQL 仍然缺乏的窗口函数（计划用于 v8.x，即仍处于预发布阶段）。

这种“hack”依赖于 ORDER BY 与 SELECT 一起处理（不是两个不同的步骤），它们比您预期的更集成。例如

SELECT * 
FROM   (SELECT CASE 
                 WHEN stats.close / ( stats.open + stats.close ) = @percent THEN 
                 @cnt 
                 ELSE ( @cnt := @cnt + 1 ) 
               end                                                        rank, 
               stats.employee, 
               stats.close, 
               stats.open, 
               ( @percent := stats.close / ( stats.open + stats.close ) ) 
               percent 
        FROM   stats 
        CROSS JOIN (@percent := 0 x, @cnt :=0 y) vars
        WHERE  stats.date = Curdate() 
        ORDER  BY percent ASC) d 
ORDER  BY percent DESC 

内部订单percent ASC 将从最低百分比值开始设置排名，然后外部订单将最高百分比放在首位。

真正的问题是不能保证 select 子句中从左到右（或从上到下）的表达式序列。所以很有可能@percent 的比较计算@cnt 没有按照写好的sql 所示的方式进行。在实践中，它“大部分时间”都有效，但可能不会。 （所以带上窗口函数！！）