对于在这个查询中查找的任何其他人来说,例如给出了两个行号的2行
+----------+-------+
| sudentid | fname |
+----------+-------+
| 101 | NULL |
| 103 | NULL |
| 112 | NULL |
+----------+-------+
3 rows in set (0.00 sec)
查询产生
+----------+-------+--------+
| sudentid | fname | rownum |
+----------+-------+--------+
| 101 | NULL | 1 |
| 103 | NULL | 2 |
+----------+-------+--------+
2 rows in set (0.00 sec)
有一个解释计划
+------+-------------+---------+------+---------------+------+---------+------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+---------+------+---------------+------+---------+------+------+----------------------------------------------+
| 1 | SIMPLE | student | ALL | NULL | NULL | NULL | NULL | 8 | Using where; Using temporary; Using filesort |
+------+-------------+---------+------+---------------+------+---------+------+------+----------------------------------------------+
1 row in set (0.00 sec)
解释计划符合我的期望,即订购时间几乎是最后一天。(
https://blog.jooq.org/2016/12/09/a-beginners-guide-to-the-true-order-of-sql-operations/
)
但似乎发生的是,由于ORDER BY递增了select中使用的变量,因此还有另一个WHERE子句以事件的实际顺序调用,而这一顺序并未反映在explain计划中(我认为这反映了事件的逻辑顺序)。
我不知道OP在这里要做什么(或者如果结果不正确),但这不是通常在版本8之前分配行号的方式。
