gpt4 book ai didi

mysql - TokuDB 排序时间在 ASC 和 DESC 之间不同

转载 作者:行者123 更新时间:2023-11-29 00:19:34 30 4
gpt4 key购买 nike

这是从 Tokutek 下载的 MariaDB + TokuDB 7.1 社区。如果这是正常行为,请接受我的无知,但我对排序结果有疑问。我在两个排序方向(升序和降序)之间的排序时遇到了巨大的时间差异:

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

请注意,这不是我正在使用的确切数据,因为太多而无法包含在此处。我只是想创建一些测试数据来演示问题。我的问题是 - 为什么它会这样以及如何使降序查询更快?

最佳答案

这是索引条件下推 (ICP) 的一个已知错误。解决方法是通过全局或在执行此查询的 session 中设置 optimizer_switch 来禁用 ICP。

mysql> SET optimizer_switch='index_condition_pushdown=off';

(完全公开,我是 Tokutek 的员工,TokuDB 的制造商)

关于mysql - TokuDB 排序时间在 ASC 和 DESC 之间不同,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21586298/

30 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com