2003-01-06 00:48:59 +01:00
drop table if exists t1,t2,t3;
2002-11-28 18:19:21 +01:00
SELECT 1 FROM (SELECT 1) as a GROUP BY SUM(1);
2003-06-04 17:28:51 +02:00
ERROR HY000: Invalid use of group function
2001-09-28 07:05:54 +02:00
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,
2001-09-28 07:05:54 +02: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');
2001-09-28 07:05:54 +02:00
SELECT t2.userid, MIN(t1.score) FROM t1, t2 WHERE t1.userID=t2.userID GROUP BY t2.userid;
2000-12-28 02:56:38 +01:00
userid MIN(t1.score)
1 1
2 2
3 3
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;
userid MIN(t1.score)
1 1
2 2
3 3
2001-09-28 07:05:54 +02:00
SELECT t2.userid, MIN(t1.score) FROM t1, t2 WHERE t1.userID=t2.userID AND t1.spID=2 GROUP BY t2.userid;
2000-12-28 02:56:38 +01:00
userid MIN(t1.score)
1 1
2 2
2001-09-28 07:05:54 +02: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;
2000-12-28 02:56:38 +01:00
userid MIN(t1.score+0.0)
1 1.0
2 2.0
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;
userid MIN(t1.score+0.0)
2 2.0
2003-04-24 01:23:25 +02:00
1 1.0
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-05-21 20:39:58 +02:00
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 4 Using where; Using temporary
2003-06-04 17:28:51 +02:00
1 SIMPLE t2 eq_ref PRIMARY PRIMARY 4 test.t1.userID 1 Using index
2003-01-06 00:48:59 +01:00
drop table t1,t2;
2001-09-28 07:05:54 +02:00
CREATE TABLE t1 (
2003-03-22 19:34:20 +01:00
PID int(10) unsigned NOT NULL auto_increment,
2001-09-28 07:05:54 +02: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);
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;
2003-06-04 17:28:51 +02:00
ERROR 42000: Can't group on 'IsNew'
2001-09-28 07:05:54 +02:00
drop table t1;
CREATE TABLE t1 (
2003-03-22 19:34:20 +01:00
cid mediumint(9) NOT NULL auto_increment,
2001-09-28 07:05:54 +02: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,
2001-09-28 07:05:54 +02: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;
2000-12-28 02:56:38 +01:00
cid CONCAT(firstname, ' ', surname) COUNT(call_id)
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;
cid CONCAT(firstname, ' ', surname) COUNT(call_id)
2001-09-28 07:05:54 +02: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;
2000-12-28 02:56:38 +01:00
cid CONCAT(firstname, ' ', surname) COUNT(call_id)
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;
2001-09-28 07:05:54 +02: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;
2001-09-28 07:05:54 +02:00
CREATE TABLE t1 (
2003-03-22 19:34:20 +01:00
bug_id mediumint(9) NOT NULL auto_increment,
2001-09-28 07:05:54 +02: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,
2001-09-28 07:05:54 +02: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,
2001-09-28 07:05:54 +02: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";
2000-12-28 02:56:38 +01:00
value description bug_id
BBBBBBBBBBBBB - conversion 9
BBBBBBBBBBBBB - conversion 10
BBBBBBBBBBBBB - generic 7
BBBBBBBBBBBBB - generic 14
BBBBBBBBBBBBB - eeeeeeeee NULL
kkkkkkkkkkk lllllllllll 6
kkkkkkkkkkk lllllllllll 8
kkkkkkkkkkk lllllllllll 12
Test Procedures NULL
Documentation NULL
Host communication NULL
2001-09-28 07:05:54 +02: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;
2000-12-28 02:56:38 +01:00
value description COUNT(bug_id)
BBBBBBBBBBBBB - conversion 2
BBBBBBBBBBBBB - eeeeeeeee 0
BBBBBBBBBBBBB - generic 2
Documentation 0
Host communication 0
kkkkkkkkkkk lllllllllll 3
Test Procedures 0
2002-12-04 10:47:51 +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);
value description COUNT(bug_id)
BBBBBBBBBBBBB - conversion 2
BBBBBBBBBBBBB - eeeeeeeee 0
BBBBBBBBBBBBB - generic 2
Documentation 0
Host communication 0
Test Procedures 0
2001-09-28 07:05:54 +02:00
drop table t1,t2;
create table t1 (foo int);
insert into t1 values (1);
select 1+1, "a",count(*) from t1 where foo in (2);
2001-04-21 16:12:59 +02:00
1+1 a count(*)
2 a 0
2001-09-28 07:05:54 +02:00
insert into t1 values (1);
select 1+1,"a",count(*) from t1 where foo in (2);
2001-04-21 16:12:59 +02:00
1+1 a count(*)
2 a 0
2001-09-28 07:05:54 +02:00
drop table t1;
2001-12-13 01:31:19 +01:00
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-13 01:31:19 +01:00
explain select userid,count(*) from t1 group by userid desc;
2002-09-26 22:08:22 +02:00
id select_type table type possible_keys key key_len ref rows Extra
2003-05-21 20:39:58 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 8 Using temporary; Using filesort
2003-01-28 07:38:28 +01:00
explain select userid,count(*) from t1 group by userid desc order by null;
2003-02-04 20:52:14 +01:00
id select_type table type possible_keys key key_len ref rows Extra
2003-05-21 20:39:58 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 8 Using temporary
2001-12-13 01:31:19 +01:00
select userid,count(*) from t1 group by userid desc;
userid count(*)
2003-04-23 20:52:16 +02:00
3 5
2001-12-13 01:31:19 +01:00
2 1
1 2
2002-12-04 10:47:51 +01:00
select userid,count(*) from t1 group by userid desc having (count(*)+1) IN (4,3);
userid count(*)
1 2
select userid,count(*) from t1 group by userid desc having 3 IN (1,COUNT(*));
userid count(*)
2001-12-13 01:31:19 +01:00
explain select spid,count(*) from t1 where spid between 1 and 2 group by spid desc;
2002-09-26 22:08:22 +02:00
id select_type table type possible_keys key key_len ref rows Extra
2003-05-21 20:39:58 +02:00
1 SIMPLE t1 range spID spID 5 NULL 3 Using where; Using index
2003-02-07 14:47:24 +01:00
explain select spid,count(*) from t1 where spid between 1 and 2 group by spid;
2003-02-04 20:52:14 +01:00
id select_type table type possible_keys key key_len ref rows Extra
2003-05-21 20:39:58 +02:00
1 SIMPLE t1 range spID spID 5 NULL 3 Using where; Using index
2003-02-07 14:47:24 +01:00
explain select spid,count(*) from t1 where spid between 1 and 2 group by spid order by null;
2002-09-26 22:08:22 +02:00
id select_type table type possible_keys key key_len ref rows Extra
2003-05-21 20:39:58 +02:00
1 SIMPLE t1 range spID spID 5 NULL 3 Using where; Using index
2001-12-13 01:31:19 +01:00
select spid,count(*) from t1 where spid between 1 and 2 group by spid;
spid count(*)
1 1
2 2
select spid,count(*) from t1 where spid between 1 and 2 group by spid desc;
spid count(*)
2002-03-02 08:51:24 +01:00
2 2
1 1
2003-12-19 15:25:50 +01:00
explain extended select sql_big_result spid,sum(userid) from t1 group by spid desc;
2006-07-28 19:27:01 +02:00
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 8 100.00 Using filesort
2003-10-30 11:57:26 +01:00
Warnings:
2004-07-20 07:48:28 +02:00
Note 1003 select sql_big_result `test`.`t1`.`spID` AS `spid`,sum(`test`.`t1`.`userID`) AS `sum(userid)` from `test`.`t1` group by `test`.`t1`.`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;
2003-02-04 20:52:14 +01:00
id select_type table type possible_keys key key_len ref rows Extra
2003-12-19 15:25:50 +01:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 8 Using filesort
2001-12-13 01:31:19 +01:00
select sql_big_result spid,sum(userid) from t1 group by spid desc;
spid sum(userid)
2003-04-23 20:52:16 +02:00
7 3
6 3
2001-12-13 01:31:19 +01:00
5 3
4 3
3 3
2 3
1 1
explain select sql_big_result score,count(*) from t1 group by score desc;
2002-09-26 22:08:22 +02:00
id select_type table type possible_keys key key_len ref rows Extra
2006-10-09 17:51:41 +02:00
1 SIMPLE t1 index NULL score 3 NULL 8 Using index; Using filesort
2003-01-28 07:38:28 +01:00
explain select sql_big_result score,count(*) from t1 group by score desc order by null;
2003-02-04 20:52:14 +01:00
id select_type table type possible_keys key key_len ref rows Extra
2006-10-09 17:51:41 +02:00
1 SIMPLE t1 index NULL score 3 NULL 8 Using index; Using filesort
2001-12-13 01:31:19 +01:00
select sql_big_result score,count(*) from t1 group by score desc;
score count(*)
2003-04-23 20:52:16 +02:00
3 5
2001-12-13 01:31:19 +01:00
2 1
1 2
drop table t1;
2003-03-13 14:34:07 +01:00
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;
a c count(distinct rand())
drop table t1;
2002-01-15 23:42:52 +01:00
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;
a
NULL
A
B
SELECT a,count(*) FROM t1 GROUP BY a;
a count(*)
NULL 3
A 5
B 5
SELECT a FROM t1 GROUP BY binary a;
a
NULL
A
B
a
b
SELECT a,count(*) FROM t1 GROUP BY binary a;
a count(*)
NULL 3
A 4
B 4
a 1
b 1
SELECT binary a FROM t1 GROUP BY 1;
binary a
NULL
A
B
a
b
SELECT binary a,count(*) FROM t1 GROUP BY 1;
binary a count(*)
NULL 3
A 4
B 4
a 1
b 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=1;
2002-01-15 23:42:52 +01:00
SELECT a FROM t1 GROUP BY a;
a
NULL
A
B
SELECT a,count(*) FROM t1 GROUP BY a;
a count(*)
NULL 3
A 5
B 5
SELECT a FROM t1 GROUP BY binary a;
a
NULL
A
B
a
b
SELECT a,count(*) FROM t1 GROUP BY binary a;
a count(*)
NULL 3
A 4
B 4
a 1
b 1
SELECT binary a FROM t1 GROUP BY 1;
binary a
NULL
A
B
a
b
SELECT binary a,count(*) FROM t1 GROUP BY 1;
binary a count(*)
NULL 3
A 4
B 4
a 1
b 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
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;
CONCAT(a, b)
abcdef
hijklm
SELECT CONCAT(a, b),count(*) FROM t1 GROUP BY 1;
CONCAT(a, b) count(*)
abcdef 1
hijklm 1
SELECT CONCAT(a, b),count(distinct a) FROM t1 GROUP BY 1;
CONCAT(a, b) count(distinct a)
abcdef 1
hijklm 1
SELECT 1 FROM t1 GROUP BY CONCAT(a, b);
1
1
1
INSERT INTO t1 values ('hij','klm');
SELECT CONCAT(a, b),count(*) FROM t1 GROUP BY 1;
CONCAT(a, b) count(*)
abcdef 1
hijklm 2
DROP TABLE t1;
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;
One Two sum(Four)
1 1 16
1 2 16
1 3 16
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;
gender dist_count percentage
2005-05-05 22:01:39 +02:00
F 3 60.0000
M 1 20.0000
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 order by percentage;
gender dist_count percentage
2005-05-05 22:01:39 +02:00
M 1 20.0000
F 3 60.0000
2002-06-08 19:02:49 +02:00
drop table t1,t2;
2002-08-08 15:41:04 +02:00
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-08 15:41:04 +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;
xID xID1
1 1
2 2
2 2
3 134
3 134
3 134
4 185
4 185
4 185
4 185
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;
xID xID1 Level
1 1 *
2 2 **
3 134 ***
4 185 ****
2011-12-15 09:21:15 +01:00
SET optimizer_switch=@save_optimizer_switch;
2002-08-08 15:41:04 +02:00
drop table t1;
2002-11-09 08:51:03 +01:00
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);
pid c1id c2id value id active id active
1 1 NULL 1 1 Yes NULL NULL
1 NULL 3 3 NULL NULL 3 Yes
1 4 NULL 4 4 Yes NULL 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);
max(value)
4
drop table t1,t2,t3;
2003-01-17 12:57:15 +01:00
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;
a count(*)
NULL 9
3
b 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=1;
2003-01-17 12:57:15 +01:00
select a,count(*) from t1 group by a;
a count(*)
NULL 9
3
b 1
drop table t1;
2003-01-28 07:38:28 +01:00
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;
a b
1 1
1 3
2 2
3 1
select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b ORDER BY NULL;
a b
1 3
3 1
2 2
1 1
explain select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b;
2003-02-07 14:47:24 +01:00
id select_type table type possible_keys key key_len ref rows Extra
2007-05-29 14:58:18 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 6 Using temporary; Using filesort
2010-10-18 22:33:05 +02:00
1 SIMPLE t2 ALL a NULL NULL NULL 4 Using where; Using join buffer (flat, BNL join)
2003-01-28 07:38:28 +01:00
explain select t1.a,t2.b from t1,t2 where t1.a=t2.a group by t1.a,t2.b ORDER BY NULL;
2003-02-07 14:47:24 +01:00
id select_type table type possible_keys key key_len ref rows Extra
2007-05-29 14:58:18 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 6 Using temporary
2010-10-18 22:33:05 +02:00
1 SIMPLE t2 ALL a NULL NULL NULL 4 Using where; Using join buffer (flat, BNL join)
2003-01-28 07:38:28 +01:00
drop table t1,t2;
2003-01-29 18:33:48 +01:00
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 18:33:48 +01:00
select a, MAX(b), INTERVAL (MAX(b), 1,3,10,30,39,40,50,60,100,1000) from t1 group by a;
2003-01-29 09:38:56 +01:00
a MAX(b) INTERVAL (MAX(b), 1,3,10,30,39,40,50,60,100,1000)
1 4 2
10 43 6
2003-01-29 18:33:48 +01:00
select a, MAX(b), CASE MAX(b) when 4 then 4 when 43 then 43 else 0 end from t1 group by a;
2003-01-29 09:38:56 +01:00
a MAX(b) CASE MAX(b) when 4 then 4 when 43 then 43 else 0 end
1 4 4
10 43 43
2003-01-29 18:33:48 +01:00
select a, MAX(b), FIELD(MAX(b), '43', '4', '5') from t1 group by a;
2003-01-29 09:38:56 +01:00
a MAX(b) FIELD(MAX(b), '43', '4', '5')
1 4 2
10 43 1
2003-01-29 18:33:48 +01:00
select a, MAX(b), CONCAT_WS(MAX(b), '43', '4', '5') from t1 group by a;
2003-01-29 09:38:56 +01:00
a MAX(b) CONCAT_WS(MAX(b), '43', '4', '5')
1 4 434445
10 43 43434435
2003-01-29 18:33:48 +01:00
select a, MAX(b), ELT(MAX(b), 'a', 'b', 'c', 'd', 'e', 'f') from t1 group by a;
2003-01-29 09:38:56 +01:00
a MAX(b) ELT(MAX(b), 'a', 'b', 'c', 'd', 'e', 'f')
1 4 d
10 43 NULL
2003-01-29 18:33:48 +01:00
select a, MAX(b), MAKE_SET(MAX(b), 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h') from t1 group by a;
2003-01-29 09:38:56 +01:00
a MAX(b) MAKE_SET(MAX(b), 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h')
1 4 c
10 43 a,b,d,f
2003-01-29 18:33:48 +01:00
drop table t1;
2003-03-25 12:06:20 +01:00
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;
id sqty cqty
1 5 2
2 9 2
select id, sum(qty) as sqty from t1 group by id having sqty>2 and count(qty)>1;
id sqty
1 5
2 9
select id, sum(qty) as sqty, count(qty) as cqty from t1 group by id having sqty>2 and cqty>1;
id sqty cqty
1 5 2
2 9 2
select id, sum(qty) as sqty, count(qty) as cqty from t1 group by id having sum(qty)>2 and count(qty)>1;
id sqty cqty
1 5 2
2 9 2
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;
count(*) category
2 NULL
1 one
1 two
select count(*), interval(qty,2,3,4,5,6,7,8) as category from t1 group by category;
count(*) category
1 1
1 2
1 3
1 4
2003-03-25 12:06:20 +01:00
drop table t1;
2003-12-09 23:08:10 +01:00
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);
SELECT userid,count(*) FROM t1 GROUP BY userid DESC;
2003-12-09 21:52:58 +01:00
userid count(*)
3 5
2 1
1 2
EXPLAIN SELECT userid,count(*) FROM t1 GROUP BY userid DESC;
2003-12-19 15:25:50 +01:00
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 8 Using temporary; Using filesort
2003-12-09 23:08:10 +01:00
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;
2003-12-09 21:52:58 +01:00
i COUNT(DISTINCT(i))
1 1
2 1
4 4
explain SELECT i, COUNT(DISTINCT(i)) FROM t1 GROUP BY j ORDER BY NULL;
2003-12-19 15:25:50 +01:00
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 6 Using filesort
2003-12-09 21:52:58 +01:00
DROP TABLE t1;
2004-12-11 17:59:09 +01:00
create table t1 (a int);
insert into t1 values(null);
select min(a) is null from t1;
min(a) is null
1
select min(a) is null or null from t1;
min(a) is null or null
1
select 1 and min(a) is null from t1;
1 and min(a) is null
1
drop table t1;
2005-02-07 17:13:57 +01:00
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 '%';
alias
1,2
1,2
1
drop table t1;
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;
a r2 r1
1 1.0 2
2005-02-08 13:41:09 +01:00
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
a r2 r1
2005-02-08 13:41:09 +01:00
1 2 2
2005-02-07 17:13:57 +01:00
select a,sum(b) from t1 where a=1 group by c;
a sum(b)
1 5
select a*sum(b) from t1 where a=1 group by c;
a*sum(b)
5
select sum(a)*sum(b) from t1 where a=1 group by c;
sum(a)*sum(b)
10
select a,sum(b) from t1 where a=1 group by c having a=1;
a sum(b)
1 5
select a as d,sum(b) from t1 where a=1 group by c having d=1;
d sum(b)
1 5
select sum(a)*sum(b) as d from t1 where a=1 group by c having d > 0;
d
10
drop table t1;
2005-03-30 13:57:42 +02:00
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;
id select_type table type possible_keys key key_len ref rows Extra
2005-04-01 01:14:30 +02:00
1 SIMPLE t2 ref PRIMARY,a PRIMARY 402 const,const 6 Using where
2005-03-30 13:57:42 +02:00
select c from t2 where a = 2 and b = 'val-2' group by c;
c
val-74
val-98
drop table t1,t2;
2005-04-18 05:26:23 +02:00
create table t1 (b int4 unsigned not null);
insert into t1 values(3000000000);
select * from t1;
b
3000000000
select min(b) from t1;
min(b)
3000000000
drop table t1;
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;
hostname no
2005-07-04 02:24:25 +02:00
cache-dtc-af05.proxy.aol.com 1
DROP TABLE t1;
2005-07-04 15:01:04 +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';
a b
1 2
SELECT DISTINCT a, b FROM t1 GROUP BY 'const';
a b
1 2
DROP TABLE t1;
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;
f id
20050501123000 1
DROP TABLE t1;
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');
SELECT COUNT(DISTINCT(t1.id)), LEFT(err_comment, 256) AS comment
FROM t1 LEFT JOIN t2 ON t1.id=t2.id GROUP BY comment;
COUNT(DISTINCT(t1.id)) comment
1 NULL
1 a problem
DROP TABLE t1, t2;
2005-09-09 10:57:00 +02:00
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;
date(left(f1+0,8))
2005-06-06
drop table t1;
2005-08-08 00:10:05 +02:00
CREATE TABLE t1 (n int);
INSERT INTO t1 VALUES (1);
SELECT n+1 AS n FROM t1 GROUP BY n;
n
2
2005-07-04 02:24:25 +02:00
Warnings:
Warning 1052 Column 'n' in group statement is ambiguous
2005-06-16 20:59:00 +02:00
DROP TABLE t1;
2005-09-09 12:47:57 +02:00
create table t1(f1 varchar(5) key);
insert into t1 values (1),(2);
select sql_buffer_result max(f1) is null from t1;
max(f1) is null
0
select sql_buffer_result max(f1)+1 from t1;
max(f1)+1
3
drop table t1;
2006-10-16 12:10:25 +02:00
CREATE TABLE t1(a INT);
INSERT INTO t1 VALUES (1),(2);
SELECT a FROM t1 GROUP BY 'a';
a
1
SELECT a FROM t1 GROUP BY "a";
a
1
SELECT a FROM t1 GROUP BY `a`;
a
1
2
set sql_mode=ANSI_QUOTES;
SELECT a FROM t1 GROUP BY "a";
a
1
2
SELECT a FROM t1 GROUP BY 'a';
a
1
SELECT a FROM t1 GROUP BY `a`;
a
1
2
set sql_mode='';
SELECT a FROM t1 HAVING 'a' > 1;
a
2006-10-16 15:27:06 +02:00
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'a'
2006-10-16 12:10:25 +02:00
SELECT a FROM t1 HAVING "a" > 1;
a
2006-10-16 15:27:06 +02:00
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'a'
2006-10-16 12:10:25 +02:00
SELECT a FROM t1 HAVING `a` > 1;
a
2
SELECT a FROM t1 ORDER BY 'a' DESC;
a
1
2
SELECT a FROM t1 ORDER BY "a" DESC;
a
1
2
SELECT a FROM t1 ORDER BY `a` DESC;
a
2
1
DROP TABLE t1;
2007-07-31 08:10:03 +02:00
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;
avg(t2.f1)
SELECT avg(t2.f1) FROM t1, t2 where t2.f2 = 'SIR' GROUP BY t1.f1;
avg(t2.f1)
DROP TABLE t1, t2;
2005-07-04 02:42:33 +02:00
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');
select t1.c1 as c2 from t1, t2 where t1.c2 = t2.c4
group by c2;
c2
aaa
aaa
Warnings:
Warning 1052 Column 'c2' in group statement is ambiguous
show warnings;
Level Code Message
Warning 1052 Column 'c2' in group statement is ambiguous
select t1.c1 as c2 from t1, t2 where t1.c2 = t2.c4
group by t1.c1;
c2
aaa
show warnings;
Level Code Message
drop table t1, t2;
2006-07-21 19:44:35 +02:00
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;
id select_type table type possible_keys key key_len ref rows Extra
2010-09-28 21:39:33 +02:00
1 SIMPLE t2 index b b 2 NULL 10 Using where; Using index
2006-09-06 17:21:43 +02:00
1 SIMPLE t1 eq_ref PRIMARY PRIMARY 1 test.t2.b 1
2006-07-21 19:44:35 +02:00
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;
a b real_b
1 ----- -----
6 Allemagne Allemagne
17 Autriche Autriche
25 Belgique Belgique
54 Danemark Danemark
62 Espagne Espagne
68 France France
DROP VIEW v1;
DROP TABLE t1,t2;
2006-10-09 17:51:41 +02:00
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;
MIN(b) MAX(b)
0 19
EXPLAIN SELECT b, sum(1) FROM t1 GROUP BY b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL b 5 NULL 128 Using index
EXPLAIN SELECT SQL_BIG_RESULT b, sum(1) FROM t1 GROUP BY b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL b 5 NULL 128 Using index; Using filesort
SELECT b, sum(1) FROM t1 GROUP BY b;
b sum(1)
0 6
1 7
2 7
3 7
4 7
5 7
6 7
7 7
8 7
9 6
10 6
11 6
12 6
13 6
14 6
15 6
16 6
17 6
18 6
19 6
SELECT SQL_BIG_RESULT b, sum(1) FROM t1 GROUP BY b;
b sum(1)
0 6
1 7
2 7
3 7
4 7
5 7
6 7
7 7
8 7
9 6
10 6
11 6
12 6
13 6
14 6
15 6
16 6
17 6
18 6
19 6
DROP TABLE t1;
2007-01-11 21:18:01 +01:00
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;
MAX(a)-MIN(a)
1
1
1
SELECT CEILING(MIN(a)) FROM t1 GROUP BY b;
CEILING(MIN(a))
1
3
5
SELECT CASE WHEN AVG(a)>=0 THEN 'Positive' ELSE 'Negative' END FROM t1
GROUP BY b;
CASE WHEN AVG(a)>=0 THEN 'Positive' ELSE 'Negative' END
Positive
Positive
Positive
SELECT a + 1 FROM t1 GROUP BY a;
a + 1
2
3
4
5
6
7
SELECT a + b FROM t1 GROUP BY b;
ERROR 42000: 'test.t1.a' isn't in GROUP BY
SELECT (SELECT t1_outer.a FROM t1 AS t1_inner GROUP BY b LIMIT 1)
FROM t1 AS t1_outer;
(SELECT t1_outer.a FROM t1 AS t1_inner GROUP BY b LIMIT 1)
1
2
3
4
5
6
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);
1
1
1
1
1
1
1
SELECT (SELECT t1_outer.a FROM t1 AS t1_inner LIMIT 1)
FROM t1 AS t1_outer GROUP BY t1_outer.b;
ERROR 42000: 'test.t1_outer.a' isn't in GROUP BY
SELECT 1 FROM t1 as t1_outer GROUP BY a
HAVING (SELECT t1_outer.b FROM t1 AS t1_inner LIMIT 1);
ERROR 42S22: Unknown column 'test.t1_outer.b' in 'field list'
SELECT (SELECT SUM(t1_inner.a) FROM t1 AS t1_inner LIMIT 1)
FROM t1 AS t1_outer GROUP BY t1_outer.b;
(SELECT SUM(t1_inner.a) FROM t1 AS t1_inner LIMIT 1)
21
21
21
SELECT (SELECT SUM(t1_inner.a) FROM t1 AS t1_inner GROUP BY t1_inner.b LIMIT 1)
FROM t1 AS t1_outer;
(SELECT SUM(t1_inner.a) FROM t1 AS t1_inner GROUP BY t1_inner.b LIMIT 1)
3
3
3
3
3
3
SELECT (SELECT SUM(t1_outer.a) FROM t1 AS t1_inner LIMIT 1)
FROM t1 AS t1_outer GROUP BY t1_outer.b;
ERROR 42000: 'test.t1_outer.a' isn't in GROUP BY
SELECT 1 FROM t1 as t1_outer
WHERE (SELECT t1_outer.b FROM t1 AS t1_inner GROUP BY t1_inner.b LIMIT 1);
1
1
1
1
1
1
1
SELECT b FROM t1 GROUP BY b HAVING CEILING(b) > 0;
b
1
2
3
SELECT 1 FROM t1 GROUP BY b HAVING b = 2 OR b = 3 OR SUM(a) > 12;
1
1
1
SELECT 1 FROM t1 GROUP BY b HAVING ROW (b,b) = ROW (1,1);
1
1
SELECT 1 FROM t1 GROUP BY b HAVING a = 2;
ERROR 42S22: Unknown column 'a' in 'having clause'
SELECT 1 FROM t1 GROUP BY SUM(b);
ERROR HY000: Invalid use of group function
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);
ERROR 42000: 'test.t1_outer.b' isn't in GROUP BY
DROP TABLE t1;
SET SQL_MODE = '';
2007-04-24 20:35:57 +02:00
SET SQL_MODE = 'ONLY_FULL_GROUP_BY';
create table t1(f1 int, f2 int);
select * from t1 group by f1;
ERROR 42000: 'test.t1.f2' isn't in GROUP BY
select * from t1 group by f2;
ERROR 42000: 'test.t1.f1' isn't in GROUP BY
select * from t1 group by f1, f2;
f1 f2
select t1.f1,t.* from t1, t1 t group by 1;
ERROR 42000: 'test.t.f1' isn't in GROUP BY
drop table t1;
SET SQL_MODE = '';
2007-08-27 17:33:41 +02:00
CREATE TABLE t1(
2007-11-09 17:12:12 +01:00
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);
SELECT * FROM t1 ORDER BY c1;
id c1 c2
5 1 3
4 2 3
3 3 5
2 4 1
1 5 1
SELECT * FROM t1 GROUP BY id ORDER BY c1;
id c1 c2
5 1 3
4 2 3
3 3 5
2 4 1
1 5 1
SELECT * FROM t1 GROUP BY id ORDER BY id DESC;
id c1 c2
5 1 3
4 2 3
3 3 5
2 4 1
1 5 1
SELECT * FROM t1 GROUP BY c2 ,c1, id ORDER BY c2, c1;
id c1 c2
2 4 1
1 5 1
5 1 3
4 2 3
3 3 5
SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1;
id c1 c2
3 3 5
5 1 3
4 2 3
2 4 1
1 5 1
SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1 DESC;
id c1 c2
3 3 5
4 2 3
5 1 3
1 5 1
2 4 1
SELECT * FROM t1 GROUP BY c2 ORDER BY c2, c1;
id c1 c2
1 5 1
4 2 3
3 3 5
SELECT * FROM t1 GROUP BY c2 ORDER BY c2 DESC, c1;
id c1 c2
3 3 5
4 2 3
1 5 1
SELECT * FROM t1 GROUP BY c2 ORDER BY c2 DESC, c1 DESC;
id c1 c2
3 3 5
4 2 3
1 5 1
DROP TABLE t1;
2008-03-27 17:49:32 +01:00
#
# Bug#27219: Aggregate functions in ORDER BY.
#
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(*);
1
1
SELECT 1 FROM t1 ORDER BY COUNT(*) + 1;
1
1
SELECT 1 FROM t1 ORDER BY COUNT(*) + a;
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT 1 FROM t1 ORDER BY COUNT(*), 1;
1
1
SELECT 1 FROM t1 ORDER BY COUNT(*), a;
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT 1 FROM t1 ORDER BY SUM(a);
1
1
SELECT 1 FROM t1 ORDER BY SUM(a + 1);
1
1
SELECT 1 FROM t1 ORDER BY SUM(a) + 1;
1
1
SELECT 1 FROM t1 ORDER BY SUM(a), b;
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT a FROM t1 ORDER BY COUNT(b);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT t1.a FROM t1 ORDER BY (SELECT SUM(t2.a) FROM t2);
a
3
2
3
2
3
4
SELECT t1.a FROM t1 ORDER BY (SELECT SUM(t2.a), t2.a FROM t2);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT t1.a FROM t1 ORDER BY (SELECT SUM(t2.a) FROM t2 ORDER BY t2.a);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT t1.a FROM t1 ORDER BY (SELECT t2.a FROM t2 ORDER BY SUM(t2.b) LIMIT 1);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT t1.a FROM t1
WHERE t1.a = (SELECT t2.a FROM t2 ORDER BY SUM(t2.b) LIMIT 1);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING t1.a = (SELECT t2.a FROM t2 ORDER BY SUM(t2.a) LIMIT 1);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING t1.a IN (SELECT t2.a FROM t2 ORDER BY SUM(t1.b));
a
2
3
4
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 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
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 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT t1.a FROM t1
WHERE t1.a = (SELECT t2.a FROM t2 ORDER BY SUM(t1.b));
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(SUM(t1.b) + 1) FROM t2 ORDER BY SUM(t2.a) LIMIT 1);
1
1
1
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);
1
1
1
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);
1
1
1
1
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(SUM(t1.b) + 1) FROM t2 ORDER BY t2.a LIMIT 1);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
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 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
SELECT 1 FROM t1 GROUP BY t1.a
HAVING (SELECT AVG(t1.b + t2.b) FROM t2 ORDER BY t2.a LIMIT 1);
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
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);
a
4
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;
a SUM(t1.b)
4 4
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;
a SUM(t1.b)
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;
a SUM(t1.b)
SELECT t1.a FROM t1 GROUP BY t1.a
HAVING (1, 1) = (SELECT SUM(t1.a), t1.a FROM t2 LIMIT 1);
a
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;
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))
29.0000
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;
ERROR 42000: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
select (select sum(outr.a + t1.a) from t1 limit 1) as tt from t1 as outr order by outr.a;
tt
29
29
35
35
35
41
SET sql_mode=@save_sql_mode;
DROP TABLE t1, t2;
2008-10-24 04:16:22 +02:00
#
# BUG#38072: Wrong result: HAVING not observed in a query with aggregate
#
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';
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible HAVING
SELECT COUNT(varchar_key) AS X FROM t1 WHERE pk = 8 having 'foo'='bar';
X
drop table t1;
2007-11-09 17:12:12 +01:00
End of 5.0 tests
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;
Table Op Msg_type Msg_text
test.t1 analyze status OK
EXPLAIN SELECT a FROM t1 WHERE a < 2;
2006-08-14 17:19:29 +02:00
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 range PRIMARY,i2 PRIMARY 4 NULL 1 Using where; Using index
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 WHERE a < 2 ORDER BY a;
2006-08-14 17:19:29 +02:00
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 range PRIMARY,i2 PRIMARY 4 NULL 1 Using where; Using index
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 WHERE a < 2 GROUP BY a;
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 range PRIMARY,i2 PRIMARY 4 NULL 1 Using where; Using index
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 (PRIMARY,i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 144
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 JOIN (PRIMARY,i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 144
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 GROUP BY (PRIMARY,i2) GROUP BY a;
id select_type table type possible_keys key key_len ref rows Extra
2007-09-28 12:30:55 +02:00
1 SIMPLE t1 index NULL PRIMARY 4 NULL 144 Using index
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,i2) ORDER BY a;
id select_type table type possible_keys key key_len ref rows Extra
2007-09-28 09:36:05 +02:00
1 SIMPLE t1 index NULL PRIMARY 4 NULL 144 Using index
SELECT a FROM t1 IGNORE INDEX FOR ORDER BY (PRIMARY,i2) ORDER BY a;
a
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
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;
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 index NULL PRIMARY 4 NULL 144 Using index
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 (PRIMARY) IGNORE INDEX FOR ORDER BY (i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 index NULL i2 9 NULL 144 Using index
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 FORCE INDEX (i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 index NULL i2 9 NULL 144 Using index
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 ();
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 144
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 () USE INDEX (i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 144
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
FORCE INDEX (PRIMARY)
IGNORE INDEX FOR GROUP BY (i2)
IGNORE INDEX FOR ORDER BY (i2)
USE INDEX (i2);
ERROR HY000: Incorrect usage of USE INDEX and FORCE INDEX
EXPLAIN SELECT a FROM t1 USE INDEX (i2) USE INDEX ();
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 index NULL i2 9 NULL 144 Using index
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 FORCE INDEX ();
2011-12-12 23:58:40 +01:00
ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ')' at line 1
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 ();
2011-12-12 23:58:40 +01:00
ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ')' at line 1
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;
id select_type table type possible_keys key key_len ref rows Extra
2007-08-29 13:46:49 +02:00
1 SIMPLE t1 # NULL i2 # NULL # #
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 FORCE INDEX FOR JOIN (i2)
FORCE INDEX FOR GROUP BY (i2) GROUP BY a;
id select_type table type possible_keys key key_len ref rows Extra
2014-04-22 23:39:57 +02:00
1 SIMPLE t1 index NULL i2 9 NULL 144 Using index
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 () IGNORE INDEX (i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 144
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 (i2) USE INDEX ();
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 ALL NULL NULL NULL NULL 144
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 GROUP BY (i2)
USE INDEX FOR ORDER BY (i2)
USE INDEX FOR JOIN (i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 index NULL i2 9 NULL 144 Using index
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 JOIN (i2)
USE INDEX FOR JOIN (i2,i2);
id select_type table type possible_keys key key_len ref rows Extra
2007-06-12 14:10:33 +02:00
1 SIMPLE t1 index NULL i2 9 NULL 144 Using index
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));
id select_type table type possible_keys key key_len ref rows Extra
2011-11-02 10:48:41 +01:00
1 PRIMARY t1 index PRIMARY,i2 PRIMARY 4 NULL 144 Using index
2011-11-09 14:36:25 +01:00
1 PRIMARY <subquery2> eq_ref distinct_key distinct_key 4 func 1
2011-12-04 22:31:42 +01:00
2 MATERIALIZED t1 ALL NULL NULL NULL NULL 144
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;
id select_type table type possible_keys key key_len ref rows Extra
2007-08-02 21:45:56 +02:00
1 SIMPLE t2 index NULL a 5 NULL 2
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, SUM(b) FROM t2 IGNORE INDEX (a) GROUP BY a LIMIT 2;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 ALL NULL NULL NULL NULL 4 Using temporary; Using filesort
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));
id select_type table type possible_keys key key_len ref rows Extra
2011-11-02 10:48:41 +01:00
1 PRIMARY t2 index a a 5 NULL 4 Using index
1 PRIMARY t1 ALL NULL NULL NULL NULL 144 Using where; FirstMatch(t2)
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
DROP TABLE t1, t2;
2007-08-28 18:01:29 +02:00
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;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 3 Using filesort
SELECT c,b,d FROM t1 GROUP BY c,b,d;
c b d
1 1 50
3 1 4
3 2 40
EXPLAIN SELECT c,b,d FROM t1 GROUP BY c,b,d ORDER BY NULL;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 3
SELECT c,b,d FROM t1 GROUP BY c,b,d ORDER BY NULL;
c b d
1 1 50
3 2 40
3 1 4
EXPLAIN SELECT c,b,d FROM t1 ORDER BY c,b,d;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 3 Using filesort
SELECT c,b,d FROM t1 ORDER BY c,b,d;
c b d
1 1 50
3 1 4
3 2 40
EXPLAIN SELECT c,b,d FROM t1 GROUP BY c,b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 3 Using filesort
SELECT c,b,d FROM t1 GROUP BY c,b;
c b d
1 1 50
3 1 4
3 2 40
EXPLAIN SELECT c,b FROM t1 GROUP BY c,b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL c 8 NULL 3 Using index
SELECT c,b FROM t1 GROUP BY c,b;
c b
1 1
3 1
3 2
EXPLAIN SELECT a,b from t2 ORDER BY a,b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 index NULL a 10 NULL 6 Using index
SELECT a,b from t2 ORDER BY a,b;
a b
NULL NULL
NULL NULL
NULL 1
1 NULL
1 1
1 2
EXPLAIN SELECT a,b from t2 GROUP BY a,b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 index NULL a 10 NULL 6 Using index
SELECT a,b from t2 GROUP BY a,b;
a b
NULL NULL
NULL 1
1 NULL
1 1
1 2
EXPLAIN SELECT a from t2 GROUP BY a;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 index NULL a 10 NULL 6 Using index
SELECT a from t2 GROUP BY a;
a
NULL
1
EXPLAIN SELECT b from t2 GROUP BY b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 index NULL a 10 NULL 6 Using index; Using temporary; Using filesort
SELECT b from t2 GROUP BY b;
b
NULL
1
2
DROP TABLE t1;
2008-03-14 17:59:03 +01:00
DROP TABLE t2;
2008-01-11 18:50:54 +01:00
CREATE TABLE t1 ( a INT, b INT );
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1;
c (SELECT a FROM t1 WHERE b = c)
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
c (SELECT a FROM t1 WHERE b = c)
SELECT MAX(b) c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
ERROR 42S22: Reference 'c' not supported (reference to group function)
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;
c (SELECT a FROM t1 WHERE b = c)
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
2011-09-29 14:31:46 +02:00
ERROR 42000: Non-grouping field 'b' is used in HAVING clause
2008-01-11 18:50:54 +01:00
SELECT MAX(b) c, (SELECT a FROM t1 WHERE b = c)
FROM t1
HAVING b = 10;
ERROR 42S22: Reference 'c' not supported (reference to group function)
INSERT INTO t1 VALUES (1, 1);
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1;
c (SELECT a FROM t1 WHERE b = c)
1 1
INSERT INTO t1 VALUES (2, 1);
SELECT b c, (SELECT a FROM t1 WHERE b = c)
FROM t1;
ERROR 21000: Subquery returns more than 1 row
DROP TABLE t1;
SET @@sql_mode = @old_sql_mode;
2009-02-26 18:17:06 +01:00
SET @old_sql_mode = @@sql_mode;
SET @@sql_mode='ONLY_FULL_GROUP_BY';
CREATE TABLE t1(i INT);
INSERT INTO t1 VALUES (1), (10);
SELECT COUNT(i) FROM t1;
COUNT(i)
2
SELECT COUNT(i) FROM t1 WHERE i > 1;
COUNT(i)
1
DROP TABLE t1;
SET @@sql_mode = @old_sql_mode;
2010-02-06 20:54:30 +01:00
#
# Bug #45640: optimizer bug produces wrong results
#
CREATE TABLE t1 (a INT, b INT);
INSERT INTO t1 VALUES (4, 40), (1, 10), (2, 20), (2, 20), (3, 30);
# should return 4 ordered records:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa;
aa COUNT(DISTINCT b)
1 1
2 1
3 1
4 1
SELECT (SELECT (SELECT t1.a)) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa;
aa COUNT(DISTINCT b)
1 1
2 1
3 1
4 1
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa+0;
aa COUNT(DISTINCT b)
1 1
2 1
3 1
4 1
# should return the same result in a reverse order:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY -aa;
aa COUNT(DISTINCT b)
4 1
3 1
2 1
1 1
# execution plan should not use temporary table:
EXPLAIN EXTENDED
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY aa+0;
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 5 100.00 Using filesort
2 DEPENDENT SUBQUERY NULL NULL NULL NULL NULL NULL NULL NULL No tables used
Warnings:
Note 1276 Field or reference 'test.t1.a' of SELECT #2 was resolved in SELECT #1
2011-10-05 17:18:00 +02:00
Note 1003 select <expr_cache><`test`.`t1`.`a`>((select `test`.`t1`.`a`)) AS `aa`,count(distinct `test`.`t1`.`b`) AS `COUNT(DISTINCT b)` from `test`.`t1` group by (<expr_cache><`test`.`t1`.`a`>((select `test`.`t1`.`a`)) + 0)
2010-02-06 20:54:30 +01:00
EXPLAIN EXTENDED
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) FROM t1 GROUP BY -aa;
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 5 100.00 Using filesort
2 DEPENDENT SUBQUERY NULL NULL NULL NULL NULL NULL NULL NULL No tables used
Warnings:
Note 1276 Field or reference 'test.t1.a' of SELECT #2 was resolved in SELECT #1
2011-10-05 17:18:00 +02:00
Note 1003 select <expr_cache><`test`.`t1`.`a`>((select `test`.`t1`.`a`)) AS `aa`,count(distinct `test`.`t1`.`b`) AS `COUNT(DISTINCT b)` from `test`.`t1` group by -(<expr_cache><`test`.`t1`.`a`>((select `test`.`t1`.`a`)))
2010-02-06 20:54:30 +01:00
# should return only one record
SELECT (SELECT tt.a FROM t1 tt LIMIT 1) aa, COUNT(DISTINCT b) FROM t1
GROUP BY aa;
aa COUNT(DISTINCT b)
4 4
CREATE TABLE t2 SELECT DISTINCT a FROM t1;
# originally reported queries (1st two columns of next two query
# 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;
aa b COUNT(DISTINCT b)
1 10 1
2 20 1
3 30 1
4 40 1
SELECT (SELECT t2.a FROM t2 WHERE t2.a = t1.a) aa, b, COUNT( b)
FROM t1 GROUP BY aa, b;
aa b COUNT( b)
1 10 1
2 20 2
3 30 1
4 40 1
# 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;
aa b COUNT(DISTINCT b)
4 40 1
3 30 1
2 20 1
1 10 1
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;
aa b COUNT( b)
4 40 1
3 30 1
2 20 2
1 10 1
DROP TABLE t1, t2;
#
2010-05-12 18:10:33 +02:00
# Bug#52051: Aggregate functions incorrectly returns NULL from outer
# join query
#
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;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Select tables optimized away
SELECT MIN(t2.a) FROM t2 LEFT JOIN t1 ON t2.a = t1.a;
MIN(t2.a)
1
EXPLAIN SELECT MAX(t2.a) FROM t2 LEFT JOIN t1 ON t2.a = t1.a;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Select tables optimized away
SELECT MAX(t2.a) FROM t2 LEFT JOIN t1 ON t2.a = t1.a;
MAX(t2.a)
2
DROP TABLE t1, t2;
2010-08-23 11:46:25 +02:00
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;
min(t2.key_col)
1
select min(t2.key_col) from t1,t2 where t1.a > 1000;
min(t2.key_col)
NULL
select min(t2.key_col)+1 from t1,t2 where t1.a> 1000;
min(t2.key_col)+1
NULL
drop table t1,t2;
2010-05-12 18:10:33 +02:00
#
2010-07-30 15:35:06 +02:00
# Bug#55188: GROUP BY, GROUP_CONCAT and TEXT - inconsistent results
#
CREATE TABLE t1 (a text, b varchar(10));
INSERT INTO t1 VALUES (repeat('1', 1300),'one'), (repeat('1', 1300),'two');
EXPLAIN
SELECT SUBSTRING(a,1,10), LENGTH(a), GROUP_CONCAT(b) FROM t1 GROUP BY a;
id 1
select_type SIMPLE
table t1
type ALL
possible_keys NULL
key NULL
key_len NULL
ref NULL
rows 2
Extra Using filesort
SELECT SUBSTRING(a,1,10), LENGTH(a), GROUP_CONCAT(b) FROM t1 GROUP BY a;
SUBSTRING(a,1,10) LENGTH(a) GROUP_CONCAT(b)
1111111111 1300 one,two
EXPLAIN
SELECT SUBSTRING(a,1,10), LENGTH(a) FROM t1 GROUP BY a;
id 1
select_type SIMPLE
table t1
type ALL
possible_keys NULL
key NULL
key_len NULL
ref NULL
rows 2
Extra Using temporary; Using filesort
SELECT SUBSTRING(a,1,10), LENGTH(a) FROM t1 GROUP BY a;
SUBSTRING(a,1,10) LENGTH(a)
1111111111 1300
DROP TABLE t1;
2010-10-29 10:23:06 +02:00
#
# Bug#57688 Assertion `!table || (!table->write_set || bitmap_is_set(table->write_set, field
#
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;
COUNT(*)
2
DROP TABLE t1;
2011-02-18 11:50:06 +01:00
#
# Bug#59839: Aggregation followed by subquery yields wrong result
#
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;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 index NULL a 10 NULL 9 Using index
2011-11-21 14:16:16 +01:00
3 DEPENDENT SUBQUERY t12 ref a a 10 func,func 2 Using index condition
2 DEPENDENT SUBQUERY t11 ref a a 10 func,func 2 Using index condition
2011-02-18 11:50:06 +01:00
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;
a AVG(t1.b) t11c t12c
1 4.0000 6 6
2 2.0000 7 7
DROP TABLE t1;
2011-08-30 09:56:07 +02:00
#
# Bug#11765254 (58200): Assertion failed: param.sort_length when grouping
# by functions
#
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`,'','');
1
1
SELECT 1 FROM t1 GROUP BY TRIM(LEADING RAND() FROM '');
1
1
SELECT 1 FROM t1 GROUP BY SUBSTRING('',SLEEP(0),'');
1
1
Warnings:
Warning 1292 Truncated incorrect INTEGER value: ''
Warning 1292 Truncated incorrect INTEGER value: ''
Warning 1292 Truncated incorrect INTEGER value: ''
SELECT 1 FROM t1 GROUP BY SUBSTRING(SYSDATE() FROM 'K' FOR 'jxW<');
1
1
Warnings:
Warning 1292 Truncated incorrect INTEGER value: 'K'
Warning 1292 Truncated incorrect INTEGER value: 'jxW<'
Warning 1292 Truncated incorrect INTEGER value: 'K'
Warning 1292 Truncated incorrect INTEGER value: 'jxW<'
Warning 1292 Truncated incorrect INTEGER value: 'K'
Warning 1292 Truncated incorrect INTEGER value: '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;
2013-01-31 23:09:36 +01:00
#
# MDEV-641 LP:1002108 - Wrong result (or crash) from a query with duplicated field in the group list and a limit clause
# Bug#11761078: 53534: INCORRECT 'SELECT SQL_BIG_RESULT...'
# WITH GROUP BY ON DUPLICATED FIELDS
#
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);
EXPLAIN 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
id select_type table type possible_keys key key_len ref rows Extra
2014-04-22 23:39:57 +02:00
1 SIMPLE t1 index NULL idx 5 NULL 20 Using index
2013-01-31 23:09:36 +01:00
FLUSH STATUS;
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
field1 field2
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
SHOW SESSION STATUS LIKE 'Sort_scan%';
Variable_name Value
2014-04-22 23:39:57 +02:00
Sort_scan 0
2013-01-31 23:09:36 +01:00
EXPLAIN SELECT SQL_BIG_RESULT col1 AS field1, col1 AS field2
FROM t1 GROUP BY field1, field2;;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL idx 5 NULL 20 Using index; Using filesort
FLUSH STATUS;
SELECT SQL_BIG_RESULT col1 AS field1, col1 AS field2
FROM t1 GROUP BY field1, field2;;
field1 field2
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
SHOW SESSION STATUS LIKE 'Sort_scan%';
Variable_name Value
Sort_scan 1
CREATE VIEW v1 AS SELECT * FROM t1;
SELECT SQL_BIG_RESULT col1 AS field1, col1 AS field2
FROM v1
GROUP BY field1, field2;
field1 field2
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
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;
field1 field2
1 1
1 2
1 3
explain
select col1 f1, col1 f2 from t1 order by f2, f1;
id select_type table type possible_keys key key_len ref rows Extra
2014-01-02 14:51:02 +01:00
1 SIMPLE t1 index NULL idx 5 NULL 20 Using index
explain
select col1 f1, col1 f2 from t1 order by f2, f1+0;
id select_type table type possible_keys key key_len ref rows Extra
2013-01-31 23:09:36 +01:00
1 SIMPLE t1 index NULL idx 5 NULL 20 Using index; Using filesort
2014-01-02 14:51:02 +01:00
select col1 f1, col1 f2 from t1 order by f2, f1+0;
2013-01-31 23:09:36 +01:00
f1 f2
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
explain
select col1 f1, col1 f2 from t1 group by f2 order by f2, f1;
id select_type table type possible_keys key key_len ref rows Extra
2014-02-01 00:54:03 +01:00
1 SIMPLE t1 index NULL idx 5 NULL 20 Using index
2013-01-31 23:09:36 +01:00
select col1 f1, col1 f2 from t1 group by f2 order by f2, f1;
f1 f2
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
explain
select col1 f1, col1 f2 from t1 group by f1, f2 order by f2, f1;
id select_type table type possible_keys key key_len ref rows Extra
2014-01-02 14:51:02 +01:00
1 SIMPLE t1 index NULL idx 5 NULL 20 Using index
2013-01-31 23:09:36 +01:00
select col1 f1, col1 f2 from t1 group by f1, f2 order by f2, f1;
f1 f2
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
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;
2013-01-31 23:09:36 +01:00
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 index NULL idx 10 NULL 20 Using index; Using temporary; Using filesort
2014-01-02 14:51:02 +01:00
select col1 f1, col2 f2, col1 f3 from t2 group by f1, f2, f3+0;
2013-01-31 23:09:36 +01:00
f1 f2 f3
1 20 1
2 19 2
3 18 3
4 17 4
5 16 5
6 15 6
7 14 7
8 13 8
9 12 9
10 11 10
11 10 11
12 9 12
13 8 13
14 7 14
15 6 15
16 5 16
17 4 17
18 3 18
19 2 19
20 1 20
explain
2014-01-02 14:51:02 +01:00
select col1 f1, col2 f2, col1 f3 from t2 order by f1, f2, f3+0;
2013-01-31 23:09:36 +01:00
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 index NULL idx 10 NULL 20 Using index; Using filesort
2014-01-02 14:51:02 +01:00
select col1 f1, col2 f2, col1 f3 from t2 order by f1, f2, f3+0;
2013-01-31 23:09:36 +01:00
f1 f2 f3
1 20 1
2 19 2
3 18 3
4 17 4
5 16 5
6 15 6
7 14 7
8 13 8
9 12 9
10 11 10
11 10 11
12 9 12
13 8 13
14 7 14
15 6 15
16 5 16
17 4 17
18 3 18
19 2 19
20 1 20
DROP VIEW v1;
DROP TABLE t1, t2;
2010-02-06 20:54:30 +01:00
# End of 5.1 tests
2010-07-19 19:11:47 +02:00
#
2012-03-14 11:09:03 +01:00
# LP bug#694450 Wrong result with non-standard GROUP BY + ORDER BY
#
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');
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;
field1 field2
2004-10-11 18:13:00 1
2009-02-19 02:05:00 5
2012-03-17 09:26:58 +01:00
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'x'
Warning 1292 Truncated incorrect DOUBLE value: 'g'
Warning 1292 Truncated incorrect DOUBLE value: 'o'
Warning 1292 Truncated incorrect DOUBLE value: 'g'
Warning 1292 Truncated incorrect DOUBLE value: 'v'
2012-03-14 11:09:03 +01:00
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 ;
field1 field2
2004-10-11 18:13:00 1
2009-02-19 02:05:00 5
2012-03-17 09:26:58 +01:00
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'x'
Warning 1292 Truncated incorrect DOUBLE value: 'g'
Warning 1292 Truncated incorrect DOUBLE value: 'o'
Warning 1292 Truncated incorrect DOUBLE value: 'g'
Warning 1292 Truncated incorrect DOUBLE value: 'v'
2012-03-14 11:09:03 +01:00
SET SESSION SQL_MODE=default;
drop table t1;
2012-05-02 18:11:02 +02:00
#
# LP bug#967242 Wrong result (extra rows, not grouped) with JOIN, AND in ON condition, multi-part key, GROUP BY, OR in WHERE
#
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;
zzz
0
3
4
8
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;
zzz
0
3
4
8
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;
zzz
0
3
4
8
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;
b
0
3
4
8
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
#
# Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY
# ROWS WHEN GROUP IS OPTIMIZED AWAY
#
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);
EXPLAIN SELECT SQL_BUFFER_RESULT t2.col2 FROM t2 JOIN t1 ON t1.col1 GROUP BY t2.col2;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 system NULL NULL NULL NULL 1 Using temporary
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 Using where
SELECT SQL_BUFFER_RESULT t2.col2 FROM t2 JOIN t1 ON t1.col1 GROUP BY t2.col2;
col2
8
EXPLAIN SELECT t2.col2 FROM t2 JOIN t1 ON t1.col1 GROUP BY t2.col2;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 system NULL NULL NULL NULL 1
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 Using where
SELECT t2.col2 FROM t2 JOIN t1 ON t1.col1 GROUP BY t2.col2;
col2
8
DROP TABLE t1,t2;
#
# BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A
# DIFFERENT QUERY OUTPUT
#
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
EXPLAIN SELECT SQL_BUFFER_RESULT MIN(a), b FROM t1 WHERE t1.b = 'a' GROUP BY b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range b b 9 NULL 2 Using where; Using index for group-by; Using temporary
SELECT SQL_BUFFER_RESULT MIN(a), b FROM t1 WHERE t1.b = 'a' GROUP BY b;
MIN(a) b
0 a
EXPLAIN SELECT MIN(a), b FROM t1 WHERE t1.b = 'a' GROUP BY b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range b b 9 NULL 2 Using where; Using index for group-by
SELECT MIN(a), b FROM t1 WHERE t1.b = 'a' GROUP BY b;
MIN(a) b
0 a
DROP TABLE t1;
2012-05-07 12:26:34 +02:00
#
# LP bug#993726 Wrong result from a query with ALL subquery predicate in WHERE
#
CREATE TABLE t1(a INT);
INSERT INTO t1 VALUES (0);
SELECT 1 FROM t1 WHERE 1 > ALL(SELECT 1 FROM t1 WHERE a!=0);
1
1
SELECT max(1) FROM t1 WHERE a!=0;
max(1)
NULL
drop table t1;
2012-03-14 11:09:03 +01:00
# End of 5.2 tests
2012-03-14 12:58:18 +01:00
#
2012-03-17 09:26:58 +01:00
# lp:872702: Crash in add_ref_to_table_cond() when grouping by a PK
2011-10-12 19:40:56 +02:00
#
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;
a
DROP TABLE t1, t2;
2012-11-17 16:50:15 +01:00
FLUSH STATUS;
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;
f3 MIN(f2)
blob NULL
DROP TABLE t1;
the value below *must* be 1
show status like 'Created_tmp_disk_tables';
Variable_name Value
Created_tmp_disk_tables 1
2012-11-22 06:55:04 +01:00
#
# Bug #1002146: Unneeded filesort if usage of join buffer is not allowed
# (bug mdev-645)
#
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;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range idx idx 5 NULL 5 Using where; Using index
1 SIMPLE t1 index NULL PRIMARY 4 NULL 4 Using index
SELECT t2.a FROM t2 STRAIGHT_JOIN t1 ON t2.a <> 0 WHERE t2.a <> 6
GROUP BY t2.a;
a
3
4
100
200
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;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range idx idx 5 NULL 5 Using where; Using index
1 SIMPLE t1 index NULL PRIMARY 4 NULL 4 Using where; Using index
SELECT t2.a FROM t2 LEFT JOIN t1 ON t2.a <> 0 WHERE t2.a <> 6
GROUP BY t2.a;
a
0
3
4
100
200
set optimizer_switch=@save_optimizer_switch;
DROP TABLE t1,t2;
2013-10-29 11:39:03 +01:00
#
# MDEV-5104 crash in Item_field::used_tables with broken order by
#
(select 1 order by x(y)) order by 1;
ERROR 42S22: Unknown column 'y' in 'order clause'
2012-03-14 12:58:18 +01:00
# End of 5.3 tests
2012-03-17 09:26:58 +01:00
#
2010-07-19 19:11:47 +02:00
# Bug#49771: Incorrect MIN (date) when minimum value is 0000-00-00
#
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;
MIN(f2) MAX(f2)
0000-00-00 2004-05-19
SELECT f1,MIN(f2),MAX(f2) FROM t1 GROUP BY 1;
f1 MIN(f2) MAX(f2)
1 0000-00-00 2004-04-19
2 0001-01-01 2004-05-19
3 2004-04-10 2004-04-10
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;
MIN(f2) MAX(f2)
00:25:00 21:44:25
SELECT f1,MIN(f2),MAX(f2) FROM t1 GROUP BY 1;
f1 MIN(f2) MAX(f2)
1 01:27:35 06:11:01
2 19:53:05 21:44:25
3 05:45:11 10:55:12
4 00:25:00 00:25:00
DROP TABLE t1;
#End of test#49771
2012-09-01 23:21:59 +02:00
#
2013-01-11 00:31:50 +01:00
# Test of bug in GROUP_CONCAT with ROLLUP
#
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;
b GROUP_CONCAT( a, b ORDER BY a, b )
c 1c
v 2v,2v
SELECT b, GROUP_CONCAT( a, b ORDER BY a, b )
FROM t1 JOIN t2 ON c = b GROUP BY b WITH ROLLUP;
b GROUP_CONCAT( a, b ORDER BY a, b )
c 1c
v 2v,2v
NULL 1c,2v,2v
DROP TABLE t1,t2;
#
2014-04-24 17:20:57 +02:00
# MDEV-6129: Server crashes during UNION with ORDER BY field IS NULL
#
SET sql_mode='ONLY_FULL_GROUP_BY';
SELECT 1 AS test UNION SELECT 2 AS test ORDER BY test IS NULL ASC;
test
1
2
SET sql_mode='';
2014-05-09 12:35:11 +02:00
#
2014-10-14 13:11:06 +02:00
# MDEV-6484: Assertion `tab->ref.use_count' failed on query with joins, constant table, multi-part key
#
CREATE TABLE t1 (i1 INT, c1 VARCHAR(1)) ENGINE=MyISAM;
INSERT INTO t1 VALUES (6,'b');
CREATE TABLE t2 (pk2 INT, i2 INT, c2 VARCHAR(1), PRIMARY KEY(pk2), KEY(pk2,i2)) ENGINE=MyISAM;
INSERT INTO t2 VALUES (1,2,'s'),(2,4,'r'),(3,8,'m'),(4,4,'b'),(5,4,'x'),(6,7,'g'),(7,4,'p');
SELECT i2 FROM t1 AS t1a STRAIGHT_JOIN ( t2 INNER JOIN t1 AS t1b ON (t1b.c1 = c2) ) ON (t1b.i1 = pk2 )
WHERE t1a.c1 = c2 GROUP BY i2;
i2
DROP TABLE t1,t2;
2014-11-03 17:47:37 +01:00
#
2012-09-01 23:21:59 +02:00
# Bug #58782
# Missing rows with SELECT .. WHERE .. IN subquery
# with full GROUP BY and no aggr
#
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);
SELECT pk AS field1, col_int_nokey AS field2
FROM t1
WHERE col_int_nokey > 0
GROUP BY field1, field2;
field1 field2
10 7
11 1
12 5
13 3
CREATE TABLE where_subselect
SELECT pk AS field1, col_int_nokey AS field2
FROM t1
WHERE col_int_nokey > 0
GROUP BY field1, field2
;
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
);
field1 field2
10 7
11 1
12 5
13 3
DROP TABLE t1;
DROP TABLE where_subselect;
# End of Bug #58782
