mariadb/mysql-test/main/func_group_innodb.result

284 lines
8 KiB
Text
Raw Normal View History

set @innodb_stats_persistent_save= @@innodb_stats_persistent;
set @innodb_stats_persistent_sample_pages_save=
@@innodb_stats_persistent_sample_pages;
set global innodb_stats_persistent= 1;
set global innodb_stats_persistent_sample_pages=100;
create table t1 (USR_ID integer not null, MAX_REQ integer not null, constraint PK_SEA_USER primary key (USR_ID)) engine=InnoDB;
insert into t1 values (1, 3);
select count(*) + MAX_REQ - MAX_REQ + MAX_REQ - MAX_REQ + MAX_REQ - MAX_REQ + MAX_REQ - MAX_REQ + MAX_REQ - MAX_REQ as exp from t1 group by MAX_REQ;
exp
1
select Case When Count(*) < MAX_REQ Then 1 Else 0 End from t1 where t1.USR_ID = 1 group by MAX_REQ;
Case When Count(*) < MAX_REQ Then 1 Else 0 End
1
drop table t1;
create table t1m (a int) engine=myisam;
create table t1i (a int) engine=innodb;
create table t2m (a int) engine=myisam;
create table t2i (a int) engine=innodb;
insert into t2m values (5);
insert into t2i values (5);
select min(a) from t1m;
min(a)
NULL
select min(7) from t1m;
min(7)
NULL
select min(7) from DUAL;
min(7)
2006-09-18 18:30:51 +04:00
7
explain select min(7) from t2m join t1m;
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(7) from t2m join t1m;
min(7)
NULL
select max(a) from t1m;
max(a)
NULL
select max(7) from t1m;
max(7)
NULL
select max(7) from DUAL;
max(7)
2006-09-18 18:30:51 +04:00
7
explain select max(7) from t2m join t1m;
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(7) from t2m join t1m;
max(7)
NULL
select 1, min(a) from t1m where a=99;
1 min(a)
1 NULL
select 1, min(a) from t1m where 1=99;
1 min(a)
1 NULL
select 1, min(1) from t1m where a=99;
1 min(1)
1 NULL
select 1, min(1) from t1m where 1=99;
1 min(1)
1 NULL
select 1, max(a) from t1m where a=99;
1 max(a)
1 NULL
select 1, max(a) from t1m where 1=99;
1 max(a)
1 NULL
select 1, max(1) from t1m where a=99;
1 max(1)
1 NULL
select 1, max(1) from t1m where 1=99;
1 max(1)
1 NULL
select min(a) from t1i;
min(a)
NULL
select min(7) from t1i;
min(7)
NULL
select min(7) from DUAL;
min(7)
2006-09-18 18:30:51 +04:00
7
explain select min(7) from t2i join t1i;
id select_type table type possible_keys key key_len ref rows Extra
Bug #27531: 5.1 part of the fix - Renamed "Using join cache" to "Using join buffer". - "Using join buffer" is now printed on the last table that "reads" from the join buffer cache. mysql-test/r/archive_gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/compress.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ctype_utf8.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/derived.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/distinct.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/func_group.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/func_group_innodb.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/greedy_optimizer.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/group_by.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/group_min_max.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/index_merge_myisam.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/information_schema.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/innodb_gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/innodb_mysql.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/join.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/join_nested.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/key_diff.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/myisam.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ndb_condition_pushdown.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ndb_gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/range.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/row.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/select.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ssl.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ssl_compress.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/subselect.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/subselect3.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/union.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/view.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. sql/sql_select.cc: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch.
2007-05-29 15:58:18 +03:00
1 SIMPLE t2i ALL NULL NULL NULL NULL 1
1 SIMPLE t1i ALL NULL NULL NULL NULL 1 Using join buffer (flat, BNL join)
select min(7) from t2i join t1i;
min(7)
NULL
select max(a) from t1i;
max(a)
NULL
select max(7) from t1i;
max(7)
NULL
select max(7) from DUAL;
max(7)
2006-09-18 18:30:51 +04:00
7
explain select max(7) from t2i join t1i;
id select_type table type possible_keys key key_len ref rows Extra
Bug #27531: 5.1 part of the fix - Renamed "Using join cache" to "Using join buffer". - "Using join buffer" is now printed on the last table that "reads" from the join buffer cache. mysql-test/r/archive_gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/compress.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ctype_utf8.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/derived.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/distinct.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/func_group.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/func_group_innodb.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/greedy_optimizer.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/group_by.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/group_min_max.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/index_merge_myisam.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/information_schema.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/innodb_gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/innodb_mysql.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/join.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/join_nested.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/key_diff.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/myisam.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ndb_condition_pushdown.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ndb_gis.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/range.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/row.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/select.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ssl.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/ssl_compress.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/subselect.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/subselect3.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/union.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. mysql-test/r/view.result: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch. sql/sql_select.cc: Bug #27531: renamed "Using join cache" to "Using join buffer" and moved to the last table in the batch.
2007-05-29 15:58:18 +03:00
1 SIMPLE t2i ALL NULL NULL NULL NULL 1
1 SIMPLE t1i ALL NULL NULL NULL NULL 1 Using join buffer (flat, BNL join)
select max(7) from t2i join t1i;
max(7)
NULL
select 1, min(a) from t1i where a=99;
1 min(a)
1 NULL
select 1, min(a) from t1i where 1=99;
1 min(a)
1 NULL
select 1, min(1) from t1i where a=99;
1 min(1)
1 NULL
select 1, min(1) from t1i where 1=99;
1 min(1)
1 NULL
select 1, max(a) from t1i where a=99;
1 max(a)
1 NULL
select 1, max(a) from t1i where 1=99;
1 max(a)
1 NULL
select 1, max(1) from t1i where a=99;
1 max(1)
1 NULL
select 1, max(1) from t1i where 1=99;
1 max(1)
1 NULL
explain select count(*), min(7), max(7) from t1m, t1i;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1m system NULL NULL NULL NULL 0 Const row not found
1 SIMPLE t1i ALL NULL NULL NULL NULL 1
select count(*), min(7), max(7) from t1m, t1i;
count(*) min(7) max(7)
0 NULL NULL
explain select count(*), min(7), max(7) from t1m, t2i;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1m system NULL NULL NULL NULL 0 Const row not found
1 SIMPLE t2i ALL NULL NULL NULL NULL 1
select count(*), min(7), max(7) from t1m, t2i;
count(*) min(7) max(7)
0 NULL NULL
explain select count(*), min(7), max(7) from t2m, t1i;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2m system NULL NULL NULL NULL 1
1 SIMPLE t1i ALL NULL NULL NULL NULL 1
select count(*), min(7), max(7) from t2m, t1i;
count(*) min(7) max(7)
0 NULL NULL
drop table t1m, t1i, t2m, t2i;
#
# Bug #57954: BIT_AND function returns incorrect results when
# semijoin=on
CREATE TABLE c (
pk INT,
col_varchar_key VARCHAR(1),
PRIMARY KEY (pk),
KEY col_varchar_key (col_varchar_key)
) ENGINE=InnoDB;
INSERT INTO c VALUES (11,NULL);
INSERT INTO c VALUES (16,'c');
CREATE TABLE bb (
pk INT,
col_varchar_key VARCHAR(1),
PRIMARY KEY (pk),
KEY col_varchar_key (col_varchar_key)
) ENGINE=InnoDB;
INSERT INTO bb VALUES (10,NULL);
SELECT straight_join BIT_AND(c.pk)
FROM
bb, c
WHERE c.col_varchar_key='ABC'
ORDER BY c.pk;
BIT_AND(c.pk)
18446744073709551615
DROP TABLE c,bb;
#
# Bug #58050: BIT_OR and BIT_XOR return incorrect results when
# semijoin=on
#
CREATE TABLE t1 (pk INT PRIMARY KEY, b INT, c INT) ENGINE=InnoDB;
INSERT INTO t1 VALUES(1, 1, 1);
CREATE TABLE t2 (pk INT PRIMARY KEY, b INT, c INT) ENGINE=InnoDB;
INSERT INTO t2 VALUES (1, 1, NULL);
SELECT t1.* FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1;
pk b c
SELECT BIT_OR(t1.b) FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1;
BIT_OR(t1.b)
0
SELECT BIT_AND(t1.b) FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1;
BIT_AND(t1.b)
18446744073709551615
SELECT BIT_XOR(t1.b) FROM t1 JOIN t2 ON t1.c=t2.c WHERE t1.pk=1;
BIT_XOR(t1.b)
0
DROP TABLE t1, t2;
2012-06-14 20:05:31 +02:00
#
# Bug#12713907: STRANGE OPTIMIZE & WRONG RESULT UNDER ORDER BY
# COUNT(*) LIMIT.
#
CREATE TABLE t1 (
id BIGINT(20) ,
member_id_to INT(11) ,
r_date DATE ,
PRIMARY KEY (id,r_date),
KEY r_date_idx (r_date),
KEY t1_idx01 (member_id_to)
) ENGINE=InnoDB;
INSERT INTO t1 VALUES
(107924526,518491,'2011-05-01'),
(107924527,518491,'2011-05-01'),
(107924534,518491,'2011-06-21'),
(107924535,518491,'2011-06-21'),
(107924542,1601319,'2011-06-21'),
(107924543,1601319,'2011-06-21'),
(107924544,1601319,'2011-06-21'),
(107924545,1601319,'2011-06-21');
SELECT member_id_to, COUNT(*) FROM t1 WHERE r_date =
'2011-06-21' GROUP BY member_id_to ORDER BY 2 LIMIT 1;
member_id_to COUNT(*)
518491 2
DROP TABLE t1;
#
# MDEV-4269: crash when grouping by values()
#
SELECT @@default_storage_engine INTO @old_engine;
set default_storage_engine=innodb;
create table y select 1 b;
select 1 from y group by b;
1
1
select 1 from y group by value(b);
1
1
drop table y;
SET default_storage_engine=@old_engine;
#
# Bug#13723054 CRASH WITH MIN/MAX AFTER QUICK_GROUP_MIN_MAX_SELECT::NEXT_MIN
#
CREATE TABLE t1(a BLOB, b VARCHAR(255) CHARSET LATIN1, c INT,
KEY(b, c, a(765))) ENGINE=INNODB;
Fixed the problem of mdev-5947. Back-ported from the mysql 5.6 code line the patch with the following comment: Fix for Bug#11757108 CHANGE IN EXECUTION PLAN FOR COUNT_DISTINCT_GROUP_ON_KEY CAUSES PEFORMANCE REGRESSION The cause for the performance regression is that the access strategy for the GROUP BY query is changed form using "index scan" in mysql-5.1 to use "loose index scan" in mysql-5.5. The index used for group by is unique and thus each "loose scan" group will only contain one record. Since loose scan needs to re-position on each "loose scan" group this query will do a re-position for each index entry. Compared to just reading the next index entry as a normal index scan does, the use of loose scan for this query becomes more expensive. The cause for selecting to use loose scan for this query is that in the current code when the size of the "loose scan" group is one, the formula for calculating the cost estimates becomes almost identical to the cost of using normal index scan. Differences in use of integer versus floating point arithmetic can cause one or the other access strategy to be selected. The main issue with the formula for estimating the cost of using loose scan is that it does not take into account that it is more costly to do a re-position for each "loose scan" group compared to just reading the next index entry. Both index scan and loose scan estimates the cpu cost as: "number of entries needed too read/scan" * ROW_EVALUATE_COST The results from testing with the query in this bug indicates that the real cost for doing re-position four to eight times higher than just reading the next index entry. Thus, the cpu cost estimate for loose scan should be increased. To account for the extra work to re-position in the index we increase the cost for loose index scan to include the cost of navigating the index. This is modelled as a function of the height of the b-tree: navigation cost= ceil(log(records in table)/log(indexes per block)) * ROWID_COMPARE_COST; This will avoid loose index scan being used for indexes where the "loose scan" group contains very few index entries.
2014-04-22 14:39:57 -07:00
INSERT INTO t1(a, b, c) VALUES
('', 'a', 0), ('', 'a', null), ('', 'a', 0), ('', 'a', null), ('', 'a', 0),
('', 'a', 1), ('', 'a', 1), ('', 'a', 2), ('', 'a', 2), ('', 'a', 3),
('', 'a', 3), ('', 'a', 4), ('', 'a', 4), ('', 'a', 5), ('', 'a', 5);
Fixed the problem of mdev-5947. Back-ported from the mysql 5.6 code line the patch with the following comment: Fix for Bug#11757108 CHANGE IN EXECUTION PLAN FOR COUNT_DISTINCT_GROUP_ON_KEY CAUSES PEFORMANCE REGRESSION The cause for the performance regression is that the access strategy for the GROUP BY query is changed form using "index scan" in mysql-5.1 to use "loose index scan" in mysql-5.5. The index used for group by is unique and thus each "loose scan" group will only contain one record. Since loose scan needs to re-position on each "loose scan" group this query will do a re-position for each index entry. Compared to just reading the next index entry as a normal index scan does, the use of loose scan for this query becomes more expensive. The cause for selecting to use loose scan for this query is that in the current code when the size of the "loose scan" group is one, the formula for calculating the cost estimates becomes almost identical to the cost of using normal index scan. Differences in use of integer versus floating point arithmetic can cause one or the other access strategy to be selected. The main issue with the formula for estimating the cost of using loose scan is that it does not take into account that it is more costly to do a re-position for each "loose scan" group compared to just reading the next index entry. Both index scan and loose scan estimates the cpu cost as: "number of entries needed too read/scan" * ROW_EVALUATE_COST The results from testing with the query in this bug indicates that the real cost for doing re-position four to eight times higher than just reading the next index entry. Thus, the cpu cost estimate for loose scan should be increased. To account for the extra work to re-position in the index we increase the cost for loose index scan to include the cost of navigating the index. This is modelled as a function of the height of the b-tree: navigation cost= ceil(log(records in table)/log(indexes per block)) * ROWID_COMPARE_COST; This will avoid loose index scan being used for indexes where the "loose scan" group contains very few index entries.
2014-04-22 14:39:57 -07:00
ANALYZE TABLE t1;
EXPLAIN SELECT MIN(c) FROM t1 GROUP BY b;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range NULL b 263 NULL 2 Using index for group-by
Added test cases for preceding test This includes all test changes from "Changing all cost calculation to be given in milliseconds" and forwards. Some of the things that caused changes in the result files: - As part of fixing tests, I added 'echo' to some comments to be able to easier find out where things where wrong. - MATERIALIZED has now a higher cost compared to X than before. Because of this some MATERIALIZED types have changed to DEPENDEND SUBQUERY. - Some test cases that required MATERIALIZED to repeat a bug was changed by adding more rows to force MATERIALIZED to happen. - 'Filtered' in SHOW EXPLAIN has in many case changed from 100.00 to something smaller. This is because now filtered also takes into account the smallest possible ref access and filters, even if they where not used. Another reason for 'Filtered' being smaller is that we now also take into account implicit filtering done for subqueries using FIRSTMATCH. (main.subselect_no_exists_to_in) This is caluculated in best_access_path() and stored in records_out. - Table orders has changed because more accurate costs. - 'index' and 'ALL' for small tables has changed to use 'range' or 'ref' because of optimizer_scan_setup_cost. - index can be changed to 'range' as 'range' optimizer assumes we don't have to read the blocks from disk that range optimizer has already read. This can be confusing in the case where there is no obvious where clause but instead there is a hidden 'key_column > NULL' added by the optimizer. (main.subselect_no_exists_to_in) - Scan on primary clustered key does not report 'Using Index' anymore (It's a table scan, not an index scan). - For derived tables, the number of rows is now 100 instead of 2, which can be seen in EXPLAIN. - More tests have "Using index for group by" as the cost of this optimization is now more correct (lower). - A primary key could be preferred for a normal key, even if it would access more rows, as it's faster to do 1 lokoup and 3 'index_next' on a clustered primary key than one lookup trough a secondary. (main.stat_tables_innodb) Notes: - There was a 4.7% more calls to best_extension_by_limited_search() in the main.greedy_optimizer test. However examining the test results it looked that the plans where slightly better (eq_ref where more chained together) so I assume this is ok. - I have verified a few test cases where there was notable/unexpected changes in the plan and in all cases the new optimizer plans where faster. (main.greedy_optimizer and some others)
2022-10-04 16:16:06 +03:00
SELECT MIN(c) FROM t1 GROUP BY b;
MIN(c)
0
DROP TABLE t1;
#
# MDEV-17589: Stack-buffer-overflow with indexed varchar (utf8) field
#
CREATE TABLE t1 (v1 varchar(1020), v2 varchar(2), v3 varchar(2),
KEY k1 (v3,v2,v1)) ENGINE=InnoDB CHARACTER SET=utf8 ROW_FORMAT=DYNAMIC;
INSERT INTO t1 VALUES ('king', 'qu','qu'), ('bad','go','go');
explain
SELECT MIN(t1.v1) FROM t1 where t1.v2='qu' and t1.v3='qu';
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(t1.v1) FROM t1 where t1.v2='qu' and t1.v3='qu';
MIN(t1.v1)
king
drop table t1;
CREATE TABLE t1 (v1 varchar(1024) CHARACTER SET utf8, KEY v1 (v1)) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;
INSERT INTO t1 VALUES ('king'), ('bad');
explain
SELECT MIN(x.v1) FROM (SELECT t1.* FROM t1 WHERE t1.v1 >= 'p') x;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL No matching min/max row
SELECT MIN(x.v1) FROM (SELECT t1.* FROM t1 WHERE t1.v1 >= 'p') x;
MIN(x.v1)
NULL
drop table t1;
End of 5.5 tests
set global innodb_stats_persistent= @innodb_stats_persistent_save;
set global innodb_stats_persistent_sample_pages=
@innodb_stats_persistent_sample_pages_save;