什么隐式类型转换？
在MySQL中:
当操作符与不同类型的操作数一起使用时，会发生类型转换以使操作数兼容。则会发生转换隐式
也就是说,MySQL会根据需要自动将数字转换为字符串，将字符串转换数字。看到这个概念之后,是不是有一种茅塞顿开的感觉。哦... 原来在数据结构中telephone字段为字符串(varchar)类型,而我们传的手机号是数字类型。
案例一: 字符串转换为数字
mysql > SELECT 1+'1';
结果:
mysql > 2
案例二: 数字转换为字符串
mysql -> SELECT CONCAT(1024,' andyqian');
结果:
'1024andyqian';
此时CONCAT(字符拼接)函数就将1024进行了隐式类型转换。
如何避免隐式类型转换?
只有当清楚的知道隐式类型转换的规则，才能从根本上避免产生隐式类型转换。MySQL也在官网描述了进行隐式类型转换的一些规则如下:
1. 隐式类型转换规则:
如果一个或两个参数都是NULL，比较的结果是NULL，除了NULL安全的<=>相等比较运算符。对于NULL <=> NULL，结果为true。不需要转换
如果比较操作中的两个参数都是字符串，则将它们作为字符串进行比较。
如果两个参数都是整数，则将它们作为整数进行比较。
如果不与数字进行比较，则将十六进制值视为二进制字符串
如果其中一个参数是十进制值，则比较取决于另一个参数。 如果另一个参数是十进制或整数值，则将参数与十进制值进行比较，如果另一个参数是浮点值，则将参数与浮点值进行比较
如果其中一个参数是TIMESTAMP或DATETIME列，另一个参数是常量，则在执行比较之前将常量转换为时间戳。
* 在所有其他情况下，参数都是作为浮点数（实数）比较的。
2. 使用CAST函数显示转换
我们可以使用CAST显示的将类型进行转换,如下所示:
mysql> SELECT 38.8, CAST(38.8 AS CHAR);
结果:
mysql > 38.8, '38.8'
如上述中:
select * from t_base_user where telephone=cast(12345678901 as char);
3. 类型一致
这里说的类型一致,指的是在写SQL时,参数类型一定要与数据库中的类型一致,避免产生隐式类型转换,就如刚才在文首时,如果多检查,写的SQL的参数类型与数据库中字段类型一致，也就不会不走索引了，你说是不是？
小心隐式类型转换
这里再重申一次,写SQL时一定要检查参数类型与数据库字段类型一致,(如果参数不一致,也要使用CAST函数显示转换成一致)否则造成隐式类型转换,不走索引,后果简直不堪设想, 在前面《写会MySQL索引》这篇文章中提到过,不走索引,轻则造成慢查询，重则造成数据库服务器CPU100%。唉,说到这里,不瞒你说，我就吃过不少MySQL隐式类型转换的亏 ! (如慢查询) !
在mysql查询中，当查询条件左右两侧类型不匹配的时候会发生隐式转换，可能导致查询无法使用索引。下面分析两种隐式转换的情况
看表结构 phone为 int类型,name为 varchar
EXPLAIN select * from user where phone = '2'
EXPLAIN select * from user where phone = 2
两种情况都可以用到索引,这次等号右侧是'2'，注意带单引号哟，左侧的索引字段是int类型，因此也会发生隐式转换，但因为int类型的数字只有2能转化为'2'，是唯一确定的。所以虽然需要隐式转换，但不影响使用索引，不会导致慢查询
EXPLAIN select * from user where name= '2'
这种情况也能使用索引,因为他们本身就是varchar 类型
EXPLAIN select * from user where name= 2
因为等号两侧类型不一致，因此会发生隐式转换，cast(index_filed as signed)，然后和2进行比较。因为'2'，' 2'，'2a'都会转化成2，故MySQL无法使用索引只能进行全表扫描，造成了慢查询的产生。
小结
看到这里,是不是有一种,数据表设计还真不是件容易的事情。需要考虑的因素太多太多了,需要考虑字段类型,索引设计,还有各种约束条件等等。也一定要谨慎谨慎再谨慎！其实换个角度就更容易理解了,大家都知道高楼大厦都是需要一个好的地基的,在数据库表设计中,前期的表结构设计就是这个地基，其重要性可想而知。
