tokudb对ASC vs desc之间的分类时间不同

Question

这是Mariadb Tokudb 7.1从Tokutek下载的社区。如果这是正常的行为，请接受我的无知，但我对分类结果有疑问。我在两种方向之间的分类方面经历了巨大的时间差异 - 上升和下降：

SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts asc
+---------+----------+---------+
| id      | createts | deleted |
+---------+----------+---------+
| 1999999 |  2000099 |    NULL |
| 2000000 |  2000100 |    NULL |
+---------+----------+---------+
2 rows in set (0.00 sec)
SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts desc
+---------+----------+---------+
| id      | createts | deleted |
+---------+----------+---------+
| 2000000 |  2000100 |    NULL |
| 1999999 |  2000099 |    NULL |
+---------+----------+---------+
2 rows in set (0.55 sec)

下面我介绍了简化的测试用例。这是表：

CREATE TABLE `sort_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `createts` int(11) DEFAULT NULL,
  `deleted` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_createts` (`createts`)
) ENGINE=TokuDB

在这里，我使用此过程用200万行填充表：

delimiter ;;
drop procedure if exists sort_test_populate;;
create procedure sort_test_populate()
begin
DECLARE int_val INT DEFAULT 1;
myloop : LOOP
  if (int_val > 2000000) THEN
    LEAVE myloop;
  end if;
  insert into sort_test (id, createts) values (int_val, int_val+100);
  set int_val = int_val +1;
end loop;
end;;
call sort_test_populate();;
Query OK, 1 row affected (28 min 2.80 sec)

这再次是我的测试查询：

SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts asc
2 rows in set (0.00 sec)
SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts desc
2 rows in set (0.55 sec)

这是"解释扩展"结果，这两个查询都是相同的：

+------+-------------+-----------+-------+---------------+--------------+---------+------+------+----------+-------------+
| id   | select_type | table     | type  | possible_keys | key          | key_len | ref  | rows | filtered | Extra       |
+------+-------------+-----------+-------+---------------+--------------+---------+------+------+----------+-------------+
|    1 | SIMPLE      | sort_test | range | idx_createts  | idx_createts | 5       | NULL |    2 |   100.00 | Using where |
+------+-------------+-----------+-------+---------------+--------------+---------+------+------+----------+-------------+

请注意，这不是我正在使用的确切数据，这太多了，在这里包括。我只是想创建一些测试数据以证明问题。我的问题是 - 为什么它是这样的，以及如何使下降订单更快地查询？

Answer 1

这是索引条件下推（ICP）的已知错误。解决方法是通过在全球或执行此查询的会话中设置Optimizer_Switch来禁用ICP。

mysql> SET optimizer_switch='index_condition_pushdown=off';

（完全披露，我是Tokudb的制造商Tokutek的员工）