MySQL SQL优化之字符串索引隐式转换
之前有用户很不解:SQL语句非常简单,就是select * from test_1 where user_id=1 这种类型,而且user_id上已经建立索引了,怎么还是查询很慢?
test_1的表结构:
CREATE TABLE `test_1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` varchar(30) NOT NULL,
`name` varchar(30) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
查看执行计划,可以看出进行了全表扫描,并没有用上user_id的索引。
mysql> explain select * from test_1 where user_id=1;
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | test_1 | ALL | idx_user_id | NULL | NULL | NULL | 3 | Using where |
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.01 sec)
仔细看下表结构,user_id的字段类型: `user_id` varchar(30) NOT NULL,
而用户传入的是int,这里会有一个隐式转换的问题。隐式转换会导致全表扫描。
把输入改成字符串类型,执行计划如下,这样就会很快了。
mysql> explain select * from test_1 where user_id='1';
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------------+
| 1 | SIMPLE | test_1 | ref | idx_user_id | idx_user_id | 92 | const | 1 | Using where |
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------------+
1 row in set (0.00 sec)
此外,还需要注意的是:
数字类型的0001等价于1
字符串的0001和1不等价
mysql> select * from test_1;
+----+---------+------+
| id | user_id | name |
+----+---------+------+
| 1 | 0001 | kate |
| 2 | 1101 | Jim |
| 3 | 1 | Jim |
+----+---------+------+
3 rows in set (0.01 sec)
mysql> select * from test_1 where user_id=1;
+----+---------+------+
| id | user_id | name |
+----+---------+------+
| 1 | 0001 | kate |
| 3 | 1 | Jim |
+----+---------+------+
2 rows in set (0.00 sec)
mysql> select * from test_1 where user_id='1';
+----+---------+------+
| id | user_id | name |
+----+---------+------+
| 3 | 1 | Jim |
+----+---------+------+
1 row in set (0.00 sec)
如果表定义的是int字段,传入的是字符串,则不会发生隐式转换。
看下面的测试:
CREATE TABLE `test_2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`name` varchar(30) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
mysql> explain select * from test_2 where user_id=1;
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------+
| 1 | SIMPLE | test_2 | ref | idx_user_id | idx_user_id | 4 | const | 2 | |
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------+
1 row in set (0.00 sec)
mysql> explain select * from test_2 where user_id='1';
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------+
| 1 | SIMPLE | test_2 | ref | idx_user_id | idx_user_id | 4 | const | 2 | |
+----+-------------+--------+------+---------------+-------------+---------+-------+------+-------+
1 row in set (0.00 sec)
MySQL SQL优化之字符串索引隐式转换的更多相关文章
- SQL Server中提前找到隐式转换提升性能的办法
http://www.cnblogs.com/shanksgao/p/4254942.html 高兄这篇文章很好的谈论了由于数据隐式转换造成执行计划不准确,从而造成了死锁.那如果在事情出现之前 ...
- 【转】SQL SERVER标量表达式的隐式转换
在SQL Server中的数据类型中,存在着优先级的问题.标量表达示的返回结果类型也会根据操作数的类型而定,如1 +'1'=2.而不是'11',因些Int型的优先级比VARCHAR型的优先级要高.所以 ...
- SQL Server有意思的数据类型隐式转换问题
写这篇文章的时候,还真不知道如何取名,也不知道这个该如何将其归类.这个是同事遇到的一个案例,案例比较复杂,这里抽丝剥茧,仅仅构造一个简单的案例来展现一下这个问题.我们先构造测试数据,如下所示: CRE ...
- mysql字符串的隐式转换导致查询异常
如果mysql某个字段(name)类型为varchar, 加了索引,在执行where查询的时候,传入了int的值,这样就会全表扫描,把每一条的值都转换成int(会出现"中国"-&g ...
- MySQL性能优化:MySQL中的隐式转换造成的索引失效
数据库优化是一个任重而道远的任务,想要做优化必须深入理解数据库的各种特性.在开发过程中我们经常会遇到一些原因很简单但造成的后果却很严重的疑难杂症,这类问题往往还不容易定位,排查费时费力最后发现是一个很 ...
- JavaScript 隐式转换
javascript 中的怪癖,js运算符隐式类型转换 x + "" //等价于 String(x) + x //等价于 Number(x),也可以写成x-0 !!x //等价于 ...
- ORACLE数据库中执行计划出现INTERNAL_FUNCTION一定是隐式转换吗?
ORACLE数据库中,我们会使用一些SQL语句找出存在隐式转换的问题SQL,其中网上流传的一个SQL语句如下,查询V$SQL_PLAN的字段FILTER_PREDICATES中是否存在INTERNAL ...
- 每天多一点(2016.12.04)》Javascript隐式转换
乱想 javascript为什么需要隐式转换?如果没有会出现什么情况? 找了一圈没有看到关于这个的讨论,只好自己研究了,可能不一定正确,自行辨知. 郁闷就是郁闷在好好的,为什么要搞个隐式转换,一般来讲 ...
- Javascript隐式转换
乱想 javascript为什么需要隐式转换?如果没有会出现什么情况? 找了一圈没有看到关于这个的讨论,只好自己研究了,可能不一定正确,自行辨知. 郁闷就是郁闷在好好的,为什么要搞个隐式转换,一般来讲 ...
随机推荐
- 【非原】c语言之声明和定义的区别
原创地址:http://www.cnblogs.com/haore147/p/3647466.html 什么是定义?什么是声明?它们有何区别? 举个例子: 1 2 A)int i; B)extern ...
- sharepoint 2010 masterpage中必须的Content PlaceHolder
Professional SharePoint 2010 Branding and Use
- mysql日志详细解析 [转]
原文出处:http://pangge.blog.51cto.com/6013757/1319304 MySQL日志: 主要包含:错误日志.查询日志.慢查询日志.事务日志.二进制日志: 日志是mysql ...
- hdu 4707 Pet(DFS水过)
http://acm.hdu.edu.cn/showproblem.php?pid=4707 [题目大意]: Lin Ji 的宠物鼠丢了,在校园里寻找,已知Lin Ji 在0的位置,输入N D,N表示 ...
- 1588: [HNOI2002]营业额统计 - BZOJ
Description营业额统计 Tiger最近被公司升任为营业部经理,他上任后接受公司交给的第一项任务便是统计并分析公司成立以来的营业情况. Tiger拿出了公司的账本,账本上记录了公司成立以来每天 ...
- C/C++ 框架,类库,资源集合
很棒的 C/C++ 框架,类库,资源集合. Awesome C/C++ Standard Libraries Frameworks Artificial Intelligence Asynchrono ...
- HDU4628+状态压缩DP
/* 状态压缩DP dp[ i ]:达到i状态的最小step. 题意:每次可以去掉一个回文串,求最少几步能取完. */ #include<stdio.h> #include<stri ...
- C/C++语言参数传递----函数/方法 参数的指针引用传递
int m_value = 1; void func(int *p) { p = &m_value; } int main(int argc, char *argv[]) { int n = ...
- SaaS系列介绍之三: SaaS的特性与作用
1 SaaS的特性 最早的SaaS服务之一当属在线电子邮箱,极大地降低了个人与企业使用电子邮件的门槛,进而改变了人与人.企业与企业之间的沟通方式.发展至今,SaaS服务的种类与产品已经非常丰富,面向个 ...
- spring的组成
① Spring Core:核心容器,BeanFactory提供了组件生命周期的管理,组件的创建,装配,销毁等功能 SpringContext:ApplicationContext,扩展核心容器,提供 ...