Two types of very hidden full table scans that cannot hit the index (one-minute series)

In "Two Tools for MySQL Deadlock Analysis", an example of a deadlock caused by forced type conversion was cited. A friend asked if the type conversion could not hit the index. Spend 1 minute to elaborate.

The first category: the "column type" does not match the "where value type", and the index cannot be hit, which will result in a full table scan.

data preparation:

create table t1 (
cell varchar(3) primary key
)engine=innodb default charset=utf8;

insert into t1(cell) values ('111'),('222'),('333');

(1) The cell attribute is of varchar type;
(2) The cell is the primary key, that is, the clustered index;
(3) t1 inserts 3 pieces of test data;

Test statement:

explain select * from t1 where cell=111;
explain select * from t1 where cell='111';

(1) In the first statement, the value type after where is an integer (inconsistent with the table cell type);
(2) In the second statement, the value type after where is a string (consistent with the table cell type);

Test Results:

(1) Forced type conversion, which cannot hit the index, requires a full table scan, ie 3 records;
(2) The same type, hits the index, 1 record;
voice-over: For explain, see "Two Tools for MySQL Deadlock Analysis" ".

The second category: the character encodings of the two joined tables are different, and the index cannot be hit, which will lead to the nested loop of the Cartesian product.

data preparation:

create table t2 (
cell varchar(3) primary key
)engine=innodb default charset=latin1;

insert into t2(cell) values ('111'),('222'),('333'),('444'),('555'),('666');

create table t3 (
cell varchar(3) primary key
)engine=innodb default charset=utf8;

insert into t3(cell) values ('111'),('222'),('333'),('444'),('555'),('666');

(1) t2 and t1 character sets are different, insert 6 pieces of test data;
(2) t3 and t1 character sets are the same, and insert 6 pieces of test data;
(3) In addition, t1, t2, t3 table structure is exactly the same ；

Test statement:

explain select * from t1,t2 where t1.cell=t2.cell;
explain select * from t1,t3 where t1.cell=t3.cell;

(1) The first join, with tables t1 and t2 (different character sets), and the associated attribute is cell;
(2) The first join, with tables t1 and t3 (same character set), and the associated attribute is cell;

Test Results:

(1) The character sets of t1 and t2 are different, and the storage space is different;
(2) When t1 and t2 are joined, all 3 records of t1 are traversed, and each record of t1 needs to traverse all 6 records of t2. The index is invalid if the Cartesian product loop calculation (nested loop) is used;
(3) When t1 and t3 are joined, all 3 records of t1 are traversed, and each record of t1 uses t3 index, that is, scans 1 line of records;
voice-over: Please enlarge the picture.

to sum up

There are two types of hidden cases
where indexes cannot be used: (1) The column type is inconsistent with the where value type;
(2) The character encoding of the join table is different;
voice-over: This article was tested in MySQL5.6.

Architect's Road-Sharing technical ideas
related recommendations:
"MyISAM and InnoDB index differences | 1 minute series"
"buffer pool (buffer pool), this time thoroughly understand! ! ! "
Write buffer (change buffer), thoroughly understand this time!" ! ! 》

作业``
create table t1 (
cell varchar(3) primary key
)engine=innodb default charset=utf8;

insert into t1(cell) values ('111'),('222'),('333');

create table t2 (
cell char(3) primary key
)engine=innodb default charset=utf8;

insert into t2(cell) values ('111'),('222'),('333'),('444'),('555'),('666');

create table t3 (
cell int primary key
)engine=innodb default charset=utf8;

insert into t3(cell) values (111),(222),(333),(444),(555),(666);

(1) The cell types of t1, t2, and t3 are different: varchar(3), char(3), and int respectively;
(2) The coding type is the same, all are utf8;

Excuse me: Can the join query of t1 and t2, t1 and t3 hit the index?
explain select from t1,t2 where t1.cell=t2.cell;
explain select from t1,t3 where t1.cell=t3.cell;

Do it yourself, "actual results" and "what you think" may not be the same.

I hope that this one minute will be rewarding and thoughtful for everyone, and ask for help.