You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

855 lines
24 KiB

Backport of: timestamp: Thu 2011-12-01 15:12:10 +0100 Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP When running sysbench on InnoDB there is a performance degradation due to index condition pushdown (ICP). Several of the queries in sysbench have a WHERE condition that the optimizer uses for executing these queries as range scans. The upper and lower limit of the range scan will ensure that the WHERE condition is fulfilled. Still, the WHERE condition is part of the queries' condition and if ICP is enabled the condition will be pushed down to InnoDB as an index condition. Due to the range scan's upper and lower limits ensure that the WHERE condition is fulfilled, the pushed index condition will not filter out any records. As a result the use of ICP for these queries results in a performance overhead for sysbench. This overhead comes from using resources for determining the part of the condition that can be pushed down to InnoDB and overhead in InnoDB for executing the pushed index condition. With the default configuration for sysbench the range scans will use the primary key. This is a clustered index in InnoDB. Using ICP on a clustered index provides the lowest performance benefit since the entire record is part of the clustered index and in InnoDB it has the highest relative overhead for executing the pushed index condition. The fix for removing the overhead ICP introduces when running sysbench is to disable use of ICP when the index used by the query is a clustered index. When WL#6061 is implemented this change should be re-evaluated.
14 years ago
Backport of: timestamp: Thu 2011-12-01 15:12:10 +0100 Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP When running sysbench on InnoDB there is a performance degradation due to index condition pushdown (ICP). Several of the queries in sysbench have a WHERE condition that the optimizer uses for executing these queries as range scans. The upper and lower limit of the range scan will ensure that the WHERE condition is fulfilled. Still, the WHERE condition is part of the queries' condition and if ICP is enabled the condition will be pushed down to InnoDB as an index condition. Due to the range scan's upper and lower limits ensure that the WHERE condition is fulfilled, the pushed index condition will not filter out any records. As a result the use of ICP for these queries results in a performance overhead for sysbench. This overhead comes from using resources for determining the part of the condition that can be pushed down to InnoDB and overhead in InnoDB for executing the pushed index condition. With the default configuration for sysbench the range scans will use the primary key. This is a clustered index in InnoDB. Using ICP on a clustered index provides the lowest performance benefit since the entire record is part of the clustered index and in InnoDB it has the highest relative overhead for executing the pushed index condition. The fix for removing the overhead ICP introduces when running sysbench is to disable use of ICP when the index used by the query is a clustered index. When WL#6061 is implemented this change should be re-evaluated.
14 years ago
Back-ported the patch of the mysql-5.6 code line that fixed several defects in the greedy optimization: 1) The greedy optimizer calculated the 'compare-cost' (CPU-cost) for iterating over the partial plan result at each level in the query plan as 'record_count / (double) TIME_FOR_COMPARE' This cost was only used locally for 'best' calculation at each level, and *not* accumulated into the total cost for the query plan. This fix added the 'CPU-cost' of processing 'current_record_count' records at each level to 'current_read_time' *before* it is used as 'accumulated cost' argument to recursive best_extension_by_limited_search() calls. This ensured that the cost of a huge join-fanout early in the QEP was correctly reflected in the cost of the final QEP. To get identical cost for a 'best' optimized query and a straight_join with the same join order, the same change was also applied to optimize_straight_join() and get_partial_join_cost() 2) Furthermore to get equal cost for 'best' optimized query and a straight_join the new code substrcated the same '0.001' in optimize_straight_join() as it had been already done in best_extension_by_limited_search() 3) When best_extension_by_limited_search() aggregated the 'best' plan a plan was 'best' by the check : 'if ((search_depth == 1) || (current_read_time < join->best_read))' The term '(search_depth == 1' incorrectly caused a new best plan to be collected whenever the specified 'search_depth' was reached - even if this partial query plan was more expensive than what we had already found.
14 years ago
14 years ago
Backport of: timestamp: Thu 2011-12-01 15:12:10 +0100 Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP When running sysbench on InnoDB there is a performance degradation due to index condition pushdown (ICP). Several of the queries in sysbench have a WHERE condition that the optimizer uses for executing these queries as range scans. The upper and lower limit of the range scan will ensure that the WHERE condition is fulfilled. Still, the WHERE condition is part of the queries' condition and if ICP is enabled the condition will be pushed down to InnoDB as an index condition. Due to the range scan's upper and lower limits ensure that the WHERE condition is fulfilled, the pushed index condition will not filter out any records. As a result the use of ICP for these queries results in a performance overhead for sysbench. This overhead comes from using resources for determining the part of the condition that can be pushed down to InnoDB and overhead in InnoDB for executing the pushed index condition. With the default configuration for sysbench the range scans will use the primary key. This is a clustered index in InnoDB. Using ICP on a clustered index provides the lowest performance benefit since the entire record is part of the clustered index and in InnoDB it has the highest relative overhead for executing the pushed index condition. The fix for removing the overhead ICP introduces when running sysbench is to disable use of ICP when the index used by the query is a clustered index. When WL#6061 is implemented this change should be re-evaluated.
14 years ago
Backport of: timestamp: Thu 2011-12-01 15:12:10 +0100 Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP When running sysbench on InnoDB there is a performance degradation due to index condition pushdown (ICP). Several of the queries in sysbench have a WHERE condition that the optimizer uses for executing these queries as range scans. The upper and lower limit of the range scan will ensure that the WHERE condition is fulfilled. Still, the WHERE condition is part of the queries' condition and if ICP is enabled the condition will be pushed down to InnoDB as an index condition. Due to the range scan's upper and lower limits ensure that the WHERE condition is fulfilled, the pushed index condition will not filter out any records. As a result the use of ICP for these queries results in a performance overhead for sysbench. This overhead comes from using resources for determining the part of the condition that can be pushed down to InnoDB and overhead in InnoDB for executing the pushed index condition. With the default configuration for sysbench the range scans will use the primary key. This is a clustered index in InnoDB. Using ICP on a clustered index provides the lowest performance benefit since the entire record is part of the clustered index and in InnoDB it has the highest relative overhead for executing the pushed index condition. The fix for removing the overhead ICP introduces when running sysbench is to disable use of ICP when the index used by the query is a clustered index. When WL#6061 is implemented this change should be re-evaluated.
14 years ago
Backport of: timestamp: Thu 2011-12-01 15:12:10 +0100 Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP When running sysbench on InnoDB there is a performance degradation due to index condition pushdown (ICP). Several of the queries in sysbench have a WHERE condition that the optimizer uses for executing these queries as range scans. The upper and lower limit of the range scan will ensure that the WHERE condition is fulfilled. Still, the WHERE condition is part of the queries' condition and if ICP is enabled the condition will be pushed down to InnoDB as an index condition. Due to the range scan's upper and lower limits ensure that the WHERE condition is fulfilled, the pushed index condition will not filter out any records. As a result the use of ICP for these queries results in a performance overhead for sysbench. This overhead comes from using resources for determining the part of the condition that can be pushed down to InnoDB and overhead in InnoDB for executing the pushed index condition. With the default configuration for sysbench the range scans will use the primary key. This is a clustered index in InnoDB. Using ICP on a clustered index provides the lowest performance benefit since the entire record is part of the clustered index and in InnoDB it has the highest relative overhead for executing the pushed index condition. The fix for removing the overhead ICP introduces when running sysbench is to disable use of ICP when the index used by the query is a clustered index. When WL#6061 is implemented this change should be re-evaluated.
14 years ago
Backport of: timestamp: Thu 2011-12-01 15:12:10 +0100 Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP When running sysbench on InnoDB there is a performance degradation due to index condition pushdown (ICP). Several of the queries in sysbench have a WHERE condition that the optimizer uses for executing these queries as range scans. The upper and lower limit of the range scan will ensure that the WHERE condition is fulfilled. Still, the WHERE condition is part of the queries' condition and if ICP is enabled the condition will be pushed down to InnoDB as an index condition. Due to the range scan's upper and lower limits ensure that the WHERE condition is fulfilled, the pushed index condition will not filter out any records. As a result the use of ICP for these queries results in a performance overhead for sysbench. This overhead comes from using resources for determining the part of the condition that can be pushed down to InnoDB and overhead in InnoDB for executing the pushed index condition. With the default configuration for sysbench the range scans will use the primary key. This is a clustered index in InnoDB. Using ICP on a clustered index provides the lowest performance benefit since the entire record is part of the clustered index and in InnoDB it has the highest relative overhead for executing the pushed index condition. The fix for removing the overhead ICP introduces when running sysbench is to disable use of ICP when the index used by the query is a clustered index. When WL#6061 is implemented this change should be re-evaluated.
14 years ago
  1. set @save_storage_engine= @@storage_engine;
  2. set storage_engine=InnoDB;
  3. set @innodb_icp_tmp=@@optimizer_switch;
  4. set optimizer_switch='mrr=on,mrr_sort_keys=on,index_condition_pushdown=on';
  5. #
  6. # Bug#36981 - "innodb crash when selecting for update"
  7. #
  8. CREATE TABLE t1 (
  9. c1 CHAR(1),
  10. c2 CHAR(10),
  11. KEY (c1)
  12. );
  13. INSERT INTO t1 VALUES ('3', null);
  14. SELECT * FROM t1 WHERE c1='3' FOR UPDATE;
  15. c1 c2
  16. 3 NULL
  17. DROP TABLE t1;
  18. CREATE TABLE t1 (a INT);
  19. INSERT INTO t1 VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
  20. CREATE TABLE t2 (a INT);
  21. INSERT INTO t2 SELECT A.a + 10*(B.a + 10*C.a) FROM t1 A, t1 B, t1 C;
  22. CREATE TABLE t3 (
  23. c1 CHAR(10) NOT NULL,
  24. c2 CHAR(10) NOT NULL,
  25. c3 CHAR(200) NOT NULL,
  26. KEY (c1)
  27. );
  28. INSERT INTO t3
  29. SELECT CONCAT('c-',1000+t2.a,'=w'), CONCAT('c-',1000+ t2.a,'=w'), 'filler'
  30. FROM t2;
  31. INSERT INTO t3
  32. SELECT CONCAT('c-',1000+t2.a,'=w'), CONCAT('c-',2000+t2.a,'=w'), 'filler-1'
  33. FROM t2;
  34. INSERT INTO t3
  35. SELECT CONCAT('c-',1000+t2.a,'=w'), CONCAT('c-',3000+t2.a,'=w'), 'filler-2'
  36. FROM t2;
  37. SELECT c1,c3 FROM t3 WHERE c1 >= 'c-1994=w' and c1 != 'c-1996=w' FOR UPDATE;
  38. c1 c3
  39. c-1994=w filler
  40. c-1994=w filler-1
  41. c-1994=w filler-2
  42. c-1995=w filler
  43. c-1995=w filler-1
  44. c-1995=w filler-2
  45. c-1997=w filler
  46. c-1997=w filler-1
  47. c-1997=w filler-2
  48. c-1998=w filler
  49. c-1998=w filler-1
  50. c-1998=w filler-2
  51. c-1999=w filler
  52. c-1999=w filler-1
  53. c-1999=w filler-2
  54. DROP TABLE t1,t2,t3;
  55. #
  56. # Bug#42580 - Innodb's ORDER BY ..LIMIT returns no rows for
  57. # null-safe operator <=> NULL
  58. #
  59. CREATE TABLE t1(
  60. c1 DATE NOT NULL,
  61. c2 DATE NULL,
  62. c3 DATETIME,
  63. c4 TIMESTAMP,
  64. PRIMARY KEY(c1),
  65. UNIQUE(c2)
  66. );
  67. INSERT INTO t1 VALUES('0000-00-00', '0000-00-00', '2008-01-04', '2008-01-05');
  68. INSERT INTO t1 VALUES('2007-05-25', '2007-05-25', '2007-05-26', '2007-05-26');
  69. INSERT INTO t1 VALUES('2008-01-01', NULL , '2008-01-02', '2008-01-03');
  70. INSERT INTO t1 VALUES('2008-01-17', NULL , NULL , '2009-01-29');
  71. INSERT INTO t1 VALUES('2009-01-29', '2009-01-29', '2009-01-29', '2009-01-29');
  72. SELECT * FROM t1 WHERE c2 <=> NULL ORDER BY c1,c2;
  73. c1 c2 c3 c4
  74. 2008-01-01 NULL 2008-01-02 00:00:00 2008-01-03 00:00:00
  75. 2008-01-17 NULL NULL 2009-01-29 00:00:00
  76. SELECT * FROM t1 WHERE c2 <=> NULL ORDER BY c1,c2 LIMIT 2;
  77. c1 c2 c3 c4
  78. 2008-01-01 NULL 2008-01-02 00:00:00 2008-01-03 00:00:00
  79. 2008-01-17 NULL NULL 2009-01-29 00:00:00
  80. DROP TABLE t1;
  81. #
  82. # Bug#43617 - Innodb returns wrong results with timestamp's range value
  83. # in IN clause
  84. # (Note: Fixed by patch for BUG#42580)
  85. #
  86. CREATE TABLE t1(
  87. c1 TIMESTAMP NOT NULL,
  88. c2 TIMESTAMP NULL,
  89. c3 DATE,
  90. c4 DATETIME,
  91. PRIMARY KEY(c1),
  92. UNIQUE INDEX(c2)
  93. );
  94. INSERT INTO t1 VALUES
  95. ('0000-00-00 00:00:00','0000-00-00 00:00:00','2008-01-04','2008-01-05 00:00:00'),
  96. ('1971-01-01 00:00:01','1980-01-01 00:00:01','2009-01-01','2009-01-02 00:00:00'),
  97. ('1999-01-01 00:00:00','1999-01-01 00:00:00', NULL, NULL),
  98. ('2007-05-23 09:15:28','2007-05-23 09:15:28','2007-05-24','2007-05-24 09:15:28'),
  99. ('2007-05-27 00:00:00','2007-05-25 00:00:00','2007-05-26','2007-05-26 00:00:00'),
  100. ('2008-01-01 00:00:00', NULL, '2008-01-02','2008-01-03 00:00:00'),
  101. ('2009-01-29 11:11:27','2009-01-29 11:11:27','2009-01-29','2009-01-29 11:11:27'),
  102. ('2038-01-09 03:14:07','2038-01-09 03:14:07','2009-01-05','2009-01-06 00:00:00');
  103. SELECT *
  104. FROM t1
  105. WHERE c2 IN ('1971-01-01 00:00:01','2038-01-09 03:14:07')
  106. ORDER BY c2;
  107. c1 c2 c3 c4
  108. 2038-01-09 03:14:07 2038-01-09 03:14:07 2009-01-05 2009-01-06 00:00:00
  109. SELECT *
  110. FROM t1
  111. WHERE c2 IN ('1971-01-01 00:00:01','2038-01-09 03:14:07')
  112. ORDER BY c2 LIMIT 2;
  113. c1 c2 c3 c4
  114. 2038-01-09 03:14:07 2038-01-09 03:14:07 2009-01-05 2009-01-06 00:00:00
  115. SELECT *
  116. FROM t1
  117. WHERE c2 IN ('1971-01-01 00:00:01','2038-01-09 03:14:07')
  118. ORDER BY c2 DESC;
  119. c1 c2 c3 c4
  120. 2038-01-09 03:14:07 2038-01-09 03:14:07 2009-01-05 2009-01-06 00:00:00
  121. SELECT *
  122. FROM t1
  123. WHERE c2 IN ('1971-01-01 00:00:01','2038-01-09 03:14:07')
  124. ORDER BY c2 DESC LIMIT 2;
  125. c1 c2 c3 c4
  126. 2038-01-09 03:14:07 2038-01-09 03:14:07 2009-01-05 2009-01-06 00:00:00
  127. DROP TABLE t1;
  128. #
  129. # BUG#43618: MyISAM&Maria returns wrong results with 'between'
  130. # on timestamp
  131. #
  132. CREATE TABLE t1(
  133. ts TIMESTAMP NOT NULL,
  134. c char NULL,
  135. PRIMARY KEY(ts)
  136. );
  137. INSERT INTO t1 VALUES
  138. ('1971-01-01','a'),
  139. ('2007-05-25','b'),
  140. ('2008-01-01','c'),
  141. ('2038-01-09','d');
  142. # Execute select with invalid timestamp, desc ordering
  143. SELECT *
  144. FROM t1
  145. WHERE ts BETWEEN '0000-00-00' AND '2010-00-01 00:00:00'
  146. ORDER BY ts DESC
  147. LIMIT 2;
  148. ts c
  149. 2008-01-01 00:00:00 c
  150. 2007-05-25 00:00:00 b
  151. # Should use index condition
  152. EXPLAIN
  153. SELECT *
  154. FROM t1
  155. WHERE ts BETWEEN '0000-00-00' AND '2010-00-01 00:00:00'
  156. ORDER BY ts DESC
  157. LIMIT 2;
  158. id select_type table type possible_keys key key_len ref rows Extra
  159. 1 SIMPLE t1 range PRIMARY PRIMARY 4 NULL 4 Using where
  160. DROP TABLE t1;
  161. #
  162. # BUG#49906: Assertion failed - Field_varstring::val_str in field.cc
  163. # (Note: Fixed by patch for LP BUG#625841)
  164. #
  165. CREATE TABLE t1 (
  166. f1 VARCHAR(1024),
  167. f2 VARCHAR(10),
  168. INDEX test_idx USING BTREE (f2,f1(5))
  169. );
  170. INSERT INTO t1 VALUES ('a','c'), ('b','d');
  171. SELECT f1
  172. FROM t1
  173. WHERE f2 LIKE 'd'
  174. ORDER BY f1;
  175. f1
  176. b
  177. DROP TABLE t1;
  178. #
  179. # Bug#52660 - "Perf. regr. using ICP for MyISAM on range queries on
  180. # an index containing TEXT"
  181. #
  182. CREATE TABLE t1 (a INT);
  183. INSERT INTO t1 VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
  184. CREATE TABLE t2 (a INT);
  185. INSERT INTO t2 SELECT A.a + 10*(B.a) FROM t1 A, t1 B;
  186. CREATE TABLE t3 (
  187. c1 TINYTEXT NOT NULL,
  188. i1 INT NOT NULL,
  189. KEY (c1(6),i1)
  190. );
  191. INSERT INTO t3 SELECT CONCAT('c-',1000+t2.a,'=w'), 1 FROM t2;
  192. EXPLAIN
  193. SELECT c1 FROM t3 WHERE c1 >= 'c-1004=w' and c1 <= 'c-1006=w';
  194. id select_type table type possible_keys key key_len ref rows Extra
  195. 1 SIMPLE t3 range c1 c1 8 NULL 3 Using where
  196. SELECT c1 FROM t3 WHERE c1 >= 'c-1004=w' and c1 <= 'c-1006=w';
  197. c1
  198. c-1004=w
  199. c-1005=w
  200. c-1006=w
  201. EXPLAIN
  202. SELECT c1 FROM t3 WHERE c1 >= 'c-1004=w' and c1 <= 'c-1006=w' and i1 > 2;
  203. id select_type table type possible_keys key key_len ref rows Extra
  204. 1 SIMPLE t3 range c1 c1 12 NULL 2 Using index condition; Using where
  205. SELECT c1 FROM t3 WHERE c1 >= 'c-1004=w' and c1 <= 'c-1006=w' and i1 > 2;
  206. c1
  207. EXPLAIN
  208. SELECT c1 FROM t3 WHERE c1 >= 'c-1004=w' and c1 <= 'c-1006=w' or i1 > 2;
  209. id select_type table type possible_keys key key_len ref rows Extra
  210. 1 SIMPLE t3 ALL c1 NULL NULL NULL 100 Using where
  211. SELECT c1 FROM t3 WHERE c1 >= 'c-1004=w' and c1 <= 'c-1006=w' or i1 > 2;
  212. c1
  213. c-1004=w
  214. c-1005=w
  215. c-1006=w
  216. DROP TABLE t1, t2, t3;
  217. #
  218. # Bug#40992 - InnoDB: Crash when engine_condition_pushdown is on
  219. #
  220. CREATE TABLE t (
  221. dummy INT PRIMARY KEY,
  222. a INT UNIQUE,
  223. b INT
  224. );
  225. INSERT INTO t VALUES (1,1,1),(3,3,3),(5,5,5);
  226. SELECT * FROM t WHERE a > 2 FOR UPDATE;
  227. dummy a b
  228. 3 3 3
  229. 5 5 5
  230. DROP TABLE t;
  231. #
  232. # Bug#35080 - Innodb crash at mem_block_get_len line 72
  233. #
  234. CREATE TABLE t1 (
  235. t1_autoinc INT(11) NOT NULL AUTO_INCREMENT,
  236. uuid VARCHAR(36) DEFAULT NULL,
  237. PRIMARY KEY (t1_autoinc),
  238. KEY k (uuid)
  239. );
  240. CREATE TABLE t2 (
  241. t2_autoinc INT(11) NOT NULL AUTO_INCREMENT,
  242. uuid VARCHAR(36) DEFAULT NULL,
  243. date DATETIME DEFAULT NULL,
  244. PRIMARY KEY (t2_autoinc),
  245. KEY k (uuid)
  246. );
  247. CREATE VIEW v1 AS
  248. SELECT t1_autoinc, uuid
  249. FROM t1
  250. WHERE (ISNULL(uuid) OR (uuid like '%-%'));
  251. CREATE VIEW v2 AS
  252. SELECT t2_autoinc, uuid, date
  253. FROM t2
  254. WHERE (ISNULL(uuid) OR (LENGTH(uuid) = 36));
  255. CREATE PROCEDURE delete_multi (IN uuid CHAR(36))
  256. DELETE v1, v2 FROM v1 INNER JOIN v2
  257. ON v1.uuid = v2.uuid
  258. WHERE v1.uuid = @uuid;
  259. SET @uuid = UUID();
  260. INSERT INTO v1 (uuid) VALUES (@uuid);
  261. INSERT INTO v2 (uuid, date) VALUES (@uuid, '2009-09-09');
  262. CALL delete_multi(@uuid);
  263. DROP procedure delete_multi;
  264. DROP table t1,t2;
  265. DROP view v1,v2;
  266. #
  267. # Bug#41996 - multi-table delete crashes server (InnoDB table)
  268. #
  269. CREATE TABLE t1 (
  270. b BIGINT,
  271. i INT,
  272. KEY (b)
  273. );
  274. INSERT INTO t1 VALUES (2, 2);
  275. DELETE t1 FROM t1 a, t1 WHERE a.i=t1.b;
  276. DROP TABLE t1;
  277. #
  278. # Bug#43448 - Server crashes on multi table delete with Innodb
  279. #
  280. CREATE TABLE t1 (
  281. id1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  282. t CHAR(12)
  283. );
  284. CREATE TABLE t2 (
  285. id2 INT NOT NULL,
  286. t CHAR(12)
  287. );
  288. CREATE TABLE t3(
  289. id3 INT NOT NULL,
  290. t CHAR(12),
  291. INDEX(id3)
  292. );
  293. CREATE PROCEDURE insert_data ()
  294. BEGIN
  295. DECLARE i1 INT DEFAULT 20;
  296. DECLARE i2 INT;
  297. DECLARE i3 INT;
  298. WHILE (i1 > 0) DO
  299. INSERT INTO t1(t) VALUES (i1);
  300. SET i2 = 2;
  301. WHILE (i2 > 0) DO
  302. INSERT INTO t2(id2, t) VALUES (i1, i2);
  303. SET i3 = 2;
  304. WHILE (i3 > 0) DO
  305. INSERT INTO t3(id3, t) VALUES (i1, i2);
  306. SET i3 = i3 -1;
  307. END WHILE;
  308. SET i2 = i2 -1;
  309. END WHILE;
  310. SET i1 = i1 - 1;
  311. END WHILE;
  312. END |
  313. CALL insert_data();
  314. SELECT COUNT(*) FROM t1 WHERE id1 > 10;
  315. COUNT(*)
  316. 10
  317. SELECT COUNT(*) FROM t2 WHERE id2 > 10;
  318. COUNT(*)
  319. 20
  320. SELECT COUNT(*) FROM t3 WHERE id3 > 10;
  321. COUNT(*)
  322. 40
  323. DELETE t1, t2, t3
  324. FROM t1, t2, t3
  325. WHERE t1.id1 = t2.id2 AND t2.id2 = t3.id3 AND t1.id1 > 3;
  326. SELECT COUNT(*) FROM t1;
  327. COUNT(*)
  328. 3
  329. SELECT COUNT(*) FROM t2;
  330. COUNT(*)
  331. 6
  332. SELECT COUNT(*) FROM t3;
  333. COUNT(*)
  334. 12
  335. DROP PROCEDURE insert_data;
  336. DROP TABLE t1, t2, t3;
  337. #
  338. # Bug#57372 "Multi-table updates and deletes fail when running with ICP
  339. # against InnoDB"
  340. #
  341. CREATE TABLE t1 (
  342. a INT KEY,
  343. b INT
  344. );
  345. CREATE TABLE t2 (
  346. a INT KEY,
  347. b INT
  348. );
  349. INSERT INTO t1 VALUES (1, 101), (2, 102), (3, 103), (4, 104), (5, 105);
  350. INSERT INTO t2 VALUES (1, 1), (2, 2), (3, 3), (4, 4), (5, 5);
  351. UPDATE t1, t2
  352. SET t1.a = t1.a + 100, t2.b = t1.a + 10
  353. WHERE t1.a BETWEEN 2 AND 4 AND t2.a = t1.b - 100;
  354. SELECT * FROM t1;
  355. a b
  356. 1 101
  357. 102 102
  358. 103 103
  359. 104 104
  360. 5 105
  361. SELECT * FROM t2;
  362. a b
  363. 1 1
  364. 2 12
  365. 3 13
  366. 4 14
  367. 5 5
  368. DROP TABLE t1, t2;
  369. #
  370. # Bug#52605 - "Adding LIMIT 1 clause to query with complex range
  371. # predicate causes wrong results"
  372. #
  373. CREATE TABLE t1 (
  374. pk INT NOT NULL,
  375. c1 INT,
  376. PRIMARY KEY (pk),
  377. KEY k1 (c1)
  378. );
  379. INSERT INTO t1 VALUES (1,NULL);
  380. INSERT INTO t1 VALUES (2,6);
  381. INSERT INTO t1 VALUES (3,NULL);
  382. INSERT INTO t1 VALUES (4,6);
  383. INSERT INTO t1 VALUES (5,NULL);
  384. INSERT INTO t1 VALUES (6,NULL);
  385. INSERT INTO t1 VALUES (7,9);
  386. INSERT INTO t1 VALUES (8,0);
  387. SELECT pk, c1
  388. FROM t1
  389. WHERE (pk BETWEEN 4 AND 5 OR pk < 2) AND c1 < 240
  390. ORDER BY c1
  391. LIMIT 1;
  392. pk c1
  393. 4 6
  394. EXPLAIN SELECT pk, c1
  395. FROM t1
  396. WHERE (pk BETWEEN 4 AND 5 OR pk < 2) AND c1 < 240
  397. ORDER BY c1
  398. LIMIT 1;
  399. id select_type table type possible_keys key key_len ref rows Extra
  400. 1 SIMPLE t1 range PRIMARY,k1 k1 5 NULL 3 Using where; Using index
  401. DROP TABLE t1;
  402. #
  403. #
  404. # Bug#59259 "Incorrect rows returned for a correlated subquery
  405. # when ICP is on"
  406. #
  407. CREATE TABLE t1 (pk INTEGER PRIMARY KEY, i INTEGER NOT NULL) ENGINE=InnoDB;
  408. INSERT INTO t1 VALUES (11,0);
  409. INSERT INTO t1 VALUES (12,5);
  410. INSERT INTO t1 VALUES (15,0);
  411. CREATE TABLE t2 (pk INTEGER PRIMARY KEY, i INTEGER NOT NULL) ENGINE=InnoDB;
  412. INSERT INTO t2 VALUES (11,1);
  413. INSERT INTO t2 VALUES (12,2);
  414. INSERT INTO t2 VALUES (15,4);
  415. set @save_optimizer_switch= @@optimizer_switch;
  416. set optimizer_switch='semijoin=off';
  417. EXPLAIN
  418. SELECT * FROM t1
  419. WHERE pk IN (SELECT it.pk FROM t2 JOIN t2 AS it ON it.i=it.i WHERE it.pk-t1.i<10);
  420. id select_type table type possible_keys key key_len ref rows Extra
  421. 1 PRIMARY t1 ALL NULL NULL NULL NULL 3 Using where
  422. 2 DEPENDENT SUBQUERY it eq_ref PRIMARY PRIMARY 4 func 1 Using where
  423. 2 DEPENDENT SUBQUERY t2 index NULL PRIMARY 4 NULL 3 Using where; Using index; Using join buffer (flat, BNL join)
  424. SELECT * FROM t1
  425. WHERE pk IN (SELECT it.pk FROM t2 JOIN t2 AS it ON it.i=it.i WHERE it.pk-t1.i<10);
  426. pk i
  427. 12 5
  428. set optimizer_switch=@save_optimizer_switch;
  429. DROP TABLE t1, t2;
  430. #
  431. # Bug #58816 "Extra temporary duplicate rows in result set when
  432. # switching ICP off"
  433. #
  434. set @save_optimizer_switch= @@optimizer_switch;
  435. CREATE TABLE t1 (
  436. pk INT NOT NULL,
  437. c1 INT NOT NULL,
  438. PRIMARY KEY (pk)
  439. );
  440. INSERT INTO t1 VALUES (1,9),(2,7),(3,6),(4,3),(5,1);
  441. EXPLAIN SELECT pk, c1 FROM t1 WHERE pk <> 3;
  442. id select_type table type possible_keys key key_len ref rows Extra
  443. 1 SIMPLE t1 range PRIMARY PRIMARY 4 NULL 4 Using where
  444. SET SESSION optimizer_switch='index_condition_pushdown=off';
  445. SELECT pk, c1 FROM t1 WHERE pk <> 3;
  446. pk c1
  447. 1 9
  448. 2 7
  449. 4 3
  450. 5 1
  451. DROP TABLE t1;
  452. set optimizer_switch= @save_optimizer_switch;
  453. #
  454. # Bug#58837: ICP crash or valgrind error due to uninitialized
  455. # value in innobase_index_cond
  456. #
  457. CREATE TABLE t1 (
  458. t1_int INT,
  459. t1_time TIME
  460. );
  461. CREATE TABLE t2 (
  462. t2_int int PRIMARY KEY,
  463. t2_int2 INT
  464. );
  465. INSERT INTO t2 VALUES ();
  466. INSERT INTO t1 VALUES ();
  467. SELECT * FROM t1 AS t1a
  468. WHERE NOT EXISTS (SELECT * FROM t1 AS t1b
  469. WHERE t1b.t1_int NOT IN
  470. (SELECT t2.t2_int FROM t2
  471. WHERE t1b.t1_time LIKE t1b.t1_int
  472. OR t1b.t1_time <> t2.t2_int2
  473. AND 6=7));
  474. t1_int t1_time
  475. DROP TABLE t1,t2;
  476. #
  477. # Bug#59186: Wrong results of join when ICP is enabled
  478. # (fixed by the patch for LP bug #694092)
  479. #
  480. CREATE TABLE t1 (
  481. pk INTEGER NOT NULL,
  482. c1 VARCHAR(3) NOT NULL,
  483. PRIMARY KEY (pk)
  484. );
  485. INSERT INTO t1 VALUES (1,'y'),(0,'or');
  486. CREATE TABLE t2 (
  487. pk INTEGER NOT NULL,
  488. c1 VARCHAR(3) NOT NULL,
  489. c2 VARCHAR(6) NOT NULL,
  490. PRIMARY KEY (pk)
  491. );
  492. INSERT INTO t2 VALUES (6,'y','RPOYT'),(10,'m','JINQE');
  493. EXPLAIN
  494. SELECT c2 FROM t1 JOIN t2 ON t1.c1 = t2.c1
  495. WHERE (t2.pk <= 4 AND t1.pk IN (2,1)) OR
  496. (t1.pk > 1 AND t2.pk BETWEEN 6 AND 6);
  497. id select_type table type possible_keys key key_len ref rows Extra
  498. 1 SIMPLE t1 range PRIMARY PRIMARY 4 NULL 1 Using where
  499. 1 SIMPLE t2 range PRIMARY PRIMARY 4 NULL 2 Using where; Using join buffer (flat, BNL join)
  500. SELECT c2 FROM t1 JOIN t2 ON t1.c1 = t2.c1
  501. WHERE (t2.pk <= 4 AND t1.pk IN (2,1)) OR
  502. (t1.pk > 1 AND t2.pk BETWEEN 6 AND 6);
  503. c2
  504. DROP TABLE t1, t2;
  505. #
  506. # Bug#58838: "Wrong results with HAVING + LIMIT without GROUP BY when
  507. # ICP is enabled".
  508. # (Fixed by the patches for LP bugs #668644, #702322)
  509. #
  510. CREATE TABLE t1 (
  511. pk INT NOT NULL,
  512. c1 INT,
  513. PRIMARY KEY (pk),
  514. KEY col_int_key (c1)
  515. );
  516. INSERT INTO t1 VALUES (1,37),(2,8),(3,-25),(4,NULL),(5,55);
  517. SELECT pk FROM t1 WHERE c1 <> 1 HAVING pk = 3 ORDER BY pk LIMIT 0;
  518. pk
  519. SELECT pk FROM t1 WHERE c1 <> 1 HAVING pk = 3 ORDER BY pk LIMIT 1;
  520. pk
  521. 3
  522. SELECT pk FROM t1 WHERE c1 <> 1 HAVING pk = 3 ORDER BY pk LIMIT 2;
  523. pk
  524. 3
  525. SELECT pk FROM t1 WHERE c1 <> 1 HAVING pk = 3 ORDER BY pk LIMIT 5;
  526. pk
  527. 3
  528. DROP TABLE t1;
  529. #
  530. # Bug#59483 "Crash on INSERT/REPLACE in
  531. # rec_convert_dtuple_to_rec_comp with ICP on"
  532. #
  533. CREATE TABLE t1 (
  534. pk INTEGER AUTO_INCREMENT PRIMARY KEY,
  535. i1 INTEGER,
  536. c1 CHAR(6),
  537. i2 INTEGER NOT NULL,
  538. KEY (i2)
  539. );
  540. INSERT INTO t1 VALUES
  541. (NULL, 4, 'that', 8),
  542. (NULL, 1, 'she', 6),
  543. (NULL, 6, 'tell', 2);
  544. SELECT * FROM t1 WHERE i2 IN (3, 6) LIMIT 2 FOR UPDATE;
  545. pk i1 c1 i2
  546. 2 1 she 6
  547. INSERT INTO t1 (i2) VALUES (1);
  548. DROP TABLE t1;
  549. #
  550. # Bug #11766678 - 59843:
  551. # USING UNINITIALISED VALUE IN USES_INDEX_FIELDS_ONLY
  552. #
  553. CREATE TABLE t1 (
  554. col999 FLOAT NOT NULL,
  555. COL1000 VARBINARY(179) NOT NULL,
  556. col1003 DATE DEFAULT NULL,
  557. KEY idx4267 (col1000, col1003)
  558. );
  559. INSERT INTO t1 VALUES (),();
  560. Warnings:
  561. Warning 1364 Field 'col999' doesn't have a default value
  562. Warning 1364 Field 'COL1000' doesn't have a default value
  563. SELECT col999 FROM t1 WHERE col1000 = "3" AND col1003 <=> sysdate();
  564. col999
  565. DROP TABLE t1;
  566. #
  567. # BUG#12822678 - ICP WITH STRAIGHT_JOIN
  568. #
  569. CREATE TABLE t1 (
  570. i1 INTEGER NOT NULL,
  571. d1 DOUBLE,
  572. KEY k1 (d1)
  573. );
  574. INSERT INTO t1 VALUES (10,1), (17,NULL), (22,NULL);
  575. CREATE TABLE t2 (
  576. pk INTEGER NOT NULL,
  577. i1 INTEGER NOT NULL,
  578. PRIMARY KEY (pk)
  579. );
  580. INSERT INTO t2 VALUES (4,1);
  581. EXPLAIN
  582. SELECT t1.d1, t2.pk, t2.i1 FROM t1 STRAIGHT_JOIN t2 ON t2.i1
  583. WHERE t2.pk <> t1.d1 AND t2.pk = 4;
  584. id select_type table type possible_keys key key_len ref rows Extra
  585. 1 SIMPLE t1 index NULL k1 9 NULL 3 Using index
  586. 1 SIMPLE t2 const PRIMARY PRIMARY 4 const 1 Using where
  587. SELECT t1.d1, t2.pk, t2.i1 FROM t1 STRAIGHT_JOIN t2 ON t2.i1
  588. WHERE t2.pk <> t1.d1 AND t2.pk = 4;
  589. d1 pk i1
  590. 1 4 1
  591. DROP TABLE t1, t2;
  592. #
  593. # BUG#778434 Wrong result with in_to_exists=on in maria-5.3-mwl89
  594. #
  595. CREATE TABLE t1 ( f11 int) ;
  596. INSERT IGNORE INTO t1 VALUES (0);
  597. CREATE TABLE t2 ( f10 int) ;
  598. INSERT IGNORE INTO t2 VALUES (0);
  599. CREATE TABLE t3 ( f1 int NOT NULL , f10 int, PRIMARY KEY (f1)) ;
  600. INSERT IGNORE INTO t3 VALUES (6,0),(10,0);
  601. CREATE TABLE t4 ( f11 int) ;
  602. INSERT IGNORE INTO t4 VALUES
  603. (0),(0),(0),(0),(0),(0),(0),(0),(0),(0),(NULL),
  604. (0),(0),(0),(0),(0),(0),(0),(0),(0),(0);
  605. set @tmp_778434=@@optimizer_switch;
  606. SET optimizer_switch='materialization=off,in_to_exists=on,subquery_cache=off,semijoin=off';
  607. SELECT * FROM t1 INNER JOIN t2 ON t2.f10 = t1.f11
  608. WHERE (6, 234) IN (
  609. SELECT t3.f1, t3.f1
  610. FROM t3 JOIN t4 ON t4.f11 = t3.f10
  611. );
  612. f11 f10
  613. DROP TABLE t1,t2,t3,t4;
  614. set optimizer_switch= @tmp_778434;
  615. #
  616. # Bug#885168: ICP for one index + potential ORDER BY for another
  617. #
  618. CREATE TABLE t1 (a varchar(64), b varchar(10), INDEX(a), INDEX(b)) ;
  619. INSERT INTO t1 VALUES
  620. ('Ohio','Iowa'), ('k','d'), ('bdkpj','mbdkpjdanp'), ('d','xdmbdkpjda'),
  621. ('fkxdmbdkpjdanpje','o'), ('f','Pennsylvan'), ('Virginia','ei');
  622. SET SESSION optimizer_switch='index_condition_pushdown=off';
  623. EXPLAIN
  624. SELECT * FROM t1
  625. WHERE NOT(b = 'Texas') AND b BETWEEN 'wy' AND 'y' OR b = 'Pennsylvania'
  626. ORDER BY a;
  627. id select_type table type possible_keys key key_len ref rows Extra
  628. 1 SIMPLE t1 range b b 13 NULL 2 Using where; Rowid-ordered scan; Using filesort
  629. SELECT * FROM t1
  630. WHERE NOT(b = 'Texas') AND b BETWEEN 'wy' AND 'y' OR b = 'Pennsylvania'
  631. ORDER BY a;
  632. a b
  633. d xdmbdkpjda
  634. SET SESSION optimizer_switch='index_condition_pushdown=on';
  635. EXPLAIN
  636. SELECT * FROM t1
  637. WHERE NOT(b = 'Texas') AND b BETWEEN 'wy' AND 'y' OR b = 'Pennsylvania'
  638. ORDER BY a;
  639. id select_type table type possible_keys key key_len ref rows Extra
  640. 1 SIMPLE t1 range b b 13 NULL 2 Using index condition; Using where; Rowid-ordered scan; Using filesort
  641. SELECT * FROM t1
  642. WHERE NOT(b = 'Texas') AND b BETWEEN 'wy' AND 'y' OR b = 'Pennsylvania'
  643. ORDER BY a;
  644. a b
  645. d xdmbdkpjda
  646. DROP TABLE t1;
  647. #
  648. # Bug#886145: join with ICP + ORDER BY
  649. #
  650. CREATE TABLE t1 (b int NOT NULL, c int, a varchar(1024), PRIMARY KEY (b));
  651. INSERT INTO t1 VALUES (1,4,'Ill');
  652. CREATE TABLE t2 (a varchar(1024), KEY (a(512)));
  653. INSERT INTO t2 VALUES
  654. ('Ill'), ('eckqzsflbzaffti'), ('w'), ('she'), ('gxbwypqtjzwywwer'), ('w');
  655. SET SESSION optimizer_switch='index_condition_pushdown=off';
  656. EXPLAIN
  657. SELECT t1.b, t1.c FROM t1, t2 WHERE t1.a = t2.a AND t1.b != 0
  658. HAVING t1.c != 5 ORDER BY t1.c;
  659. id select_type table type possible_keys key key_len ref rows Extra
  660. 1 SIMPLE t1 range PRIMARY PRIMARY 4 NULL 2 Using where; Using filesort
  661. 1 SIMPLE t2 ref a a 515 test.t1.a 1 Using where
  662. SELECT t1.b, t1.c FROM t1, t2 WHERE t1.a = t2.a AND t1.b != 0
  663. HAVING t1.c != 5 ORDER BY t1.c;
  664. b c
  665. 1 4
  666. SET SESSION optimizer_switch='index_condition_pushdown=on';
  667. EXPLAIN
  668. SELECT t1.b, t1.c FROM t1, t2 WHERE t1.a = t2.a AND t1.b != 0
  669. HAVING t1.c != 5 ORDER BY t1.c;
  670. id select_type table type possible_keys key key_len ref rows Extra
  671. 1 SIMPLE t1 range PRIMARY PRIMARY 4 NULL 2 Using where; Using filesort
  672. 1 SIMPLE t2 ref a a 515 test.t1.a 1 Using where
  673. SELECT t1.b, t1.c FROM t1, t2 WHERE t1.a = t2.a AND t1.b != 0
  674. HAVING t1.c != 5 ORDER BY t1.c;
  675. b c
  676. 1 4
  677. DROP TABLE t1,t2;
  678. #
  679. # Bug#879871: InnoDB: possible ICP + GROUP BY primary index
  680. #
  681. CREATE TABLE t1 (
  682. a int NOT NULL, b int, c varchar(1), d varchar(1),
  683. PRIMARY KEY (a), KEY c (c,b)
  684. );
  685. INSERT INTO t1 VALUES (10,8,'g','g');
  686. SET SESSION optimizer_switch='index_condition_pushdown=off';
  687. SELECT a FROM t1 WHERE c IS NULL AND d IS NOT NULL GROUP BY 1;
  688. a
  689. SET SESSION optimizer_switch='index_condition_pushdown=on';
  690. SELECT a FROM t1 WHERE c IS NULL AND d IS NOT NULL GROUP BY 1;
  691. a
  692. DROP TABLE t1;
  693. #
  694. # Bug#904832: an attempt to perform an index condition pushdown
  695. # of a condition containing a subquery
  696. #
  697. CREATE TABLE t1 (
  698. a INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
  699. b INT, c INT, d DATE NOT NULL, e VARCHAR(1),
  700. KEY (c), KEY (d), KEY k2(b), KEY k3(b), KEY k4(b)
  701. );
  702. INSERT INTO t1 (b,c,d,e) VALUES
  703. (6,5,'2006-05-25','y'),(1,5,'2008-01-23','t'),
  704. (6,5,'2007-06-18','d'),(4,5,'1900-01-01','r'),
  705. (8,5,'1900-01-01','m'),(4,5,'2006-03-09','b'),
  706. (4,5,'2001-06-05','x'),(1,5,'2008-01-23','t'),
  707. (6,5,'2007-06-18','d'),(4,5,'1900-01-01','r'),
  708. (8,5,'1900-01-01','m'),(4,5,'2006-03-09','b'),
  709. (4,5,'2001-06-05','x'),(1,5,'2008-01-23','t'),
  710. (4,5,'1900-01-01','r'),(8,5,'1900-01-01','m'),
  711. (4,5,'2006-03-09','b'),(4,5,'2001-06-05','x'),
  712. (1,5,'2008-01-23','t'),(6,5,'2007-06-18','d'),
  713. (4,5,'1900-01-01','r'),(8,5,'1900-01-01','m'),
  714. (4,5,'2006-03-09','b'),(4,5,'2001-06-05','f'),
  715. (4,5,'2001-06-05','x'),(8,5,'1900-01-01','m'),
  716. (4,5,'2006-03-09','b'),(4,5,'2001-06-05','x'),
  717. (1,5,'2008-01-23','t'),(6,5,'2007-06-18','d'),
  718. (4,5,'1900-01-01','r'),(8,5,'1900-01-01','m'),
  719. (4,5,'2006-03-09','b'),(6,5,'2007-06-18','d'),
  720. (6,5,'2007-06-18','d'),(4,5,'1900-01-01','r'),
  721. (8,5,'1900-01-01','m'),(4,5,'2006-03-09','b'),
  722. (6,5,'2007-06-18','d'),(4,5,'1900-01-01','r'),
  723. (8,5,'1900-01-01','m'),(4,5,'2006-03-09','b'),
  724. (4,5,'2006-03-09','b'),(4,5,'2001-06-05','x'),
  725. (1,5,'2008-01-23','t'),(6,5,'2007-06-18','d'),
  726. (4,5,'1900-01-01','r'),(8,5,'1900-01-01','m'),
  727. (4,5,'2006-03-09','b'),(4,5,'2001-06-05','x'),
  728. (4,5,'2001-06-05','x'),(1,5,'2008-01-23','t'),
  729. (6,5,'2007-06-18','d'),(4,5,'1900-01-01','r'),
  730. (8,5,'1900-01-01','m'),(4,5,'2006-03-09','b'),
  731. (4,5,'2001-06-05','x'),(1,5,'2008-01-23','t'),
  732. (6,5,'2007-06-18','d'),(4,1,'1900-01-01','r'),
  733. (8,8,'1900-01-01','m'),(4,1,'2006-03-09','b'),
  734. (4,1,'2001-06-05','x'),(7,1,'2006-05-28','g');
  735. CREATE TABLE t2 (
  736. f INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
  737. g INT,
  738. h VARCHAR(1),
  739. KEY (g)
  740. );
  741. INSERT INTO t2 (g,h) VALUES
  742. (3,'e'),(1,'u'),(4,'v'),(9,'u'),(6,'i'),(1,'x'),
  743. (5,'l'),(8,'y'),(0,'p'),(0,'f'),(0,'p'),(7,'d'),
  744. (7,'f'),(5,'j'),(3,'e'),(1,'u'),(4,'v'),(9,'u'),
  745. (6,'i'),(1,'x'),(5,'l'),(8,'y'),(0,'p'),(0,'f'),
  746. (0,'p'),(0,'f'),(0,'p'),(7,'d'),(7,'f'),(5,'j'),
  747. (3,'e'),(1,'u'),(4,'v'),(9,'u'),(6,'i'),(1,'x'),
  748. (7,'d'),(7,'f'),(5,'j'),(3,'e'),(1,'u'),(4,'v'),
  749. (9,'u'),(6,'i'),(1,'x'),(5,'l'),(8,'y'),(0,'p'),
  750. (0,'f'),(0,'p'),(7,'d'),(7,'f'),(5,'j'),(3,'e'),
  751. (1,'u'),(4,'v'),(9,'u'),(6,'i'),(1,'x'),(5,'l'),
  752. (6,'q'),(2,'n'),(4,'r'),(4,'b'),(8,'y'),(0,'p'),
  753. (0,'f'),(0,'p'),(7,'d'),(7,'f'),(5,'j'),(3,'e'),
  754. (1,'u'),(4,'v'),(9,'u'),(6,'i'),(1,'x'),(5,'l'),
  755. (8,'y'),(0,'p'),(0,'f'),(0,'p'),(7,'d'),(7,'f'),
  756. (5,'j'),(3,'e'),(1,'u'),(4,'v'),(9,'u'),(6,'i'),
  757. (1,'x'),(5,'l'),(8,'y'),(0,'p'),(0,'f'),(0,'p'),
  758. (0,'f'),(0,'p'),(7,'d'),(7,'f'),(5,'j'),(3,'e'),
  759. (1,'u'),(4,'v'),(9,'u'),(6,'i'),(1,'x'),(7,'d'),
  760. (7,'f'),(5,'j'),(3,'e'),(1,'u'),(0,'f'),(0,'p'),
  761. (7,'d'),(7,'f'),(5,'j'),(3,'e'),(1,'u'),(4,'v'),
  762. (9,'u'),(6,'i'),(1,'x'),(5,'l'),(8,'y'),(0,'p'),
  763. (0,'f'),(0,'p'),(0,'f'),(0,'p'),(7,'d'),(7,'f'),
  764. (5,'j'),(3,'e'),(1,'u'),(4,'v'),(9,'u'),(6,'i'),
  765. (1,'x'),(7,'d'),(7,'f'),(5,'j'),(3,'e'),(1,'u'),
  766. (4,'v'),(9,'u'),(6,'i'),(1,'x'),(5,'l'),(8,'y'),
  767. (0,'p'),(0,'f'),(0,'p'),(7,'d'),(7,'f'),(5,'j'),
  768. (3,'e'),(1,'u'),(4,'v'),(9,'u'),(6,'i'),(1,'x'),
  769. (5,'l'),(6,'q'),(2,'n'),(4,'r'),(4,'b'),(8,'y'),
  770. (0,'p'),(0,'f'),(0,'p'),(7,'d'),(7,'f'),(5,'j'),
  771. (3,'e'),(1,'u'),(4,'v'),(9,'u'),(6,'i'),(1,'x'),
  772. (7,'f'),(5,'j'),(3,'e'),(1,'u'),(4,'v'),(9,'u');
  773. SET @save_optimize_switch=@@optimizer_switch;
  774. SET optimizer_switch='materialization=on';
  775. EXPLAIN
  776. SELECT COUNT(*) FROM t1 AS t, t2
  777. WHERE c = g
  778. AND (EXISTS (SELECT * FROM t1, t2 WHERE a = f AND h <= t.e AND a > t.b)
  779. OR a = 0 AND h < 'z' );
  780. id select_type table type possible_keys key key_len ref rows Extra
  781. 1 PRIMARY t ALL PRIMARY,c NULL NULL NULL 64 Using where
  782. 1 PRIMARY t2 ref g g 5 test.t.c 9 Using where
  783. 2 DEPENDENT SUBQUERY t1 index PRIMARY d 3 NULL 64 Using where; Using index
  784. 2 DEPENDENT SUBQUERY t2 eq_ref PRIMARY PRIMARY 4 test.t1.a 1 Using where
  785. SELECT COUNT(*) FROM t1 AS t, t2
  786. WHERE c = g
  787. AND (EXISTS (SELECT * FROM t1, t2 WHERE a = f AND h <= t.e AND a > t.b)
  788. OR a = 0 AND h < 'z' );
  789. COUNT(*)
  790. 1478
  791. SELECT COUNT(*) FROM t1 AS t, t2
  792. WHERE c = g
  793. AND (EXISTS (SELECT * FROM t1, t2 WHERE a = f AND h <= t.e AND a > t.b)
  794. OR a = 0 AND h < 'z' );
  795. COUNT(*)
  796. 1478
  797. SET optimizer_switch=@save_optimizer_switch;
  798. DROP TABLE t1,t2;
  799. # check "Handler_pushed" status varuiables
  800. CREATE TABLE t1 (
  801. c1 CHAR(1),
  802. c2 CHAR(1),
  803. KEY (c1)
  804. );
  805. INSERT INTO t1 VALUES ('3', '3'),('4','4'),('5','5');
  806. flush status;
  807. show status like "Handler_icp%";
  808. Variable_name Value
  809. Handler_icp_attempts 0
  810. Handler_icp_match 0
  811. SELECT * FROM t1 FORCE INDEX(c1) WHERE (c1='3' or c1='4') and c1 % 2 = 0 ;
  812. c1 c2
  813. 4 4
  814. show status like "Handler_icp%";
  815. Variable_name Value
  816. Handler_icp_attempts 2
  817. Handler_icp_match 1
  818. SELECT * FROM t1 WHERE (c2='3' or c2='4') and c2 % 2 = 0 ;
  819. c1 c2
  820. 4 4
  821. show status like "Handler_icp%";
  822. Variable_name Value
  823. Handler_icp_attempts 2
  824. Handler_icp_match 1
  825. DROP TABLE t1;
  826. create table t1 (a int,b char(5),primary key (a), key (b(1)));
  827. insert into t1 values ('a','b');
  828. Warnings:
  829. Warning 1366 Incorrect integer value: 'a' for column 'a' at row 1
  830. select 1 from t1 where a and b >= 'aa';
  831. 1
  832. drop table t1;
  833. #
  834. # Bug#58015 "Assert in row_sel_field_store_in_mysql_format
  835. # when running innodb_mrr_icp test"
  836. #
  837. create table t1 (a char(2) charset utf8,b double, primary key (a(1)),key (b));
  838. insert into t1 values ('',1);
  839. select 1 from t1 where b <= 1 and a <> '';
  840. 1
  841. drop table t1;
  842. set optimizer_switch=@innodb_icp_tmp;
  843. set storage_engine= @save_storage_engine;