database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00
Code Activity

Bug #36259 (Optimizing with ORDER BY) and bug#45828 (Optimizer won't

Browse Source 
use partial primary key if another index can prevent filesort

The fix for bug #28404 causes the covering ordering indexes to be 
preferred unconditionally over non-covering and ref indexes.

Fixed by comparing the cost of using a covering index to the cost of
using a ref index even for covering ordering indexes.
Added an assertion to clarify the condition the local variables should
be in.
This commit is contained in:
Georgi Kodinov
2009-07-07 15:52:34 +03:00
parent b12a166d64
commit d9e82ba86c
4 changed files with 166 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
mysql-test/t/innodb_mysql.test
View File

@ -380,4 +380,85 @@ SELECT * FROM t1, t2, t3
DROP TABLE t1, t2, t3;
--echo #
--echo # Bug #45828: Optimizer won't use partial primary key if another
--echo # index can prevent filesort
--echo #
# Create the table
CREATE TABLE `t1` (
c1 int NOT NULL,
c2 int NOT NULL,
c3 int NOT NULL,
PRIMARY KEY (c1,c2),
KEY (c3)
) ENGINE=InnoDB;
# populate with data
INSERT INTO t1 VALUES (5,2,1246276747);
INSERT INTO t1 VALUES (2,1,1246281721);
INSERT INTO t1 VALUES (7,3,1246281756);
INSERT INTO t1 VALUES (4,2,1246282139);
INSERT INTO t1 VALUES (3,1,1246282230);
INSERT INTO t1 VALUES (1,0,1246282712);
INSERT INTO t1 VALUES (8,3,1246282765);
INSERT INTO t1 SELECT c1+10,c2+10,c3+10 FROM t1;
INSERT INTO t1 SELECT c1+100,c2+100,c3+100 from t1;
INSERT INTO t1 SELECT c1+1000,c2+1000,c3+1000 from t1;
INSERT INTO t1 SELECT c1+10000,c2+10000,c3+10000 from t1;
INSERT INTO t1 SELECT c1+100000,c2+100000,c3+100000 from t1;
INSERT INTO t1 SELECT c1+1000000,c2+1000000,c3+1000000 from t1;
# query and no rows will match the c1 condition, whereas all will match c3
SELECT * FROM t1 WHERE c1 = 99999999 AND c3 > 1 ORDER BY c3;
# SHOULD use the pk.
# index on c3 will be used instead of primary key
EXPLAIN SELECT * FROM t1 WHERE c1 = 99999999 AND c3 > 1 ORDER BY c3;
# if we force the primary key, we can see the estimate is 1
EXPLAIN SELECT * FROM t1 FORCE INDEX (PRIMARY) WHERE c1 = 99999999 AND c3 > 1 ORDER BY c3;
CREATE TABLE t2 (
c1 int NOT NULL,
c2 int NOT NULL,
c3 int NOT NULL,
KEY (c1,c2),
KEY (c3)
) ENGINE=InnoDB;
# SHOULD use the pk.
# if we switch it from a primary key to a regular index, it works correctly as well
explain SELECT * FROM t2 WHERE c1 = 99999999 AND c3 > 1 ORDER BY c3;
DROP TABLE t1,t2;
--echo #
--echo # 36259: Optimizing with ORDER BY
--echo #
CREATE TABLE t1 (
a INT NOT NULL AUTO_INCREMENT,
b INT NOT NULL,
c INT NOT NULL,
d VARCHAR(5),
e INT NOT NULL,
PRIMARY KEY (a), KEY i2 (b,c,d)
) ENGINE=InnoDB;
INSERT INTO t1 (b,c,d,e) VALUES (1,1,'a',1), (2,2,'b',2);
INSERT INTO t1 (b,c,d,e) SELECT RAND()*10000, RAND()*10000, d, e FROM t1;
INSERT INTO t1 (b,c,d,e) SELECT RAND()*10000, RAND()*10000, d, e FROM t1;
INSERT INTO t1 (b,c,d,e) SELECT RAND()*10000, RAND()*10000, d, e FROM t1;
INSERT INTO t1 (b,c,d,e) SELECT RAND()*10000, RAND()*10000, d, e FROM t1;
INSERT INTO t1 (b,c,d,e) SELECT RAND()*10000, RAND()*10000, d, e FROM t1;
INSERT INTO t1 (b,c,d,e) SELECT RAND()*10000, RAND()*10000, d, e FROM t1;
EXPLAIN SELECT * FROM t1 WHERE b=1 AND c=1 ORDER BY a;
EXPLAIN SELECT * FROM t1 FORCE INDEX(i2) WHERE b=1 and c=1 ORDER BY a;
EXPLAIN SELECT * FROM t1 FORCE INDEX(PRIMARY) WHERE b=1 AND c=1 ORDER BY a;
DROP TABLE t1;
--echo End of 5.1 tests