TokuDB在ASC和DESC之間的排序時間不同

這是從Tokutek下載的MariaDB + TokuDB 7.1社區。如果這是正常行爲，請接受我的無知，但我對排序結果有疑問。在排序兩個方向 - 升序和降序時，我遇到了巨大的時間差異：TokuDB在ASC和DESC之間的排序時間不同

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 | 
+------+-------------+-----------+-------+---------------+--------------+---------+------+------+----------+-------------+

請注意，這不是我正在使用的確切數據，這將包括在這裏太多。我只是想創建一些測試數據來展示問題。我的問題是 - 爲什麼它的行爲如何以及如何使降序查詢更快？

來源

2014-02-05 user1765811

怎麼樣的範圍內性能'WHERE createts <103'？ –

如果我使用'WHERE createts <103'，那麼對於ASC和DESC排序來說性能非常好。 – user1765811

我懷疑你遇到了一個節點邊界問題，TokuDB必須訪問兩個節點來檢索你的結果。 –

這是一個已知的索引狀態下推（ICP）錯誤。解決方法是通過全局或在執行此查詢的會話內設置optimizer_switch來禁用ICP。

mysql> SET optimizer_switch='index_condition_pushdown=off';

（全面披露，我在Tokutek僱員，TokuDB的製造商）

來源

2014-02-07 18:46:02 tmcallaghan

是的，該解決方案修復了我的測試用例查詢以及我遇到同樣問題時的真實生活查詢。 – user1765811

TokuDB在ASC和DESC之間的排序時間不同

回答

相關問題