2003-01-06 00:48:59 +01:00
# Initialise
--disable_warnings
drop table if exists t1,t2,t3;
--enable_warnings
#
# Simple test without tables
2002-11-24 16:41:34 +01:00
-- error 1111
2002-11-28 18:19:21 +01:00
SELECT 1 FROM (SELECT 1) as a GROUP BY SUM(1);
2003-01-06 00:48:59 +01:00
2000-12-28 02:56:38 +01:00
#
# Test of group (Failed for Lars Hoss <lh@pbm.de>)
#
CREATE TABLE t1 (
spID int(10) unsigned,
userID int(10) unsigned,
score smallint(5) unsigned,
lsg char(40),
date date
);
INSERT INTO t1 VALUES (1,1,1,'','0000-00-00');
INSERT INTO t1 VALUES (2,2,2,'','0000-00-00');
INSERT INTO t1 VALUES (2,1,1,'','0000-00-00');
INSERT INTO t1 VALUES (3,3,3,'','0000-00-00');
CREATE TABLE t2 (
2003-03-22 19:34:20 +01:00
userID int(10) unsigned NOT NULL auto_increment,
2000-12-28 02:56:38 +01:00
niName char(15),
passwd char(8),
mail char(50),
isAukt enum('N','Y') DEFAULT 'N',
vName char(30),
nName char(40),
adr char(60),
plz char(5),
ort char(35),
land char(20),
PRIMARY KEY (userID)
);
INSERT INTO t2 VALUES (1,'name','pass','mail','Y','v','n','adr','1','1','1');
INSERT INTO t2 VALUES (2,'name','pass','mail','Y','v','n','adr','1','1','1');
INSERT INTO t2 VALUES (3,'name','pass','mail','Y','v','n','adr','1','1','1');
2003-04-24 01:23:25 +02:00
INSERT INTO t2 VALUES (4,'name','pass','mail','Y','v','n','adr','1','1','1');
INSERT INTO t2 VALUES (5,'name','pass','mail','Y','v','n','adr','1','1','1');
2000-12-28 02:56:38 +01:00
SELECT t2.userid, MIN(t1.score) FROM t1, t2 WHERE t1.userID=t2.userID GROUP BY t2.userid;
2003-01-28 07:38:28 +01:00
SELECT t2.userid, MIN(t1.score) FROM t1, t2 WHERE t1.userID=t2.userID GROUP BY t2.userid ORDER BY NULL;
2000-12-28 02:56:38 +01:00
SELECT t2.userid, MIN(t1.score) FROM t1, t2 WHERE t1.userID=t2.userID AND t1.spID=2 GROUP BY t2.userid;
SELECT t2.userid, MIN(t1.score+0.0) FROM t1, t2 WHERE t1.userID=t2.userID AND t1.spID=2 GROUP BY t2.userid;
2003-01-28 07:38:28 +01:00
SELECT t2.userid, MIN(t1.score+0.0) FROM t1, t2 WHERE t1.userID=t2.userID AND t1.spID=2 GROUP BY t2.userid ORDER BY NULL;
2003-04-23 20:52:16 +02:00
EXPLAIN SELECT t2.userid, MIN(t1.score+0.0) FROM t1, t2 WHERE t1.userID=t2.userID AND t1.spID=2 GROUP BY t2.userid ORDER BY NULL;
2003-01-06 00:48:59 +01:00
drop table t1,t2;
2000-12-28 02:56:38 +01:00
#
# Bug in GROUP BY, by Nikki Chumakov <nikki@saddam.cityline.ru>
#
CREATE TABLE t1 (
2003-03-22 19:34:20 +01:00
PID int(10) unsigned NOT NULL auto_increment,
2000-12-28 02:56:38 +01:00
payDate date DEFAULT '0000-00-00' NOT NULL,
recDate datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
URID int(10) unsigned DEFAULT '0' NOT NULL,
CRID int(10) unsigned DEFAULT '0' NOT NULL,
amount int(10) unsigned DEFAULT '0' NOT NULL,
operator int(10) unsigned,
method enum('unknown','cash','dealer','check','card','lazy','delayed','test') DEFAULT 'unknown' NOT NULL,
DIID int(10) unsigned,
reason char(1) binary DEFAULT '' NOT NULL,
code_id int(10) unsigned,
qty mediumint(8) unsigned DEFAULT '0' NOT NULL,
PRIMARY KEY (PID),
KEY URID (URID),
KEY reason (reason),
KEY method (method),
KEY payDate (payDate)
);
INSERT INTO t1 VALUES (1,'1970-01-01','1997-10-17 00:00:00',2529,1,21000,11886,'check',0,'F',16200,6);
2003-03-13 13:44:03 +01:00
--error 1056
SELECT COUNT(P.URID),SUM(P.amount),P.method, MIN(PP.recdate+0) > 19980501000000 AS IsNew FROM t1 AS P JOIN t1 as PP WHERE P.URID = PP.URID GROUP BY method,IsNew;
2000-12-28 02:56:38 +01:00
drop table t1;
#
# Problem with GROUP BY + ORDER BY when no match
# Tested with locking
#
CREATE TABLE t1 (
2003-03-22 19:34:20 +01:00
cid mediumint(9) NOT NULL auto_increment,
2000-12-28 02:56:38 +01:00
firstname varchar(32) DEFAULT '' NOT NULL,
surname varchar(32) DEFAULT '' NOT NULL,
PRIMARY KEY (cid)
);
INSERT INTO t1 VALUES (1,'That','Guy');
INSERT INTO t1 VALUES (2,'Another','Gent');
CREATE TABLE t2 (
2003-03-22 19:34:20 +01:00
call_id mediumint(8) NOT NULL auto_increment,
2000-12-28 02:56:38 +01:00
contact_id mediumint(8) DEFAULT '0' NOT NULL,
PRIMARY KEY (call_id),
KEY contact_id (contact_id)
);
lock tables t1 read,t2 write;
INSERT INTO t2 VALUES (10,2);
INSERT INTO t2 VALUES (18,2);
INSERT INTO t2 VALUES (62,2);
INSERT INTO t2 VALUES (91,2);
INSERT INTO t2 VALUES (92,2);
SELECT cid, CONCAT(firstname, ' ', surname), COUNT(call_id) FROM t1 LEFT JOIN t2 ON cid=contact_id WHERE firstname like '%foo%' GROUP BY cid;
2003-01-28 07:38:28 +01:00
SELECT cid, CONCAT(firstname, ' ', surname), COUNT(call_id) FROM t1 LEFT JOIN t2 ON cid=contact_id WHERE firstname like '%foo%' GROUP BY cid ORDER BY NULL;
2000-12-28 02:56:38 +01:00
SELECT HIGH_PRIORITY cid, CONCAT(firstname, ' ', surname), COUNT(call_id) FROM t1 LEFT JOIN t2 ON cid=contact_id WHERE firstname like '%foo%' GROUP BY cid ORDER BY surname, firstname;
Backport of:
------------------------------------------------------------
revno: 2476.784.3
committer: davi@moksha.local
timestamp: Tue 2007-10-02 21:27:31 -0300
message:
Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
When a client (connection) holds a lock on a table and attempts to
drop (obtain a exclusive lock) on a second table that is already
held by a second client and the second client then attempts to
drop the table that is held by the first client, leads to a
circular wait deadlock. This scenario is very similar to trying to
drop (or rename) a table while holding read locks and are
correctly forbidden.
The solution is to allow a drop table operation to continue only
if the table being dropped is write (exclusively) locked, or if
the table is temporary, or if the client is not holding any
locks. Using this scheme prevents the creation of a circular
chain in which each client is waiting for one table that the
next client in the chain is holding.
This is incompatible change, as can be seen by number of tests
cases that needed to be fixed, but is consistent with respect to
behavior of the different scenarios in which the circular wait
might happen.
mysql-test/r/drop.result:
Test case result for Bug#25858
mysql-test/r/group_by.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/insert_notembedded.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table
mysql-test/r/lock.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/lock_multi.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/myisam.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/view.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/t/drop.test:
Add test case for Bug#25858
mysql-test/t/group_by.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/insert_notembedded.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock_multi.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/myisam.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/query_cache_notembedded.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/view.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
sql/lock.cc:
When trying to obtain a name lock under lock tables, ensure that the table is properly exclusively locked and fail otherwise.
2009-11-20 20:51:12 +01:00
drop table t2;
2000-12-28 02:56:38 +01:00
unlock tables;
Backport of:
------------------------------------------------------------
revno: 2476.784.3
committer: davi@moksha.local
timestamp: Tue 2007-10-02 21:27:31 -0300
message:
Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
When a client (connection) holds a lock on a table and attempts to
drop (obtain a exclusive lock) on a second table that is already
held by a second client and the second client then attempts to
drop the table that is held by the first client, leads to a
circular wait deadlock. This scenario is very similar to trying to
drop (or rename) a table while holding read locks and are
correctly forbidden.
The solution is to allow a drop table operation to continue only
if the table being dropped is write (exclusively) locked, or if
the table is temporary, or if the client is not holding any
locks. Using this scheme prevents the creation of a circular
chain in which each client is waiting for one table that the
next client in the chain is holding.
This is incompatible change, as can be seen by number of tests
cases that needed to be fixed, but is consistent with respect to
behavior of the different scenarios in which the circular wait
might happen.
mysql-test/r/drop.result:
Test case result for Bug#25858
mysql-test/r/group_by.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/insert_notembedded.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table
mysql-test/r/lock.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/lock_multi.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/myisam.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/view.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/t/drop.test:
Add test case for Bug#25858
mysql-test/t/group_by.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/insert_notembedded.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock_multi.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/myisam.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/query_cache_notembedded.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/view.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
sql/lock.cc:
When trying to obtain a name lock under lock tables, ensure that the table is properly exclusively locked and fail otherwise.
2009-11-20 20:51:12 +01:00
drop table t1;
2000-12-28 02:56:38 +01:00
#
# Test of group by bug in bugzilla
#
CREATE TABLE t1 (
2003-03-22 19:34:20 +01:00
bug_id mediumint(9) NOT NULL auto_increment,
2000-12-28 02:56:38 +01:00
groupset bigint(20) DEFAULT '0' NOT NULL,
assigned_to mediumint(9) DEFAULT '0' NOT NULL,
bug_file_loc text,
bug_severity enum('blocker','critical','major','normal','minor','trivial','enhancement') DEFAULT 'blocker' NOT NULL,
2003-08-18 23:08:08 +02:00
bug_status enum('','NEW','ASSIGNED','REOPENED','RESOLVED','VERIFIED','CLOSED') DEFAULT 'NEW' NOT NULL,
2000-12-28 02:56:38 +01:00
creation_ts datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
bug#10466: Datatype "timestamp" displays "YYYYMMDDHHMMSS" irrespective of display sizes.
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width.
- Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
mysql-test/include/ps_create.inc:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/alias.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_date_add.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_str.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/func_time.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/group_by.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/innodb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_1general.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_2myisam.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_3innodb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_4heap.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_5merge.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_6bdb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/ps_7ndb.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/select.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/r/type_timestamp.result:
When display width is used for a TIMESTAMP column a warning is printed that the display width will be ignored.
mysql-test/r/update.result:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/alias.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_date_add.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_str.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/func_time.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/group_by.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/innodb.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps_4heap.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/ps_5merge.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/select.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
mysql-test/t/update.test:
Reove all uses of display width in for TIMESTAMP columns, except in the type_timestamp test.
sql/share/errmsg.txt:
Correct swedish error message
sql/sql_parse.cc:
Print warning if datatype is TIMESTAMP and display width is used.
2005-06-20 12:09:00 +02:00
delta_ts timestamp,
2000-12-28 02:56:38 +01:00
short_desc mediumtext,
long_desc mediumtext,
op_sys enum('All','Windows 3.1','Windows 95','Windows 98','Windows NT','Windows 2000','Linux','other') DEFAULT 'All' NOT NULL,
priority enum('P1','P2','P3','P4','P5') DEFAULT 'P1' NOT NULL,
product varchar(64) DEFAULT '' NOT NULL,
rep_platform enum('All','PC','VTD-8','Other'),
reporter mediumint(9) DEFAULT '0' NOT NULL,
version varchar(16) DEFAULT '' NOT NULL,
component varchar(50) DEFAULT '' NOT NULL,
resolution enum('','FIXED','INVALID','WONTFIX','LATER','REMIND','DUPLICATE','WORKSFORME') DEFAULT '' NOT NULL,
target_milestone varchar(20) DEFAULT '' NOT NULL,
qa_contact mediumint(9) DEFAULT '0' NOT NULL,
status_whiteboard mediumtext NOT NULL,
votes mediumint(9) DEFAULT '0' NOT NULL,
PRIMARY KEY (bug_id),
KEY assigned_to (assigned_to),
KEY creation_ts (creation_ts),
KEY delta_ts (delta_ts),
KEY bug_severity (bug_severity),
KEY bug_status (bug_status),
KEY op_sys (op_sys),
KEY priority (priority),
KEY product (product),
KEY reporter (reporter),
KEY version (version),
KEY component (component),
KEY resolution (resolution),
KEY target_milestone (target_milestone),
KEY qa_contact (qa_contact),
KEY votes (votes)
);
INSERT INTO t1 VALUES (1,0,0,'','normal','','2000-02-10 09:25:12',20000321114747,'','','Linux','P1','TestProduct','PC',3,'other','TestComponent','','M1',0,'',0);
INSERT INTO t1 VALUES (9,0,0,'','enhancement','','2000-03-10 11:49:36',20000321114747,'','','All','P5','AAAAA','PC',3,'2.00 CD - Pre','BBBBBBBBBBBBB - conversion','','',0,'',0);
INSERT INTO t1 VALUES (10,0,0,'','enhancement','','2000-03-10 18:10:16',20000321114747,'','','All','P4','AAAAA','PC',3,'2.00 CD - Pre','BBBBBBBBBBBBB - conversion','','',0,'',0);
INSERT INTO t1 VALUES (7,0,0,'','critical','','2000-03-09 10:50:21',20000321114747,'','','All','P1','AAAAA','PC',3,'2.00 CD - Pre','BBBBBBBBBBBBB - generic','','',0,'',0);
INSERT INTO t1 VALUES (6,0,0,'','normal','','2000-03-09 10:42:44',20000321114747,'','','All','P2','AAAAA','PC',3,'2.00 CD - Pre','kkkkkkkkkkk lllllllllll','','',0,'',0);
INSERT INTO t1 VALUES (8,0,0,'','major','','2000-03-09 11:32:14',20000321114747,'','','All','P3','AAAAA','PC',3,'2.00 CD - Pre','kkkkkkkkkkk lllllllllll','','',0,'',0);
INSERT INTO t1 VALUES (5,0,0,'','enhancement','','2000-03-09 10:38:59',20000321114747,'','','All','P5','CCC/CCCCCC','PC',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (4,0,0,'','normal','','2000-03-08 18:32:14',20000321114747,'','','other','P2','TestProduct','Other',3,'other','TestComponent2','','',0,'',0);
INSERT INTO t1 VALUES (3,0,0,'','normal','','2000-03-08 18:30:52',20000321114747,'','','other','P2','TestProduct','Other',3,'other','TestComponent','','',0,'',0);
INSERT INTO t1 VALUES (2,0,0,'','enhancement','','2000-03-08 18:24:51',20000321114747,'','','All','P2','TestProduct','Other',4,'other','TestComponent2','','',0,'',0);
INSERT INTO t1 VALUES (11,0,0,'','blocker','','2000-03-13 09:43:41',20000321114747,'','','All','P2','CCC/CCCCCC','PC',5,'7.00','DDDDDDDDD','','',0,'',0);
INSERT INTO t1 VALUES (12,0,0,'','normal','','2000-03-13 16:14:31',20000321114747,'','','All','P2','AAAAA','PC',3,'2.00 CD - Pre','kkkkkkkkkkk lllllllllll','','',0,'',0);
INSERT INTO t1 VALUES (13,0,0,'','normal','','2000-03-15 16:20:44',20000321114747,'','','other','P2','TestProduct','Other',3,'other','TestComponent','','',0,'',0);
INSERT INTO t1 VALUES (14,0,0,'','blocker','','2000-03-15 18:13:47',20000321114747,'','','All','P1','AAAAA','PC',3,'2.00 CD - Pre','BBBBBBBBBBBBB - generic','','',0,'',0);
INSERT INTO t1 VALUES (15,0,0,'','minor','','2000-03-16 18:03:28',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','DDDDDDDDD','','',0,'',0);
INSERT INTO t1 VALUES (16,0,0,'','normal','','2000-03-16 18:33:41',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (17,0,0,'','normal','','2000-03-16 18:34:18',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (18,0,0,'','normal','','2000-03-16 18:34:56',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (19,0,0,'','enhancement','','2000-03-16 18:35:34',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (20,0,0,'','enhancement','','2000-03-16 18:36:23',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (21,0,0,'','enhancement','','2000-03-16 18:37:23',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (22,0,0,'','enhancement','','2000-03-16 18:38:16',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','Administration','','',0,'',0);
INSERT INTO t1 VALUES (23,0,0,'','normal','','2000-03-16 18:58:12',20000321114747,'','','All','P2','CCC/CCCCCC','Other',5,'7.00','DDDDDDDDD','','',0,'',0);
INSERT INTO t1 VALUES (24,0,0,'','normal','','2000-03-17 11:08:10',20000321114747,'','','All','P2','AAAAAAAA-AAA','PC',3,'2.8','Web Interface','','',0,'',0);
INSERT INTO t1 VALUES (25,0,0,'','normal','','2000-03-17 11:10:45',20000321114747,'','','All','P2','AAAAAAAA-AAA','PC',3,'2.8','Web Interface','','',0,'',0);
INSERT INTO t1 VALUES (26,0,0,'','normal','','2000-03-17 11:15:47',20000321114747,'','','All','P2','AAAAAAAA-AAA','PC',3,'2.8','Web Interface','','',0,'',0);
INSERT INTO t1 VALUES (27,0,0,'','normal','','2000-03-17 17:45:41',20000321114747,'','','All','P2','CCC/CCCCCC','PC',5,'7.00','DDDDDDDDD','','',0,'',0);
INSERT INTO t1 VALUES (28,0,0,'','normal','','2000-03-20 09:51:45',20000321114747,'','','Windows NT','P2','TestProduct','PC',8,'other','TestComponent','','',0,'',0);
INSERT INTO t1 VALUES (29,0,0,'','normal','','2000-03-20 11:15:09',20000321114747,'','','All','P5','AAAAAAAA-AAA','PC',3,'2.8','Web Interface','','',0,'',0);
CREATE TABLE t2 (
value tinytext,
program varchar(64),
initialowner tinytext NOT NULL,
initialqacontact tinytext NOT NULL,
description mediumtext NOT NULL
);
INSERT INTO t2 VALUES ('TestComponent','TestProduct','id0001','','');
INSERT INTO t2 VALUES ('BBBBBBBBBBBBB - conversion','AAAAA','id0001','','');
INSERT INTO t2 VALUES ('BBBBBBBBBBBBB - generic','AAAAA','id0001','','');
INSERT INTO t2 VALUES ('TestComponent2','TestProduct','id0001','','');
INSERT INTO t2 VALUES ('BBBBBBBBBBBBB - eeeeeeeee','AAAAA','id0001','','');
INSERT INTO t2 VALUES ('kkkkkkkkkkk lllllllllll','AAAAA','id0001','','');
INSERT INTO t2 VALUES ('Test Procedures','AAAAA','id0001','','');
INSERT INTO t2 VALUES ('Documentation','AAAAA','id0003','','');
INSERT INTO t2 VALUES ('DDDDDDDDD','CCC/CCCCCC','id0002','','');
INSERT INTO t2 VALUES ('Eeeeeeee Lite','CCC/CCCCCC','id0002','','');
INSERT INTO t2 VALUES ('Eeeeeeee Full','CCC/CCCCCC','id0002','','');
INSERT INTO t2 VALUES ('Administration','CCC/CCCCCC','id0002','','');
INSERT INTO t2 VALUES ('Distribution','CCC/CCCCCC','id0002','','');
INSERT INTO t2 VALUES ('Setup','CCC/CCCCCC','id0002','','');
INSERT INTO t2 VALUES ('Unspecified','CCC/CCCCCC','id0002','','');
INSERT INTO t2 VALUES ('Web Interface','AAAAAAAA-AAA','id0001','','');
INSERT INTO t2 VALUES ('Host communication','AAAAA','id0001','','');
select value,description,bug_id from t2 left join t1 on t2.program=t1.product and t2.value=t1.component where program="AAAAA";
select value,description,COUNT(bug_id) from t2 left join t1 on t2.program=t1.product and t2.value=t1.component where program="AAAAA" group by value;
2002-11-30 17:38:44 +01:00
select value,description,COUNT(bug_id) from t2 left join t1 on t2.program=t1.product and t2.value=t1.component where program="AAAAA" group by value having COUNT(bug_id) IN (0,2);
2000-12-28 02:56:38 +01:00
drop table t1,t2;
2001-04-21 16:12:59 +02:00
#
# Problem with functions and group functions when no matching rows
#
create table t1 (foo int);
insert into t1 values (1);
select 1+1, "a",count(*) from t1 where foo in (2);
insert into t1 values (1);
select 1+1,"a",count(*) from t1 where foo in (2);
drop table t1;
2001-12-10 16:51:07 +01:00
#
# Test GROUP BY DESC
CREATE TABLE t1 (
spID int(10) unsigned,
userID int(10) unsigned,
score smallint(5) unsigned,
key (spid),
key (score)
);
2003-04-23 20:52:16 +02:00
INSERT INTO t1 VALUES (1,1,1),(2,2,2),(2,1,1),(3,3,3),(4,3,3),(5,3,3),(6,3,3),(7,3,3);
2001-12-10 16:51:07 +01:00
explain select userid,count(*) from t1 group by userid desc;
2003-01-28 07:38:28 +01:00
explain select userid,count(*) from t1 group by userid desc order by null;
2001-12-10 16:51:07 +01:00
select userid,count(*) from t1 group by userid desc;
2002-12-02 13:16:02 +01:00
select userid,count(*) from t1 group by userid desc having (count(*)+1) IN (4,3);
select userid,count(*) from t1 group by userid desc having 3 IN (1,COUNT(*));
2001-12-10 16:51:07 +01:00
explain select spid,count(*) from t1 where spid between 1 and 2 group by spid desc;
explain select spid,count(*) from t1 where spid between 1 and 2 group by spid;
2003-01-28 07:38:28 +01:00
explain select spid,count(*) from t1 where spid between 1 and 2 group by spid order by null;
2001-12-10 16:51:07 +01:00
select spid,count(*) from t1 where spid between 1 and 2 group by spid;
select spid,count(*) from t1 where spid between 1 and 2 group by spid desc;
2003-10-30 11:57:26 +01:00
explain extended select sql_big_result spid,sum(userid) from t1 group by spid desc;
2003-01-28 07:38:28 +01:00
explain select sql_big_result spid,sum(userid) from t1 group by spid desc order by null;
2001-12-10 16:51:07 +01:00
select sql_big_result spid,sum(userid) from t1 group by spid desc;
explain select sql_big_result score,count(*) from t1 group by score desc;
2003-01-28 07:38:28 +01:00
explain select sql_big_result score,count(*) from t1 group by score desc order by null;
2001-12-10 16:51:07 +01:00
select sql_big_result score,count(*) from t1 group by score desc;
drop table t1;
2002-01-15 23:42:52 +01:00
2003-03-13 13:44:03 +01:00
# not purely group_by bug, but group_by is involved...
create table t1 (a date default null, b date default null);
insert t1 values ('1999-10-01','2000-01-10'), ('1997-01-01','1998-10-01');
select a,min(b) c,count(distinct rand()) from t1 group by a having c<a + interval 1 day;
drop table t1;
2002-01-15 23:42:52 +01:00
# Compare with hash keys
CREATE TABLE t1 (a char(1));
INSERT INTO t1 VALUES ('A'),('B'),('A'),('B'),('A'),('B'),(NULL),('a'),('b'),(NULL),('A'),('B'),(NULL);
SELECT a FROM t1 GROUP BY a;
SELECT a,count(*) FROM t1 GROUP BY a;
SELECT a FROM t1 GROUP BY binary a;
SELECT a,count(*) FROM t1 GROUP BY binary a;
SELECT binary a FROM t1 GROUP BY 1;
SELECT binary a,count(*) FROM t1 GROUP BY 1;
# Do the same tests with MyISAM temporary tables
fixes for test failures
and small collateral changes
mysql-test/lib/My/Test.pm:
somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
this differs, because we don't rewrite general log queries, and multi-statement
packets are logged as a one entry. this result file is identical to what mysql-5.6.5
produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged
2012-09-27 20:09:46 +02:00
SET BIG_TABLES=1;
2002-01-15 23:42:52 +01:00
SELECT a FROM t1 GROUP BY a;
SELECT a,count(*) FROM t1 GROUP BY a;
SELECT a FROM t1 GROUP BY binary a;
SELECT a,count(*) FROM t1 GROUP BY binary a;
SELECT binary a FROM t1 GROUP BY 1;
SELECT binary a,count(*) FROM t1 GROUP BY 1;
fixes for test failures
and small collateral changes
mysql-test/lib/My/Test.pm:
somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
this differs, because we don't rewrite general log queries, and multi-statement
packets are logged as a one entry. this result file is identical to what mysql-5.6.5
produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged
2012-09-27 20:09:46 +02:00
SET BIG_TABLES=0;
2002-01-15 23:42:52 +01:00
drop table t1;
2002-01-16 22:02:26 +01:00
#
# Test of key >= 256 bytes
#
CREATE TABLE t1 (
`a` char(193) default NULL,
`b` char(63) default NULL
);
INSERT INTO t1 VALUES ('abc','def'),('hij','klm');
SELECT CONCAT(a, b) FROM t1 GROUP BY 1;
SELECT CONCAT(a, b),count(*) FROM t1 GROUP BY 1;
SELECT CONCAT(a, b),count(distinct a) FROM t1 GROUP BY 1;
SELECT 1 FROM t1 GROUP BY CONCAT(a, b);
INSERT INTO t1 values ('hij','klm');
SELECT CONCAT(a, b),count(*) FROM t1 GROUP BY 1;
DROP TABLE t1;
2002-06-09 14:41:19 +02:00
#
# Test problem with ORDER BY on a SUM() column
#
2002-05-24 17:34:34 +02:00
create table t1 (One int unsigned, Two int unsigned, Three int unsigned, Four int unsigned);
2002-06-09 14:41:19 +02:00
insert into t1 values (1,2,1,4),(1,2,2,4),(1,2,3,4),(1,2,4,4),(1,1,1,4),(1,1,2,4),(1,1,3,4),(1,1,4,4),(1,3,1,4),(1,3,2,4),(1,3,3,4),(1,3,4,4);
2002-05-24 17:34:34 +02:00
select One, Two, sum(Four) from t1 group by One,Two;
2002-06-09 14:41:19 +02:00
drop table t1;
2002-06-08 19:02:49 +02:00
create table t1 (id integer primary key not null auto_increment, gender char(1));
2002-06-09 14:41:19 +02:00
insert into t1 values (NULL, 'M'), (NULL, 'F'),(NULL, 'F'),(NULL, 'F'),(NULL, 'M');
create table t2 (user_id integer not null, date date);
insert into t2 values (1, '2002-06-09'),(2, '2002-06-09'),(1, '2002-06-09'),(3, '2002-06-09'),(4, '2002-06-09'),(4, '2002-06-09');
2002-06-08 19:02:49 +02:00
select u.gender as gender, count(distinct u.id) as dist_count, (count(distinct u.id)/5*100) as percentage from t1 u, t2 l where l.user_id = u.id group by u.gender;
select u.gender as gender, count(distinct u.id) as dist_count, (count(distinct u.id)/5*100) as percentage from t1 u, t2 l where l.user_id = u.id group by u.gender order by percentage;
drop table t1,t2;
2002-08-05 17:10:53 +02:00
#
# The GROUP BY returned rows in wrong order in 3.23.51
#
CREATE TABLE t1 (ID1 int, ID2 int, ID int NOT NULL AUTO_INCREMENT,PRIMARY KEY(ID
));
insert into t1 values (1,244,NULL),(2,243,NULL),(134,223,NULL),(185,186,NULL);
2011-12-15 09:21:15 +01:00
SET @save_optimizer_switch=@@optimizer_switch;
SET optimizer_switch='outer_join_with_cache=off';
2002-08-05 17:10:53 +02:00
select S.ID as xID, S.ID1 as xID1 from t1 as S left join t1 as yS on S.ID1 between yS.ID1 and yS.ID2;
select S.ID as xID, S.ID1 as xID1, repeat('*',count(distinct yS.ID)) as Level from t1 as S left join t1 as yS on S.ID1 between yS.ID1 and yS.ID2 group by xID order by xID1;
2011-12-15 09:21:15 +01:00
SET optimizer_switch=@save_optimizer_switch;
2002-08-05 17:10:53 +02:00
drop table t1;
2002-11-09 08:51:03 +01:00
#
# Problem with MAX and LEFT JOIN
#
CREATE TABLE t1 (
pid int(11) unsigned NOT NULL default '0',
c1id int(11) unsigned default NULL,
c2id int(11) unsigned default NULL,
value int(11) unsigned NOT NULL default '0',
UNIQUE KEY pid2 (pid,c1id,c2id),
UNIQUE KEY pid (pid,value)
2003-12-10 05:31:42 +01:00
) ENGINE=MyISAM;
2002-11-09 08:51:03 +01:00
INSERT INTO t1 VALUES (1, 1, NULL, 1),(1, 2, NULL, 2),(1, NULL, 3, 3),(1, 4, NULL, 4),(1, 5, NULL, 5);
CREATE TABLE t2 (
id int(11) unsigned NOT NULL default '0',
active enum('Yes','No') NOT NULL default 'Yes',
PRIMARY KEY (id)
2003-12-10 05:31:42 +01:00
) ENGINE=MyISAM;
2002-11-09 08:51:03 +01:00
INSERT INTO t2 VALUES (1, 'Yes'),(2, 'No'),(4, 'Yes'),(5, 'No');
CREATE TABLE t3 (
id int(11) unsigned NOT NULL default '0',
active enum('Yes','No') NOT NULL default 'Yes',
PRIMARY KEY (id)
);
INSERT INTO t3 VALUES (3, 'Yes');
select * from t1 AS m LEFT JOIN t2 AS c1 ON m.c1id =
c1.id AND c1.active = 'Yes' LEFT JOIN t3 AS c2 ON m.c2id = c2.id AND
c2.active = 'Yes' WHERE m.pid=1 AND (c1.id IS NOT NULL OR c2.id IS NOT NULL);
select max(value) from t1 AS m LEFT JOIN t2 AS c1 ON
m.c1id = c1.id AND c1.active = 'Yes' LEFT JOIN t3 AS c2 ON m.c2id =
c2.id AND c2.active = 'Yes' WHERE m.pid=1 AND (c1.id IS NOT NULL OR c2.id IS
NOT NULL);
drop table t1,t2,t3;
2002-12-27 20:39:35 +01:00
#
# Test bug in GROUP BY on BLOB that is NULL or empty
#
create table t1 (a blob null);
insert into t1 values (NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(""),(""),(""),("b");
select a,count(*) from t1 group by a;
fixes for test failures
and small collateral changes
mysql-test/lib/My/Test.pm:
somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
this differs, because we don't rewrite general log queries, and multi-statement
packets are logged as a one entry. this result file is identical to what mysql-5.6.5
produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged
2012-09-27 20:09:46 +02:00
set big_tables=1;
2002-12-27 20:39:35 +01:00
select a,count(*) from t1 group by a;
drop table t1;
2003-01-28 07:38:28 +01:00
#
# Test of GROUP BY ... ORDER BY NULL optimization
#
create table t1 (a int not null, b int not null);
insert into t1 values (1,1),(1,2),(3,1),(3,2),(2,2),(2,1);
create table t2 (a int not null, b int not null, key(a));
insert into t2 values (1,3),(3,1),(2,2),(1,1);
select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b;
select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b ORDER BY NULL;
explain select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b;
explain select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b ORDER BY NULL;
drop table t1,t2;
2003-01-29 09:38:56 +01:00
#
# group function arguments in some functions
#
create table t1 (a int, b int);
2003-04-23 20:52:16 +02:00
insert into t1 values (1, 4),(10, 40),(1, 4),(10, 43),(1, 4),(10, 41),(1, 4),(10, 43),(1, 4);
2003-01-29 09:38:56 +01:00
select a, MAX(b), INTERVAL (MAX(b), 1,3,10,30,39,40,50,60,100,1000) from t1 group by a;
select a, MAX(b), CASE MAX(b) when 4 then 4 when 43 then 43 else 0 end from t1 group by a;
select a, MAX(b), FIELD(MAX(b), '43', '4', '5') from t1 group by a;
select a, MAX(b), CONCAT_WS(MAX(b), '43', '4', '5') from t1 group by a;
select a, MAX(b), ELT(MAX(b), 'a', 'b', 'c', 'd', 'e', 'f') from t1 group by a;
select a, MAX(b), MAKE_SET(MAX(b), 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h') from t1 group by a;
drop table t1;
2003-03-25 12:06:20 +01:00
#
# Problem with group by and alias
#
create table t1 (id int not null, qty int not null);
insert into t1 values (1,2),(1,3),(2,4),(2,5);
select id, sum(qty) as sqty, count(qty) as cqty from t1 group by id having sum(qty)>2 and cqty>1;
select id, sum(qty) as sqty from t1 group by id having sqty>2 and count(qty)>1;
select id, sum(qty) as sqty, count(qty) as cqty from t1 group by id having sqty>2 and cqty>1;
select id, sum(qty) as sqty, count(qty) as cqty from t1 group by id having sum(qty)>2 and count(qty)>1;
2003-07-09 21:33:26 +02:00
select count(*), case interval(qty,2,3,4,5,6,7,8) when -1 then NULL when 0 then "zero" when 1 then "one" when 2 then "two" end as category from t1 group by category;
select count(*), interval(qty,2,3,4,5,6,7,8) as category from t1 group by category;
2003-03-25 12:06:20 +01:00
drop table t1;
2003-12-09 21:52:58 +01:00
#
# Tests for bug #1355: 'Using filesort' is missing in EXPLAIN when ORDER BY
# NULL is used.
#
CREATE TABLE t1 (
userid int(10) unsigned,
score smallint(5) unsigned,
key (score)
);
INSERT INTO t1 VALUES (1,1),(2,2),(1,1),(3,3),(3,3),(3,3),(3,3),(3,3);
# Here we select unordered GROUP BY into a temporary talbe,
# and then sort it with filesort (GROUP BY in MySQL
# implies sorted order of results)
SELECT userid,count(*) FROM t1 GROUP BY userid DESC;
EXPLAIN SELECT userid,count(*) FROM t1 GROUP BY userid DESC;
DROP TABLE t1;
CREATE TABLE t1 (
i int(11) default NULL,
j int(11) default NULL
);
INSERT INTO t1 VALUES (1,2),(2,3),(4,5),(3,5),(1,5),(23,5);
SELECT i, COUNT(DISTINCT(i)) FROM t1 GROUP BY j ORDER BY NULL;
explain SELECT i, COUNT(DISTINCT(i)) FROM t1 GROUP BY j ORDER BY NULL;
DROP TABLE t1;
2004-09-08 20:43:37 +02:00
2005-02-07 17:13:57 +01:00
#Test for BUG#6976: Aggregate functions have incorrect NULL-ness
create table t1 (a int);
insert into t1 values(null);
select min(a) is null from t1;
select min(a) is null or null from t1;
select 1 and min(a) is null from t1;
drop table t1;
2004-09-08 20:43:37 +02:00
# Test for BUG#5400: GROUP_CONCAT returns everything twice.
create table t1 ( col1 int, col2 int );
insert into t1 values (1,1),(1,2),(1,3),(2,1),(2,2);
select group_concat( distinct col1 ) as alias from t1
group by col2 having alias like '%';
drop table t1;
2005-02-07 17:13:57 +01:00
#
# Test BUG#8216 when referring in HAVING to n alias which is rand() function
#
2004-12-11 18:13:43 +01:00
2005-02-07 17:13:57 +01:00
create table t1 (a integer, b integer, c integer);
insert into t1 (a,b) values (1,2),(1,3),(2,5);
select a, 0.1*0+1 r2, sum(1) r1 from t1 where a = 1 group by a having r1>1 and r2=1;
2005-02-08 13:41:09 +01:00
# rand(100)*10 will be < 2 only for the first row (of 6)
select a, round(rand(100)*10) r2, sum(1) r1 from t1 where a = 1 group by a having r1>1 and r2<=2;
2005-02-07 17:13:57 +01:00
select a,sum(b) from t1 where a=1 group by c;
select a*sum(b) from t1 where a=1 group by c;
select sum(a)*sum(b) from t1 where a=1 group by c;
select a,sum(b) from t1 where a=1 group by c having a=1;
select a as d,sum(b) from t1 where a=1 group by c having d=1;
select sum(a)*sum(b) as d from t1 where a=1 group by c having d > 0;
2004-12-11 17:59:09 +01:00
drop table t1;
2005-03-30 13:57:42 +02:00
# Test for BUG#9213 GROUP BY query on utf-8 key returns wrong results
create table t1(a int);
insert into t1 values (0),(1),(2),(3),(4),(5),(6),(8),(9);
create table t2 (
a int,
b varchar(200) NOT NULL,
c varchar(50) NOT NULL,
d varchar(100) NOT NULL,
primary key (a,b(132),c,d),
key a (a,b)
) charset=utf8;
insert into t2 select
x3.a, -- 3
concat('val-', x3.a + 3*x4.a), -- 12
concat('val-', @a:=x3.a + 3*x4.a + 12*C.a), -- 120
concat('val-', @a + 120*D.a)
from t1 x3, t1 x4, t1 C, t1 D where x3.a < 3 and x4.a < 4 and D.a < 4;
2005-03-31 18:23:10 +02:00
delete from t2 where a = 2 and b = 'val-2' order by a,b,c,d limit 30;
2005-03-30 13:57:42 +02:00
explain select c from t2 where a = 2 and b = 'val-2' group by c;
select c from t2 where a = 2 and b = 'val-2' group by c;
drop table t1,t2;
2005-04-18 05:26:23 +02:00
# Test for BUG#9298 "Wrong handling of int4 unsigned columns in GROUP functions"
# (the actual problem was with protocol code, not GROUP BY)
create table t1 (b int4 unsigned not null);
insert into t1 values(3000000000);
select * from t1;
select min(b) from t1;
drop table t1;
2005-06-07 12:05:57 +02:00
#
2005-06-16 18:45:41 +02:00
# Test for bug #11088: GROUP BY a BLOB column with COUNT(DISTINCT column1)
2005-06-07 12:05:57 +02:00
#
CREATE TABLE t1 (id int PRIMARY KEY, user_id int, hostname longtext);
INSERT INTO t1 VALUES
(1, 7, 'cache-dtc-af05.proxy.aol.com'),
(2, 3, 'what.ever.com'),
(3, 7, 'cache-dtc-af05.proxy.aol.com'),
(4, 7, 'cache-dtc-af05.proxy.aol.com');
SELECT hostname, COUNT(DISTINCT user_id) as no FROM t1
WHERE hostname LIKE '%aol%'
GROUP BY hostname;
2005-06-16 18:45:41 +02:00
DROP TABLE t1;
#
2005-06-20 19:49:04 +02:00
# Test for bug #8614: GROUP BY 'const' with DISTINCT
2005-06-16 18:45:41 +02:00
#
CREATE TABLE t1 (a int, b int);
INSERT INTO t1 VALUES (1,2), (1,3);
SELECT a, b FROM t1 GROUP BY 'const';
SELECT DISTINCT a, b FROM t1 GROUP BY 'const';
DROP TABLE t1;
2005-06-20 19:49:04 +02:00
#
# Test for bug #11385: GROUP BY for datetime converted to decimals
#
CREATE TABLE t1 (id INT, dt DATETIME);
INSERT INTO t1 VALUES ( 1, '2005-05-01 12:30:00' );
INSERT INTO t1 VALUES ( 1, '2005-05-01 12:30:00' );
INSERT INTO t1 VALUES ( 1, '2005-05-01 12:30:00' );
INSERT INTO t1 VALUES ( 1, '2005-05-01 12:30:00' );
SELECT dt DIV 1 AS f, id FROM t1 GROUP BY f;
DROP TABLE t1;
2005-06-21 13:24:21 +02:00
#
# Test for bug #11295: GROUP BY a BLOB column with COUNT(DISTINCT column1)
# when the BLOB column takes NULL values
#
CREATE TABLE t1 (id varchar(20) NOT NULL);
INSERT INTO t1 VALUES ('trans1'), ('trans2');
CREATE TABLE t2 (id varchar(20) NOT NULL, err_comment blob NOT NULL);
INSERT INTO t2 VALUES ('trans1', 'a problem');
2005-09-09 10:57:00 +02:00
SELECT COUNT(DISTINCT(t1.id)), LEFT(err_comment, 256) AS comment
FROM t1 LEFT JOIN t2 ON t1.id=t2.id GROUP BY comment;
DROP TABLE t1, t2;
2005-08-07 23:30:46 +02:00
#
# Bug #12266 GROUP BY expression on DATE column produces result with
# reduced length
#
create table t1 (f1 date);
insert into t1 values('2005-06-06');
insert into t1 values('2005-06-06');
select date(left(f1+0,8)) from t1 group by 1;
drop table t1;
2005-07-04 15:01:04 +02:00
#
# Test for bug #11414: crash on Windows for a simple GROUP BY query
#
CREATE TABLE t1 (n int);
INSERT INTO t1 VALUES (1);
SELECT n+1 AS n FROM t1 GROUP BY n;
DROP TABLE t1;
2005-09-08 22:57:27 +02:00
#
# BUG#12695: Item_func_isnull::update_used_tables
# did not update const_item_cache
#
create table t1(f1 varchar(5) key);
insert into t1 values (1),(2);
select sql_buffer_result max(f1) is null from t1;
select sql_buffer_result max(f1)+1 from t1;
drop table t1;
2006-10-16 12:10:25 +02:00
#
# BUG#14019-4.1-opt
#
CREATE TABLE t1(a INT); INSERT INTO t1 VALUES (1),(2);
SELECT a FROM t1 GROUP BY 'a';
SELECT a FROM t1 GROUP BY "a";
SELECT a FROM t1 GROUP BY `a`;
set sql_mode=ANSI_QUOTES;
SELECT a FROM t1 GROUP BY "a";
SELECT a FROM t1 GROUP BY 'a';
SELECT a FROM t1 GROUP BY `a`;
set sql_mode='';
SELECT a FROM t1 HAVING 'a' > 1;
SELECT a FROM t1 HAVING "a" > 1;
SELECT a FROM t1 HAVING `a` > 1;
SELECT a FROM t1 ORDER BY 'a' DESC;
SELECT a FROM t1 ORDER BY "a" DESC;
SELECT a FROM t1 ORDER BY `a` DESC;
DROP TABLE t1;
2006-10-16 12:24:54 +02:00
2007-07-31 07:46:04 +02:00
#
# Bug #29717 INSERT INTO SELECT inserts values even if SELECT statement itself
# returns empty
#
CREATE TABLE t1 (
f1 int(10) unsigned NOT NULL auto_increment primary key,
f2 varchar(100) NOT NULL default ''
);
CREATE TABLE t2 (
f1 varchar(10) NOT NULL default '',
f2 char(3) NOT NULL default '',
PRIMARY KEY (`f1`),
KEY `k1` (`f2`,`f1`)
);
INSERT INTO t1 values(NULL, '');
INSERT INTO `t2` VALUES ('486878','WDT'),('486910','WDT');
SELECT SQL_BUFFER_RESULT avg(t2.f1) FROM t1, t2 where t2.f2 = 'SIR' GROUP BY t1.f1;
SELECT avg(t2.f1) FROM t1, t2 where t2.f2 = 'SIR' GROUP BY t1.f1;
DROP TABLE t1, t2;
2007-07-31 08:03:31 +02:00
2005-07-28 02:22:47 +02:00
# End of 4.1 tests
2005-07-28 16:09:54 +02:00
2005-07-04 15:01:04 +02:00
#
# Bug#11211: Ambiguous column reference in GROUP BY.
#
create table t1 (c1 char(3), c2 char(3));
create table t2 (c3 char(3), c4 char(3));
insert into t1 values ('aaa', 'bb1'), ('aaa', 'bb2');
insert into t2 values ('aaa', 'bb1'), ('aaa', 'bb2');
# query with ambiguous column reference 'c2'
select t1.c1 as c2 from t1, t2 where t1.c2 = t2.c4
group by c2;
show warnings;
# this query has no ambiguity
select t1.c1 as c2 from t1, t2 where t1.c2 = t2.c4
group by t1.c1;
show warnings;
drop table t1, t2;
2006-07-21 19:44:35 +02:00
#
# Bug #20466: a view is mixing data when there's a trigger on the table
#
CREATE TABLE t1 (a tinyint(3), b varchar(255), PRIMARY KEY (a));
INSERT INTO t1 VALUES (1,'-----'), (6,'Allemagne'), (17,'Autriche'),
(25,'Belgique'), (54,'Danemark'), (62,'Espagne'), (68,'France');
CREATE TABLE t2 (a tinyint(3), b tinyint(3), PRIMARY KEY (a), KEY b (b));
INSERT INTO t2 VALUES (1,1), (2,1), (6,6), (18,17), (15,25), (16,25),
(17,25), (10,54), (5,62),(3,68);
CREATE VIEW v1 AS select t1.a, concat(t1.b,'') AS b, t1.b as real_b from t1;
explain
SELECT straight_join sql_no_cache v1.a, v1.b, v1.real_b from t2, v1
where t2.b=v1.a GROUP BY t2.b;
SELECT straight_join sql_no_cache v1.a, v1.b, v1.real_b from t2, v1
where t2.b=v1.a GROUP BY t2.b;
DROP VIEW v1;
DROP TABLE t1,t2;
2006-08-14 17:19:29 +02:00
2006-10-09 17:51:41 +02:00
#
# Bug#22781: SQL_BIG_RESULT fails to influence sort plan
#
CREATE TABLE t1 (a INT PRIMARY KEY, b INT, key (b));
INSERT INTO t1 VALUES (1, 1);
INSERT INTO t1 SELECT a + 1 , MOD(a + 1 , 20) FROM t1;
INSERT INTO t1 SELECT a + 2 , MOD(a + 2 , 20) FROM t1;
INSERT INTO t1 SELECT a + 4 , MOD(a + 4 , 20) FROM t1;
INSERT INTO t1 SELECT a + 8 , MOD(a + 8 , 20) FROM t1;
INSERT INTO t1 SELECT a + 16, MOD(a + 16, 20) FROM t1;
INSERT INTO t1 SELECT a + 32, MOD(a + 32, 20) FROM t1;
INSERT INTO t1 SELECT a + 64, MOD(a + 64, 20) FROM t1;
SELECT MIN(b), MAX(b) from t1;
EXPLAIN SELECT b, sum(1) FROM t1 GROUP BY b;
EXPLAIN SELECT SQL_BIG_RESULT b, sum(1) FROM t1 GROUP BY b;
SELECT b, sum(1) FROM t1 GROUP BY b;
SELECT SQL_BIG_RESULT b, sum(1) FROM t1 GROUP BY b;
DROP TABLE t1;
2006-10-19 16:43:46 +02:00
2007-01-11 21:18:01 +01:00
#
# Bug #23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode
#
CREATE TABLE t1 (a INT PRIMARY KEY, b INT);
INSERT INTO t1 VALUES (1,1),(2,1),(3,2),(4,2),(5,3),(6,3);
SET SQL_MODE = 'ONLY_FULL_GROUP_BY';
SELECT MAX(a)-MIN(a) FROM t1 GROUP BY b;
SELECT CEILING(MIN(a)) FROM t1 GROUP BY b;
SELECT CASE WHEN AVG(a)>=0 THEN 'Positive' ELSE 'Negative' END FROM t1
GROUP BY b;
SELECT a + 1 FROM t1 GROUP BY a;
--error ER_WRONG_FIELD_WITH_GROUP
SELECT a + b FROM t1 GROUP BY b;
SELECT (SELECT t1_outer.a FROM t1 AS t1_inner GROUP BY b LIMIT 1)
FROM t1 AS t1_outer;
SELECT 1 FROM t1 as t1_outer GROUP BY a
HAVING (SELECT t1_outer.a FROM t1 AS t1_inner GROUP BY b LIMIT 1);
--error ER_WRONG_FIELD_WITH_GROUP
SELECT (SELECT t1_outer.a FROM t1 AS t1_inner LIMIT 1)
FROM t1 AS t1_outer GROUP BY t1_outer.b;
--error ER_BAD_FIELD_ERROR
SELECT 1 FROM t1 as t1_outer GROUP BY a
HAVING (SELECT t1_outer.b FROM t1 AS t1_inner LIMIT 1);
SELECT (SELECT SUM(t1_inner.a) FROM t1 AS t1_inner LIMIT 1)
FROM t1 AS t1_outer GROUP BY t1_outer.b;
SELECT (SELECT SUM(t1_inner.a) FROM t1 AS t1_inner GROUP BY t1_inner.b LIMIT 1)
FROM t1 AS t1_outer;
--error ER_WRONG_FIELD_WITH_GROUP
SELECT (SELECT SUM(t1_outer.a) FROM t1 AS t1_inner LIMIT 1)
FROM t1 AS t1_outer GROUP BY t1_outer.b;
SELECT 1 FROM t1 as t1_outer
WHERE (SELECT t1_outer.b FROM t1 AS t1_inner GROUP BY t1_inner.b LIMIT 1);
SELECT b FROM t1 GROUP BY b HAVING CEILING(b) > 0;
SELECT 1 FROM t1 GROUP BY b HAVING b = 2 OR b = 3 OR SUM(a) > 12;
SELECT 1 FROM t1 GROUP BY b HAVING ROW (b,b) = ROW (1,1);
--error ER_BAD_FIELD_ERROR
SELECT 1 FROM t1 GROUP BY b HAVING a = 2;
--error ER_INVALID_GROUP_FUNC_USE
SELECT 1 FROM t1 GROUP BY SUM(b);
--error ER_WRONG_FIELD_WITH_GROUP
SELECT b FROM t1 AS t1_outer GROUP BY a HAVING t1_outer.a IN
(SELECT SUM(t1_inner.b)+t1_outer.b FROM t1 AS t1_inner GROUP BY t1_inner.a
HAVING SUM(t1_inner.b)+t1_outer.b > 5);
DROP TABLE t1;
SET SQL_MODE = '';
2007-04-24 20:35:57 +02:00
#
# Bug#27874: Non-grouped columns are allowed by * in ONLY_FULL_GROUP_BY mode.
#
SET SQL_MODE = 'ONLY_FULL_GROUP_BY';
create table t1(f1 int, f2 int);
--error 1055
select * from t1 group by f1;
--error 1055
select * from t1 group by f2;
select * from t1 group by f1, f2;
--error 1055
select t1.f1,t.* from t1, t1 t group by 1;
drop table t1;
SET SQL_MODE = '';
2007-01-23 11:34:50 +01:00
2007-11-09 17:12:12 +01:00
#
# Bug #32202: ORDER BY not working with GROUP BY
#
CREATE TABLE t1(
id INT AUTO_INCREMENT PRIMARY KEY,
c1 INT NOT NULL,
c2 INT NOT NULL,
UNIQUE KEY (c2,c1));
INSERT INTO t1(c1,c2) VALUES (5,1), (4,1), (3,5), (2,3), (1,3);
# Show that the test cases from the bug report pass
SELECT * FROM t1 ORDER BY c1;
SELECT * FROM t1 GROUP BY id ORDER BY c1;
# Show that DESC is handled correctly
SELECT * FROM t1 GROUP BY id ORDER BY id DESC;
# Show that results are correctly ordered when ORDER BY fields
# are a subset of GROUP BY ones
SELECT * FROM t1 GROUP BY c2 ,c1, id ORDER BY c2, c1;
SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1;
SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1 DESC;
# Show that results are correctly ordered when GROUP BY fields
# are a subset of ORDER BY ones
SELECT * FROM t1 GROUP BY c2 ORDER BY c2, c1;
SELECT * FROM t1 GROUP BY c2 ORDER BY c2 DESC, c1;
SELECT * FROM t1 GROUP BY c2 ORDER BY c2 DESC, c1 DESC;
DROP TABLE t1;
2008-01-19 19:09:22 +01:00
2008-03-27 17:49:32 +01:00
--echo #
--echo # Bug#27219: Aggregate functions in ORDER BY.
--echo #
SET @save_sql_mode=@@sql_mode;
SET @@sql_mode='ONLY_FULL_GROUP_BY';
CREATE TABLE t1 (a INT, b INT, c INT DEFAULT 0);
INSERT INTO t1 (a, b) VALUES (3,3), (2,2), (3,3), (2,2), (3,3), (4,4);
CREATE TABLE t2 SELECT * FROM t1;
SELECT 1 FROM t1 ORDER BY COUNT(*);
SELECT 1 FROM t1 ORDER BY COUNT(*) + 1;
--error 1140
SELECT 1 FROM t1 ORDER BY COUNT(*) + a;
SELECT 1 FROM t1 ORDER BY COUNT(*), 1;
--error 1140
SELECT 1 FROM t1 ORDER BY COUNT(*), a;
SELECT 1 FROM t1 ORDER BY SUM(a);
SELECT 1 FROM t1 ORDER BY SUM(a + 1);
SELECT 1 FROM t1 ORDER BY SUM(a) + 1;
--error 1140
SELECT 1 FROM t1 ORDER BY SUM(a), b;
--error 1140
SELECT a FROM t1 ORDER BY COUNT(b);
SELECT t1.a FROM t1 ORDER BY (SELECT SUM(t2.a) FROM t2);
--error 1140
SELECT t1.a FROM t1 ORDER BY (SELECT SUM(t2.a), t2.a FROM t2);
--error 1140
SELECT t1.a FROM t1 ORDER BY (SELECT SUM(t2.a) FROM t2 ORDER BY t2.a);
--error 1140
SELECT t1.a FROM t1 ORDER BY (SELECT t2.a FROM t2 ORDER BY SUM(t2.b) LIMIT 1);
--error 1140
SELECT t1.a FROM t1
WHERE t1.a = (SELECT t2.a FROM t2 ORDER BY SUM(t2.b) LIMIT 1);
--error 1140
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING t1.a = (SELECT t2.a FROM t2 ORDER BY SUM(t2.a) LIMIT 1);
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING t1.a IN (SELECT t2.a FROM t2 ORDER BY SUM(t1.b));
--error 1140
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING t1.a IN (SELECT t2.a FROM t2 ORDER BY t2.a, SUM(t2.b));
--error 1140
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING t1.a > ANY (SELECT t2.a FROM t2 ORDER BY t2.a, SUM(t2.b));
--error 1140
SELECT t1.a FROM t1
WHERE t1.a = (SELECT t2.a FROM t2 ORDER BY SUM(t1.b));
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(SUM(t1.b) + 1) FROM t2 ORDER BY SUM(t2.a) LIMIT 1);
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(SUM(t1.b) + t2.b) FROM t2 ORDER BY SUM(t2.a) LIMIT 1);
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(t1.b + t2.b) FROM t2 ORDER BY SUM(t2.a) LIMIT 1);
--error 1140
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(SUM(t1.b) + 1) FROM t2 ORDER BY t2.a LIMIT 1);
--error 1140
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(SUM(t1.b) + t2.b) FROM t2 ORDER BY t2.a LIMIT 1);
--error 1140
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(t1.b + t2.b) FROM t2 ORDER BY t2.a LIMIT 1);
# Both SUMs are aggregated in the subquery, no mixture:
SELECT t1.a FROM t1
WHERE t1.a = (SELECT t2.a FROM t2 GROUP BY t2.a
ORDER BY SUM(t2.b), SUM(t1.b) LIMIT 1);
# SUM(t1.b) is aggregated in the subquery, no mixture:
SELECT t1.a, SUM(t1.b) FROM t1
WHERE t1.a = (SELECT SUM(t2.b) FROM t2 GROUP BY t2.a
ORDER BY SUM(t2.b), SUM(t1.b) LIMIT 1)
GROUP BY t1.a;
# 2nd SUM(t1.b) is aggregated in the subquery, no mixture:
SELECT t1.a, SUM(t1.b) FROM t1
WHERE t1.a = (SELECT SUM(t2.b) FROM t2
ORDER BY SUM(t2.b) + SUM(t1.b) LIMIT 1)
GROUP BY t1.a;
# SUM(t2.b + t1.a) is aggregated in the subquery, no mixture:
SELECT t1.a, SUM(t1.b) FROM t1
WHERE t1.a = (SELECT SUM(t2.b) FROM t2
ORDER BY SUM(t2.b + t1.a) LIMIT 1)
GROUP BY t1.a;
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING (1, 1) = (SELECT SUM(t1.a), t1.a FROM t2 LIMIT 1);
select avg (
(select
(select sum(outr.a + innr.a) from t1 as innr limit 1) as tt
from t1 as outr order by outr.a limit 1))
from t1 as most_outer;
--error 1140
select avg (
(select (
(select sum(outr.a + innr.a) from t1 as innr limit 1)) as tt
from t1 as outr order by count(outr.a) limit 1)) as tt
from t1 as most_outer;
select (select sum(outr.a + t1.a) from t1 limit 1) as tt from t1 as outr order by outr.a;
SET sql_mode=@save_sql_mode;
DROP TABLE t1, t2;
2008-10-24 04:16:22 +02:00
--echo #
--echo # BUG#38072: Wrong result: HAVING not observed in a query with aggregate
--echo #
CREATE TABLE t1 (
pk int(11) NOT NULL AUTO_INCREMENT,
int_nokey int(11) NOT NULL,
int_key int(11) NOT NULL,
varchar_key varchar(1) NOT NULL,
varchar_nokey varchar(1) NOT NULL,
PRIMARY KEY (pk),
KEY int_key (int_key),
KEY varchar_key (varchar_key)
);
INSERT INTO t1 VALUES
(1,5,5, 'h','h'),
(2,1,1, '{','{'),
(3,1,1, 'z','z'),
(4,8,8, 'x','x'),
(5,7,7, 'o','o'),
(6,3,3, 'p','p'),
(7,9,9, 'c','c'),
(8,0,0, 'k','k'),
(9,6,6, 't','t'),
(10,0,0,'c','c');
explain SELECT COUNT(varchar_key) AS X FROM t1 WHERE pk = 8 having 'foo'='bar';
SELECT COUNT(varchar_key) AS X FROM t1 WHERE pk = 8 having 'foo'='bar';
drop table t1;
2007-11-09 17:12:12 +01:00
--echo End of 5.0 tests
2006-08-14 17:19:29 +02:00
# Bug #21174: Index degrades sort performance and
2007-03-26 18:15:30 +02:00
# optimizer does not honor IGNORE INDEX.
# a.k.a WL3527.
2006-08-14 17:19:29 +02:00
#
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
CREATE TABLE t1 (a INT, b INT,
PRIMARY KEY (a),
KEY i2(a,b));
INSERT INTO t1 VALUES (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8);
INSERT INTO t1 SELECT a + 8,b FROM t1;
INSERT INTO t1 SELECT a + 16,b FROM t1;
INSERT INTO t1 SELECT a + 32,b FROM t1;
INSERT INTO t1 SELECT a + 64,b FROM t1;
2007-06-12 14:10:33 +02:00
INSERT INTO t1 SELECT a + 128,b FROM t1 limit 16;
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
ANALYZE TABLE t1;
EXPLAIN SELECT a FROM t1 WHERE a < 2;
EXPLAIN SELECT a FROM t1 WHERE a < 2 ORDER BY a;
EXPLAIN SELECT a FROM t1 WHERE a < 2 GROUP BY a;
EXPLAIN SELECT a FROM t1 IGNORE INDEX (PRIMARY,i2);
EXPLAIN SELECT a FROM t1 IGNORE INDEX FOR JOIN (PRIMARY,i2);
EXPLAIN SELECT a FROM t1 IGNORE INDEX FOR GROUP BY (PRIMARY,i2) GROUP BY a;
EXPLAIN SELECT a FROM t1 IGNORE INDEX FOR ORDER BY (PRIMARY,i2) ORDER BY a;
2007-09-28 09:36:05 +02:00
SELECT a FROM t1 IGNORE INDEX FOR ORDER BY (PRIMARY,i2) ORDER BY a;
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
EXPLAIN SELECT a FROM t1 IGNORE INDEX FOR ORDER BY (PRIMARY)
IGNORE INDEX FOR GROUP BY (i2) GROUP BY a;
EXPLAIN SELECT a FROM t1 IGNORE INDEX (PRIMARY) IGNORE INDEX FOR ORDER BY (i2);
EXPLAIN SELECT a FROM t1 FORCE INDEX (i2);
EXPLAIN SELECT a FROM t1 USE INDEX ();
EXPLAIN SELECT a FROM t1 USE INDEX () USE INDEX (i2);
--error ER_WRONG_USAGE
EXPLAIN SELECT a FROM t1
FORCE INDEX (PRIMARY)
IGNORE INDEX FOR GROUP BY (i2)
IGNORE INDEX FOR ORDER BY (i2)
USE INDEX (i2);
EXPLAIN SELECT a FROM t1 USE INDEX (i2) USE INDEX ();
--error ER_PARSE_ERROR
EXPLAIN SELECT a FROM t1 FORCE INDEX ();
--error ER_PARSE_ERROR
EXPLAIN SELECT a FROM t1 IGNORE INDEX ();
2007-08-29 13:46:49 +02:00
# disable the columns irrelevant to this test here. On some systems
# without support for large files the rowid is shorter and its size affects
# the cost calculations. This causes the optimizer to choose loose index
# scan over normal index access.
--replace_column 4 # 7 # 9 # 10 #
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
EXPLAIN SELECT a FROM t1 USE INDEX FOR JOIN (i2)
USE INDEX FOR GROUP BY (i2) GROUP BY a;
EXPLAIN SELECT a FROM t1 FORCE INDEX FOR JOIN (i2)
FORCE INDEX FOR GROUP BY (i2) GROUP BY a;
EXPLAIN SELECT a FROM t1 USE INDEX () IGNORE INDEX (i2);
EXPLAIN SELECT a FROM t1 IGNORE INDEX (i2) USE INDEX ();
EXPLAIN SELECT a FROM t1
USE INDEX FOR GROUP BY (i2)
USE INDEX FOR ORDER BY (i2)
USE INDEX FOR JOIN (i2);
EXPLAIN SELECT a FROM t1
USE INDEX FOR JOIN (i2)
USE INDEX FOR JOIN (i2)
USE INDEX FOR JOIN (i2,i2);
2011-12-15 09:21:15 +01:00
SET @save_optimizer_switch=@@optimizer_switch;
SET optimizer_switch='semijoin_with_cache=off';
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
EXPLAIN SELECT 1 FROM t1 WHERE a IN
(SELECT a FROM t1 USE INDEX (i2) IGNORE INDEX (i2));
2011-12-15 09:21:15 +01:00
SET optimizer_switch=@save_optimizer_switch;
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
CREATE TABLE t2 (a INT, b INT, KEY(a));
INSERT INTO t2 VALUES (1, 1), (2, 2), (3,3), (4,4);
EXPLAIN SELECT a, SUM(b) FROM t2 GROUP BY a LIMIT 2;
EXPLAIN SELECT a, SUM(b) FROM t2 IGNORE INDEX (a) GROUP BY a LIMIT 2;
2011-12-15 09:21:15 +01:00
SET @save_optimizer_switch=@@optimizer_switch;
SET optimizer_switch='semijoin_with_cache=off';
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
EXPLAIN SELECT 1 FROM t2 WHERE a IN
(SELECT a FROM t1 USE INDEX (i2) IGNORE INDEX (i2));
2011-12-15 09:21:15 +01:00
SET optimizer_switch=@save_optimizer_switch;
2006-08-14 17:19:29 +02:00
WL#3527: Extend IGNORE INDEX so places where index is ignored
can be specified
Currently MySQL allows one to specify what indexes to ignore during
join optimization. The scope of the current USE/FORCE/IGNORE INDEX
statement is only the FROM clause, while all other clauses are not
affected.
However, in certain cases, the optimizer
may incorrectly choose an index for sorting and/or grouping, and
produce an inefficient query plan.
This task provides the means to specify what indexes are
ignored/used for what operation in a more fine-grained manner, thus
making it possible to manually force a better plan. We do this
by extending the current IGNORE/USE/FORCE INDEX syntax to:
IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
so that:
- if no FOR is specified, the index hint will apply everywhere.
- if MySQL is started with the compatibility option --old_mode then
an index hint without a FOR clause works as in 5.0 (i.e, the
index will only be ignored for JOINs, but can still be used to
compute ORDER BY).
See the WL#3527 for further details.
BitKeeper/deleted/.del-mysqld.cc.rej:
Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej
BitKeeper/deleted/.del-sql_parse.cc.rej:
Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej
BitKeeper/deleted/.del-table.cc.rej:
Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej
mysql-test/r/endspace.result:
WL3527 : fixed undeterministic test
mysql-test/r/group_by.result:
WL#3527: test cases
mysql-test/t/endspace.test:
WL3527 : fixed undeterministic test
mysql-test/t/group_by.test:
WL#3527: test cases
sql/item.cc:
WL#3527: renames
sql/mysql_priv.h:
WL#3527: corrected initialization
sql/mysqld.cc:
WL#3527: added old_mode command line option
sql/opt_range.cc:
WL#3527: renames
sql/sql_base.cc:
WL#3527:
- renames
- correct initialization
- extended the processing of USE/FORCE/IGNORE index
sql/sql_class.h:
WL#3527: added old_mode command line option
sql/sql_delete.cc:
WL#3527: renames
sql/sql_help.cc:
WL#3527: renames
sql/sql_lex.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_lex.h:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_parse.cc:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/sql_select.cc:
WL#3527:
- renames
- passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
- If there is a covering index, and we have
IGNORE INDEX FOR GROUP/ORDER, and this index is
used for the JOIN part, then we have to ignore the
IGNORE INDEX FOR GROUP/ORDER.
sql/sql_show.cc:
WL#3527: passing additional info to support the extended
USE/FORCE/IGNORE INDEX syntax
sql/sql_update.cc:
WL#3527: renames
sql/sql_yacc.yy:
WL#3527: extended parsing of USE/FORCE/IGNORE index
sql/table.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
sql/table.h:
WL#3527: extended the processing of USE/FORCE/IGNORE index
storage/myisam/ha_myisam.cc:
WL#3527: extended the processing of USE/FORCE/IGNORE index
2007-03-05 18:08:41 +01:00
DROP TABLE t1, t2;
2007-08-28 18:01:29 +02:00
#
# Bug#30596: GROUP BY optimization gives wrong result order
#
CREATE TABLE t1(
a INT,
b INT NOT NULL,
c INT NOT NULL,
d INT,
UNIQUE KEY (c,b)
);
INSERT INTO t1 VALUES (1,1,1,50), (1,2,3,40), (2,1,3,4);
CREATE TABLE t2(
a INT,
b INT,
UNIQUE KEY(a,b)
);
INSERT INTO t2 VALUES (NULL, NULL), (NULL, NULL), (NULL, 1), (1, NULL), (1, 1), (1,2);
EXPLAIN SELECT c,b,d FROM t1 GROUP BY c,b,d;
SELECT c,b,d FROM t1 GROUP BY c,b,d;
EXPLAIN SELECT c,b,d FROM t1 GROUP BY c,b,d ORDER BY NULL;
SELECT c,b,d FROM t1 GROUP BY c,b,d ORDER BY NULL;
EXPLAIN SELECT c,b,d FROM t1 ORDER BY c,b,d;
SELECT c,b,d FROM t1 ORDER BY c,b,d;
EXPLAIN SELECT c,b,d FROM t1 GROUP BY c,b;
SELECT c,b,d FROM t1 GROUP BY c,b;
EXPLAIN SELECT c,b FROM t1 GROUP BY c,b;
SELECT c,b FROM t1 GROUP BY c,b;
EXPLAIN SELECT a,b from t2 ORDER BY a,b;
SELECT a,b from t2 ORDER BY a,b;
EXPLAIN SELECT a,b from t2 GROUP BY a,b;
SELECT a,b from t2 GROUP BY a,b;
EXPLAIN SELECT a from t2 GROUP BY a;
SELECT a from t2 GROUP BY a;
EXPLAIN SELECT b from t2 GROUP BY b;
SELECT b from t2 GROUP BY b;
DROP TABLE t1;
2008-03-14 17:59:03 +01:00
DROP TABLE t2;
2008-01-11 18:50:54 +01:00
#
# Bug #31797: error while parsing subqueries -- WHERE is parsed as HAVING
#
CREATE TABLE t1 ( a INT, b INT );
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1;
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
--error ER_ILLEGAL_REFERENCE
SELECT MAX(b) c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
SET @old_sql_mode = @@sql_mode;
SET @@sql_mode='ONLY_FULL_GROUP_BY';
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1;
--error ER_NON_GROUPING_FIELD_USED
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
--error ER_ILLEGAL_REFERENCE
SELECT MAX(b) c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
INSERT INTO t1 VALUES (1, 1);
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1;
INSERT INTO t1 VALUES (2, 1);
--error ER_SUBQUERY_NO_1_ROW
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1;
DROP TABLE t1;
SET @@sql_mode = @old_sql_mode;
2009-02-26 18:17:06 +01:00
#
# Bug#42567 Invalid GROUP BY error
#
# Setup of the subtest
SET @old_sql_mode = @@sql_mode;
SET @@sql_mode='ONLY_FULL_GROUP_BY';
CREATE TABLE t1(i INT);
INSERT INTO t1 VALUES (1), (10);
# The actual test
SELECT COUNT(i) FROM t1;
SELECT COUNT(i) FROM t1 WHERE i > 1;
# Cleanup of subtest
DROP TABLE t1;
SET @@sql_mode = @old_sql_mode;
2008-01-11 18:50:54 +01:00
2010-02-06 20:54:30 +01:00
--echo #
--echo # Bug #45640: optimizer bug produces wrong results
--echo #
CREATE TABLE t1 (a INT, b INT);
INSERT INTO t1 VALUES (4, 40), (1, 10), (2, 20), (2, 20), (3, 30);
--echo # should return 4 ordered records:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa;
SELECT (SELECT (SELECT t1.a)) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa;
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa+0;
--echo # should return the same result in a reverse order:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY -aa;
--echo # execution plan should not use temporary table:
EXPLAIN EXTENDED
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa+0;
EXPLAIN EXTENDED
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY -aa;
--echo # should return only one record
SELECT (SELECT tt.a FROM t1 tt LIMIT 1) aa, COUNT(DISTINCT b) FROM t1
GROUP BY aa;
CREATE TABLE t2 SELECT DISTINCT a FROM t1;
--echo # originally reported queries (1st two columns of next two query
--echo # results should be same):
SELECT (SELECT t2.a FROM t2 WHERE t2.a = t1.a) aa, b, COUNT(DISTINCT b)
FROM t1 GROUP BY aa, b;
SELECT (SELECT t2.a FROM t2 WHERE t2.a = t1.a) aa, b, COUNT( b)
FROM t1 GROUP BY aa, b;
--echo # ORDER BY for sure:
SELECT (SELECT t2.a FROM t2 WHERE t2.a = t1.a) aa, b, COUNT(DISTINCT b)
FROM t1 GROUP BY aa, b ORDER BY -aa, -b;
SELECT (SELECT t2.a FROM t2 WHERE t2.a = t1.a) aa, b, COUNT( b)
FROM t1 GROUP BY aa, b ORDER BY -aa, -b;
DROP TABLE t1, t2;
2010-05-12 18:10:33 +02:00
--echo #
--echo # Bug#52051: Aggregate functions incorrectly returns NULL from outer
--echo # join query
--echo #
CREATE TABLE t1 (a INT PRIMARY KEY);
CREATE TABLE t2 (a INT PRIMARY KEY);
INSERT INTO t2 VALUES (1), (2);
EXPLAIN SELECT MIN(t2.a) FROM t2 LEFT JOIN t1 ON t2.a = t1.a;
SELECT MIN(t2.a) FROM t2 LEFT JOIN t1 ON t2.a = t1.a;
EXPLAIN SELECT MAX(t2.a) FROM t2 LEFT JOIN t1 ON t2.a = t1.a;
SELECT MAX(t2.a) FROM t2 LEFT JOIN t1 ON t2.a = t1.a;
DROP TABLE t1, t2;
2010-08-23 11:46:25 +02:00
#
# min() returns wrong value when used in expression when there is no matching
# rows
#
CREATE TABLE t1 (a int(11) NOT NULL);
INSERT INTO t1 VALUES (1),(2);
CREATE TABLE t2 (
key_col int(11) NOT NULL,
KEY (key_col)
);
INSERT INTO t2 VALUES (1),(2);
select min(t2.key_col) from t1,t2 where t1.a=1;
select min(t2.key_col) from t1,t2 where t1.a > 1000;
select min(t2.key_col)+1 from t1,t2 where t1.a> 1000;
drop table t1,t2;
2010-05-12 18:10:33 +02:00
2010-02-06 20:54:30 +01:00
--echo #
2010-07-30 15:35:06 +02:00
--echo # Bug#55188: GROUP BY, GROUP_CONCAT and TEXT - inconsistent results
--echo #
CREATE TABLE t1 (a text, b varchar(10));
INSERT INTO t1 VALUES (repeat('1', 1300),'one'), (repeat('1', 1300),'two');
query_vertical EXPLAIN
SELECT SUBSTRING(a,1,10), LENGTH(a), GROUP_CONCAT(b) FROM t1 GROUP BY a;
SELECT SUBSTRING(a,1,10), LENGTH(a), GROUP_CONCAT(b) FROM t1 GROUP BY a;
query_vertical EXPLAIN
SELECT SUBSTRING(a,1,10), LENGTH(a) FROM t1 GROUP BY a;
SELECT SUBSTRING(a,1,10), LENGTH(a) FROM t1 GROUP BY a;
DROP TABLE t1;
2010-10-29 10:23:06 +02:00
--echo #
--echo # Bug#57688 Assertion `!table || (!table->write_set || bitmap_is_set(table->write_set, field
--echo #
CREATE TABLE t1(f1 INT NOT NULL);
INSERT INTO t1 VALUES (16777214),(0);
SELECT COUNT(*) FROM t1 LEFT JOIN t1 t2
ON 1 WHERE t2.f1 > 1 GROUP BY t2.f1;
DROP TABLE t1;
2010-02-06 20:54:30 +01:00
2011-02-18 11:50:06 +01:00
--echo #
--echo # Bug#59839: Aggregation followed by subquery yields wrong result
--echo #
CREATE TABLE t1 (
a INT,
b INT,
c INT,
KEY (a, b)
);
INSERT INTO t1 VALUES
( 1, 1, 1 ),
( 1, 2, 2 ),
( 1, 3, 3 ),
( 1, 4, 6 ),
( 1, 5, 5 ),
( 1, 9, 13 ),
( 2, 1, 6 ),
( 2, 2, 7 ),
( 2, 3, 8 );
EXPLAIN
SELECT a, AVG(t1.b),
(SELECT t11.c FROM t1 t11 WHERE t11.a = t1.a AND t11.b = AVG(t1.b)) AS t11c,
(SELECT t12.c FROM t1 t12 WHERE t12.a = t1.a AND t12.b = AVG(t1.b)) AS t12c
FROM t1 GROUP BY a;
SELECT a, AVG(t1.b),
(SELECT t11.c FROM t1 t11 WHERE t11.a = t1.a AND t11.b = AVG(t1.b)) AS t11c,
(SELECT t12.c FROM t1 t12 WHERE t12.a = t1.a AND t12.b = AVG(t1.b)) AS t12c
FROM t1 GROUP BY a;
DROP TABLE t1;
2011-08-30 09:56:07 +02:00
--echo #
--echo # Bug#11765254 (58200): Assertion failed: param.sort_length when grouping
--echo # by functions
--echo #
fixes for test failures
and small collateral changes
mysql-test/lib/My/Test.pm:
somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
this differs, because we don't rewrite general log queries, and multi-statement
packets are logged as a one entry. this result file is identical to what mysql-5.6.5
produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged
2012-09-27 20:09:46 +02:00
SET BIG_TABLES=1;
2011-08-30 09:56:07 +02:00
CREATE TABLE t1(a INT);
INSERT INTO t1 VALUES (0),(0);
SELECT 1 FROM t1 GROUP BY IF(`a`,'','');
SELECT 1 FROM t1 GROUP BY TRIM(LEADING RAND() FROM '');
SELECT 1 FROM t1 GROUP BY SUBSTRING('',SLEEP(0),'');
SELECT 1 FROM t1 GROUP BY SUBSTRING(SYSDATE() FROM 'K' FOR 'jxW<');
DROP TABLE t1;
fixes for test failures
and small collateral changes
mysql-test/lib/My/Test.pm:
somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
this differs, because we don't rewrite general log queries, and multi-statement
packets are logged as a one entry. this result file is identical to what mysql-5.6.5
produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged
2012-09-27 20:09:46 +02:00
SET BIG_TABLES=0;
2010-02-06 20:54:30 +01:00
2013-01-31 23:09:36 +01:00
--echo #
--echo # MDEV-641 LP:1002108 - Wrong result (or crash) from a query with duplicated field in the group list and a limit clause
--echo # Bug#11761078: 53534: INCORRECT 'SELECT SQL_BIG_RESULT...'
--echo # WITH GROUP BY ON DUPLICATED FIELDS
--echo #
CREATE TABLE t1(
col1 int,
UNIQUE INDEX idx (col1));
INSERT INTO t1 VALUES (1),(2),(3),(4),(5),(6),(7),(8),(9),(10),
(11),(12),(13),(14),(15),(16),(17),(18),(19),(20);
let $query0=SELECT col1 AS field1, col1 AS field2
2014-04-22 23:39:57 +02:00
FROM t1 GROUP BY field1, field2;
2013-01-31 23:09:36 +01:00
# Needs to be range to exercise bug
--eval EXPLAIN $query0;
FLUSH STATUS;
--eval $query0;
SHOW SESSION STATUS LIKE 'Sort_scan%';
let $query=SELECT SQL_BIG_RESULT col1 AS field1, col1 AS field2
FROM t1 GROUP BY field1, field2;
# Needs to be range to exercise bug
--eval EXPLAIN $query;
FLUSH STATUS;
--eval $query;
SHOW SESSION STATUS LIKE 'Sort_scan%';
CREATE VIEW v1 AS SELECT * FROM t1;
SELECT SQL_BIG_RESULT col1 AS field1, col1 AS field2
FROM v1
GROUP BY field1, field2;
SELECT SQL_BIG_RESULT tbl1.col1 AS field1, tbl2.col1 AS field2
FROM t1 as tbl1, t1 as tbl2
GROUP BY field1, field2
LIMIT 3;
explain
select col1 f1, col1 f2 from t1 order by f2, f1;
2014-01-02 14:51:02 +01:00
explain
select col1 f1, col1 f2 from t1 order by f2, f1+0;
select col1 f1, col1 f2 from t1 order by f2, f1+0;
2013-01-31 23:09:36 +01:00
explain
select col1 f1, col1 f2 from t1 group by f2 order by f2, f1;
select col1 f1, col1 f2 from t1 group by f2 order by f2, f1;
explain
select col1 f1, col1 f2 from t1 group by f1, f2 order by f2, f1;
select col1 f1, col1 f2 from t1 group by f1, f2 order by f2, f1;
CREATE TABLE t2(
col1 int,
col2 int,
UNIQUE INDEX idx (col1, col2));
INSERT INTO t2(col1, col2) VALUES
(1,20),(2,19),(3,18),(4,17),(5,16),(6,15),(7,14),(8,13),(9,12),(10,11),
(11,10),(12,9),(13,8),(14,7),(15,6),(16,5),(17,4),(18,3),(19,2),(20,1);
explain
2014-01-02 14:51:02 +01:00
select col1 f1, col2 f2, col1 f3 from t2 group by f1, f2, f3+0;
select col1 f1, col2 f2, col1 f3 from t2 group by f1, f2, f3+0;
2013-01-31 23:09:36 +01:00
explain
2014-01-02 14:51:02 +01:00
select col1 f1, col2 f2, col1 f3 from t2 order by f1, f2, f3+0;
select col1 f1, col2 f2, col1 f3 from t2 order by f1, f2, f3+0;
2013-01-31 23:09:36 +01:00
DROP VIEW v1;
DROP TABLE t1, t2;
2010-02-06 20:54:30 +01:00
--echo # End of 5.1 tests
2010-07-19 19:11:47 +02:00
--echo #
2012-03-14 11:09:03 +01:00
--echo # LP bug#694450 Wrong result with non-standard GROUP BY + ORDER BY
2010-07-19 19:11:47 +02:00
--echo #
2012-03-14 11:09:03 +01:00
SET SESSION SQL_MODE='ONLY_FULL_GROUP_BY';
CREATE TABLE t1 (
f1 int(11), f2 int(11), f3 datetime, f4 varchar(1), PRIMARY KEY (f1)) ;
INSERT IGNORE INTO t1 VALUES ('1','9','2004-10-11 18:13','x'),('2','5','2004-03-07 14:02','g'),('3','1','2004-04-09 09:38','o'),('4','0','1900-01-01 00:00','g'),('5','1','2009-02-19 02:05','v');
2010-07-19 19:11:47 +02:00
2012-03-14 11:09:03 +01:00
# This must return an error, but instead returns 1 row
SELECT alias2.f3 AS field1 , alias2.f1 AS field2 FROM t1 AS alias1 JOIN t1 AS alias2 ON alias2.f1 = alias1.f2 AND alias2.f1 != alias1.f4 GROUP BY field1 , field2 ORDER BY alias1.f2 , field2;
2010-07-19 19:11:47 +02:00
2012-03-14 11:09:03 +01:00
# This returns several rows
SELECT alias2.f3 AS field1 , alias2.f1 AS field2 FROM t1 AS alias1 JOIN t1 AS alias2 ON alias2.f1 = alias1.f2 AND alias2.f1 != alias1.f4 GROUP BY field1 , field2 ;
SET SESSION SQL_MODE=default;
drop table t1;
2010-07-19 19:11:47 +02:00
2012-05-02 18:11:02 +02:00
--echo #
--echo # LP bug#967242 Wrong result (extra rows, not grouped) with JOIN, AND in ON condition, multi-part key, GROUP BY, OR in WHERE
--echo #
CREATE TABLE t1 ( a VARCHAR(1) ) ENGINE=MyISAM;
INSERT INTO t1 VALUES ('x');
CREATE TABLE t2 ( b INT, c VARCHAR(1), KEY (c, b) ) ENGINE=MyISAM;
INSERT INTO t2 VALUES
(4, 'd'),(8, 'g'),(3, 'x'),(3, 'f'),
(0, 'p'),(3, 'j'),(8, 'c');
SELECT t2_1.b as zzz
FROM t1 JOIN t2 AS t2_1 JOIN t2 AS t2_2
ON (t2_2.b = t2_1.b ) AND (t2_2.c = t2_1.c )
WHERE
rand() + 1 > 0 OR
a = t2_1.c
GROUP BY zzz;
SELECT t2_1.b as zzz
FROM t1 JOIN t2 AS t2_1 JOIN t2 AS t2_2
ON (t2_2.b = t2_1.b ) AND (t2_2.c = t2_1.c )
WHERE
1 > 0 OR
a = t2_1.c
GROUP BY zzz;
SELECT t2_1.b as zzz
FROM t1 JOIN t2 AS t2_1 JOIN t2 AS t2_2
ON (t2_2.b = t2_1.b ) AND (t2_2.c = t2_1.c )
WHERE
t2_1.b + 1 > 0 OR
a = t2_1.c
GROUP BY zzz;
2012-05-11 10:40:23 +02:00
SET @save_optimizer_switch967242=@@optimizer_switch;
SET optimizer_switch = 'in_to_exists=on';
SELECT t2_1.b
FROM t1 JOIN t2 AS t2_1 JOIN t2 AS t2_2
ON (t2_2.b = t2_1.b ) AND (t2_2.c = t2_1.c )
WHERE
( SELECT COUNT(*) FROM t2 ) IS NOT NULL
OR a = t2_1.c
GROUP BY t2_1.b;
SET optimizer_switch=@save_optimizer_switch967242;
2012-05-02 18:11:02 +02:00
drop table t1, t2;
Fix for bug lp:992405
The patch backports two patches from mysql 5.6:
- BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT QUERY OUTPUT
- Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY ROWS WHEN GROUP IS OPTIMIZED AWAY
Original comment:
-----------------
3714 Jorgen Loland 2012-03-01
BUG#12640437 - USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT
QUERY OUTPUT
For all but simple grouped queries, temporary tables are used to
resolve grouping. In these cases, the list of grouping fields is
stored in the temporary table and grouping is resolved
there (e.g. by adding a unique constraint on the involved
fields). Because of this, grouping is already done when the rows
are read from the temporary table.
In the case where a group clause may be optimized away, grouping
does not have to be resolved using a temporary table. However, if
a temporary table is explicitly requested (e.g. because the
SQL_BUFFER_RESULT hint is used, or the statement is
INSERT...SELECT), a temporary table is used anyway. In this case,
the temporary table is created with an empty group list (because
the group clause was optimized away) and it will therefore not
create groups. Since the temporary table does not take care of
grouping, JOIN::group shall not be set to false in
make_simple_join(). This was fixed in bug 12578908.
However, there is an exception where make_simple_join() should
set JOIN::group to false even if the query uses a temporary table
that was explicitly requested but is not strictly needed. That
exception is if the loose index scan access method (explain
says "Using index for group-by") is used to read into the
temporary table. With loose index scan, grouping is resolved
by the access method. This is exactly what happens in this bug.
2012-05-07 10:02:58 +02:00
--echo #
--echo # Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY
--echo # ROWS WHEN GROUP IS OPTIMIZED AWAY
--echo #
CREATE TABLE t1 (col1 int, col2 int) ;
INSERT INTO t1 VALUES (10,1),(11,7);
CREATE TABLE t2 (col1 int, col2 int) ;
INSERT INTO t2 VALUES (10,8);
let $q_body=t2.col2 FROM t2 JOIN t1 ON t1.col1 GROUP BY t2.col2;
--echo
--eval EXPLAIN SELECT SQL_BUFFER_RESULT $q_body
--eval SELECT SQL_BUFFER_RESULT $q_body
--echo
--eval EXPLAIN SELECT $q_body
--eval SELECT $q_body
--echo
DROP TABLE t1,t2;
--echo #
--echo # BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A
--echo # DIFFERENT QUERY OUTPUT
--echo #
2012-03-14 11:09:03 +01:00
Fix for bug lp:992405
The patch backports two patches from mysql 5.6:
- BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT QUERY OUTPUT
- Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY ROWS WHEN GROUP IS OPTIMIZED AWAY
Original comment:
-----------------
3714 Jorgen Loland 2012-03-01
BUG#12640437 - USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT
QUERY OUTPUT
For all but simple grouped queries, temporary tables are used to
resolve grouping. In these cases, the list of grouping fields is
stored in the temporary table and grouping is resolved
there (e.g. by adding a unique constraint on the involved
fields). Because of this, grouping is already done when the rows
are read from the temporary table.
In the case where a group clause may be optimized away, grouping
does not have to be resolved using a temporary table. However, if
a temporary table is explicitly requested (e.g. because the
SQL_BUFFER_RESULT hint is used, or the statement is
INSERT...SELECT), a temporary table is used anyway. In this case,
the temporary table is created with an empty group list (because
the group clause was optimized away) and it will therefore not
create groups. Since the temporary table does not take care of
grouping, JOIN::group shall not be set to false in
make_simple_join(). This was fixed in bug 12578908.
However, there is an exception where make_simple_join() should
set JOIN::group to false even if the query uses a temporary table
that was explicitly requested but is not strictly needed. That
exception is if the loose index scan access method (explain
says "Using index for group-by") is used to read into the
temporary table. With loose index scan, grouping is resolved
by the access method. This is exactly what happens in this bug.
2012-05-07 10:02:58 +02:00
CREATE TABLE t1 (
a int,
b varchar(1),
KEY (b,a)
);
2014-04-22 23:39:57 +02:00
INSERT INTO t1 VALUES (1,NULL),(0,'a'),(1,NULL),(0,'a');
Fix for bug lp:992405
The patch backports two patches from mysql 5.6:
- BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT QUERY OUTPUT
- Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY ROWS WHEN GROUP IS OPTIMIZED AWAY
Original comment:
-----------------
3714 Jorgen Loland 2012-03-01
BUG#12640437 - USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT
QUERY OUTPUT
For all but simple grouped queries, temporary tables are used to
resolve grouping. In these cases, the list of grouping fields is
stored in the temporary table and grouping is resolved
there (e.g. by adding a unique constraint on the involved
fields). Because of this, grouping is already done when the rows
are read from the temporary table.
In the case where a group clause may be optimized away, grouping
does not have to be resolved using a temporary table. However, if
a temporary table is explicitly requested (e.g. because the
SQL_BUFFER_RESULT hint is used, or the statement is
INSERT...SELECT), a temporary table is used anyway. In this case,
the temporary table is created with an empty group list (because
the group clause was optimized away) and it will therefore not
create groups. Since the temporary table does not take care of
grouping, JOIN::group shall not be set to false in
make_simple_join(). This was fixed in bug 12578908.
However, there is an exception where make_simple_join() should
set JOIN::group to false even if the query uses a temporary table
that was explicitly requested but is not strictly needed. That
exception is if the loose index scan access method (explain
says "Using index for group-by") is used to read into the
temporary table. With loose index scan, grouping is resolved
by the access method. This is exactly what happens in this bug.
2012-05-07 10:02:58 +02:00
let $query=
SELECT SQL_BUFFER_RESULT MIN(a), b FROM t1 WHERE t1.b = 'a' GROUP BY b;
--echo
--eval EXPLAIN $query
--echo
--eval $query
let $query= SELECT MIN(a), b FROM t1 WHERE t1.b = 'a' GROUP BY b;
--echo
--eval EXPLAIN $query
--echo
--eval $query
--echo
DROP TABLE t1;
2012-05-07 12:26:34 +02:00
--echo #
--echo # LP bug#993726 Wrong result from a query with ALL subquery predicate in WHERE
--echo #
CREATE TABLE t1(a INT);
INSERT INTO t1 VALUES (0);
SELECT 1 FROM t1 WHERE 1 > ALL(SELECT 1 FROM t1 WHERE a!=0);
SELECT max(1) FROM t1 WHERE a!=0;
drop table t1;
2012-03-14 11:09:03 +01:00
--echo # End of 5.2 tests
2010-07-19 19:11:47 +02:00
2011-11-22 18:04:38 +01:00
--echo #
--echo # lp:872702: Crash in add_ref_to_table_cond() when grouping by a PK
2011-10-12 19:40:56 +02:00
--echo #
CREATE TABLE t1 (a int, PRIMARY KEY (a)) ;
INSERT INTO t1 VALUES (14),(15),(16),(17),(18),(19),(20);
CREATE TABLE t2 (a int) ;
SELECT a
FROM t1
WHERE a = (
SELECT t2.a
FROM t2
) OR t1.a = 73
GROUP BY 1;
DROP TABLE t1, t2;
2012-11-17 16:50:15 +01:00
#
# MDEV-736 LP:1004615 - Unexpected warnings "Encountered illegal value '' when converting to DECIMAL" on a query with aggregate functions and GROUP BY
#
FLUSH STATUS; # this test case *must* use Aria temp tables
CREATE TABLE t1 (f1 INT, f2 decimal(20,1), f3 blob);
INSERT INTO t1 values(11,NULL,'blob'),(11,NULL,'blob');
SELECT f3, MIN(f2) FROM t1 GROUP BY f1 LIMIT 1;
DROP TABLE t1;
--echo the value below *must* be 1
show status like 'Created_tmp_disk_tables';
2012-11-22 06:55:04 +01:00
--echo #
--echo # Bug #1002146: Unneeded filesort if usage of join buffer is not allowed
--echo # (bug mdev-645)
--echo #
CREATE TABLE t1 (pk int PRIMARY KEY, a int, INDEX idx(a));
INSERT INTO t1 VALUES (3,2), (2,3), (5,3), (6,4);
CREATE TABLE t2 (pk int PRIMARY KEY, a int, INDEX idx(a));
INSERT INTO t2 VALUES (9,0), (10,3), (6,4), (1,6), (3,100), (5,200);
set join_cache_level=0;
EXPLAIN
SELECT t2.a FROM t2 STRAIGHT_JOIN t1 ON t2.a <> 0 WHERE t2.a <> 6
GROUP BY t2.a;
SELECT t2.a FROM t2 STRAIGHT_JOIN t1 ON t2.a <> 0 WHERE t2.a <> 6
GROUP BY t2.a;
set join_cache_level=default;
set @save_optimizer_switch=@@optimizer_switch;
set optimizer_switch='outer_join_with_cache=off';
EXPLAIN
SELECT t2.a FROM t2 LEFT JOIN t1 ON t2.a <> 0 WHERE t2.a <> 6
GROUP BY t2.a;
SELECT t2.a FROM t2 LEFT JOIN t1 ON t2.a <> 0 WHERE t2.a <> 6
GROUP BY t2.a;
set optimizer_switch=@save_optimizer_switch;
DROP TABLE t1,t2;
2013-10-29 11:39:03 +01:00
--echo #
--echo # MDEV-5104 crash in Item_field::used_tables with broken order by
--echo #
--error ER_BAD_FIELD_ERROR
(select 1 order by x(y)) order by 1;
2012-03-14 12:58:18 +01:00
--echo # End of 5.3 tests
2012-03-17 09:26:58 +01:00
--echo #
--echo # Bug#49771: Incorrect MIN (date) when minimum value is 0000-00-00
--echo #
CREATE TABLE t1 (f1 int, f2 DATE);
INSERT INTO t1 VALUES (1,'2004-04-19'), (1,'0000-00-00'), (1,'2004-04-18'),
(2,'2004-05-19'), (2,'0001-01-01'), (3,'2004-04-10');
SELECT MIN(f2),MAX(f2) FROM t1;
SELECT f1,MIN(f2),MAX(f2) FROM t1 GROUP BY 1;
DROP TABLE t1;
CREATE TABLE t1 ( f1 int, f2 time);
INSERT INTO t1 VALUES (1,'01:27:35'), (1,'06:11:01'), (2,'19:53:05'),
(2,'21:44:25'), (3,'10:55:12'), (3,'05:45:11'), (4,'00:25:00');
SELECT MIN(f2),MAX(f2) FROM t1;
SELECT f1,MIN(f2),MAX(f2) FROM t1 GROUP BY 1;
DROP TABLE t1;
--echo #End of test#49771
2012-09-01 23:21:59 +02:00
2013-01-11 00:31:50 +01:00
--echo #
--echo # Test of bug in GROUP_CONCAT with ROLLUP
--echo #
CREATE TABLE t1 ( b VARCHAR(8) NOT NULL, a INT NOT NULL ) ENGINE=MyISAM;
INSERT INTO t1 (a,b) VALUES (1,'c'),(2,'v');
CREATE TABLE t2 ( c VARCHAR(8), d INT, KEY (c, d) ) ENGINE=MyISAM;
INSERT INTO t2 VALUES ('v',6),('c',4),('v',3);
SELECT b, GROUP_CONCAT( a, b ORDER BY a, b )
FROM t1 JOIN t2 ON c = b GROUP BY b;
SELECT b, GROUP_CONCAT( a, b ORDER BY a, b )
FROM t1 JOIN t2 ON c = b GROUP BY b WITH ROLLUP;
DROP TABLE t1,t2;
2012-09-01 23:21:59 +02:00
--echo #
--echo # Bug #58782
--echo # Missing rows with SELECT .. WHERE .. IN subquery
--echo # with full GROUP BY and no aggr
--echo #
CREATE TABLE t1 (
pk INT NOT NULL,
col_int_nokey INT,
PRIMARY KEY (pk)
);
INSERT INTO t1 VALUES (10,7);
INSERT INTO t1 VALUES (11,1);
INSERT INTO t1 VALUES (12,5);
INSERT INTO t1 VALUES (13,3);
## original query:
SELECT pk AS field1, col_int_nokey AS field2
FROM t1
WHERE col_int_nokey > 0
GROUP BY field1, field2;
## store query results in a new table:
CREATE TABLE where_subselect
SELECT pk AS field1, col_int_nokey AS field2
FROM t1
WHERE col_int_nokey > 0
GROUP BY field1, field2
;
## query the new table and compare to original using WHERE ... IN():
SELECT *
FROM where_subselect
WHERE (field1, field2) IN (
SELECT pk AS field1, col_int_nokey AS field2
FROM t1
WHERE col_int_nokey > 0
GROUP BY field1, field2
);
DROP TABLE t1;
DROP TABLE where_subselect;
--echo # End of Bug #58782
