Время сортировки TokuDB отличается между ASC и 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

Здесь я заполняю таблицу 2 миллионами строк, используя эту процедуру:

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

Это известная ошибка с индексным условием Pushdown (ICP). Обходной путь - отключить ICP, установив optimizer_switch либо глобально, либо в рамках сеанса, выполняющего этот запрос.

mysql> SET optimizer_switch='index_condition_pushdown=off';

(полное раскрытие, я сотрудник Tokutek, создатель TokuDB)