数据类型隐式转换测试报告

摘要: 数据类型隐式转换是否对性能有所影响？详见正文。

数据类型隐式转换性能损失报告

１.前言
数据类型隐式转换对于开发人员和DBA来说可能是被忽略的一块。在很多项目中由于人员流动或者管理不够完善造成代码中会出现数据类型隐式转换的情况。
在mysql中由于默认配置下对隐式转换睁一眼闭一眼，这样会给我们的应用性能造成了很多隐患。
本专题主要针对数据类型隐式转换来讨论，看看到底隐式转换会不会造成性能损耗。

2.测试环境
2.1.软件环境
操作系统环境：CentOS 6.6 64位
软件版本：Percona-Server-server-56-5.6.25-rel73.1.el6.x86_64

3.测试内容
3.1.表结构中a2列为字符类型的情况
3.1.1.表结构定义
CREATE TABLE `test1` (
`a1` bigint(20) NOT NULL,
`a2` varchar(255) DEFAULT NULL, 此列为字符类型时。
`a3` int(11) DEFAULT NULL,
PRIMARY KEY (`a1`),
KEY `idx_test1_a2` (`a2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

3.1.2.不存在数据类型隐式转换
explain select * from test1 where a2 = '31' \p;
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-----------------------+
| 1 | SIMPLE | test1 | ref | idx_test1_a2 | idx_test1_a2 | 768 | const | 137790 | Using index condition |
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-----------------------+

select * from test1 where a2 = '31' \p;
69442 rows in set (0.10 sec)

3.1.3.存在数据类型隐式转换
#explain select * from test1 where a2 = 31 \p;
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
| 1 | SIMPLE | test1 | ALL | idx_test1_a2 | NULL | NULL | NULL | 3284646 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+

#select * from test1 where a2 = 31 \p;
69442 rows in set (0.90 sec)

3.2.表结构中a2列为数字类型的情况
3.2.1表结构定义
CREATE TABLE `test1` (
`a1` bigint(20) NOT NULL,
`a2` int(11) DEFAULT NULL, 此列为数字类型
`a3` int(11) DEFAULT NULL,
PRIMARY KEY (`a1`),
KEY `idx_test1_a2` (`a2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

3.2.2.不存在数据类型隐式转换
#explain select * from test1 where a2 = 31 \p;
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-------+
| 1 | SIMPLE | test1 | ref | idx_test1_a2 | idx_test1_a2 | 5 | const | 127204 | NULL |
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-------+

#select * from test1 where a2 = 31 \p;
69442 rows in set (0.08 sec)

3.2.3.存在数据类型隐式转换
explain select * from test1 where a2 = '31' \p;
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-------+
| 1 | SIMPLE | test1 | ref | idx_test1_a2 | idx_test1_a2 | 5 | const | 127204 | NULL |
+----+-------------+-------+------+---------------+--------------+---------+-------+--------+-------+

select * from test1 where a2 = '31' \p;
69442 rows in set (0.07 sec)

4.性能对比
结论：
如果某列数据类型为字符类型，并且有索引。发生数据类型隐式转换后，语句的查询时间增加了８倍。
如果某列数据类型为数字类型，并且有索引。由于都使用了索引，即使发生数据类型转换，语句的查询时间没有太大差别。
无论列的类型是什么类型，一定要保证语句中的值与列类型一致。否则存在很大的性能隐患和增加了代码的维护难度。