一，场景说明
表A字段：
a1 手机号，有索引
b1 关联用字段，bigint 数字类型
其他字段
表B字段：
b1 关联用字段，varchar 字符串类型，有索引
其他字段
现在计划将两个表通过b1字段进行连接，注意，两个表的b1字段类型不同。
二，错误的sql
select *
from A
join B on A.b1=B.b1
where a.phone=xxx;
三，现象
1，上述sql执行会非常慢，表B的b1字段有索引但是没什么用。
2，上述sql用explain解析后，在key列中显示，会使用B.b1字段索引。
3，上述sql用explain解析后，在row列中显示，行数几乎等于表B的所有行。
四，知识点
1，字段关联时，如果字段类型不同，会触发隐式转换。
当关联的两个字段类型不同时，MySQL会进行隐式转换，上述sql相当于执行了：
select *
from A
join B on A.b1=CAST(B.b1 AS UNSIGNED)
where a.phone=xxx;
关联表B时，使用了函数，所以索引会失效。
2，隐式转换的策略，数字优先。
既然会隐式转换，那么问题来了：MySQL为什么选择把表B的b1转换成数字，而不是把表A的b1转换成字符串，这样关联表B时不就能用索引了么？
因为，MySQL做隐式转换是有优先级的，数字类型(INT, DECIMAL等) > 字符串类型(VARCHAR, CHAR等)
也就是说，当数字 = 字符串时，MySQL会将字符串转换为数字。
这个优先级的设定也能解释一个更常见的索引失效场景：
1，当字段col是数字时，where col='123'; 能用索引。因为字段类型是数字，MySQL会把字符串隐式转成数字，索引生效。
2，当字段col是字符串时，where col=123; 不能用索引。因为字段类型是字符串，MySQL不会把数字隐式转为字符串，索引无效。
3，explain结果中key列的索引，包含索引扫描和索引查询两种。
索引扫描和索引查询都会使explain结果的key列显示目标索引，Extra列也都会显示Using index，但这不代表此索引就会高效生效。
索引扫描：把索引列拿出来用了。基本要扫描索引的每一行，所以效率基本等于全表扫描，真正需要查询时不一定用的上索引。
索引查询：查询时先用索引匹配目标行，再查询行中其他字段信息。这是"真使用索引"。
在上面的例子中，MySQL只是把表B的b1字段索引列拿出来批量做了一下隐式转换，真正查询表B的时候是用数字类型查的，用不上索引。
4，explain的结果不能只看key列。
key列能表示是否用到索引，而rows列能体现索引性能，如果发现key列有值，而rows的数字几乎等于全表数据量，基本可以认定是只命中了索引扫描，但查询性能不高。
五，解决方案
解决方案按实际情况和业务内容进行处理，比如显式进行数字到字符串的类型转换：
select *
from A
join B on cast(A.b1 as char)=B.b1
where a.phone=xxx;