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为什么需要隐式转换?如果没有会出现什么情况? 找了一圈没有看到关于这个的讨论,只好自己研究了,可能不一定正确,自行辨知. 郁闷就是郁闷在好好的,为什么要搞个隐式转换,一般来讲 ...
随机推荐
- Webx框架自带的petstore
Webx框架:http://openwebx.org/ petstore:webx3/webx-sample/petstore/tags/3.0/petstore 编译之后:mvn jetty:run ...
- Qt单元测试
单元测试之作用要完成测试用例,保证设计上的耦合依赖通过测试用例,保证覆盖率,提高程序质量 QTest一些有用的静态函数QTest::qExecQTest::qSleepQTest::qWait 例 ...
- 转载:传说中的T检验
第二周结束:传说中的T检验 小耿2014-01-21 10:58 本文和上一篇笔记一样:语言十分啰嗦.请大家忍耐…… 以前我不懂统计的时候(现在也不懂),只知道数据出来了要做三件事:1,检验一下数据是 ...
- Elasticsearch从0.90到1.2的不兼容变化-系统和设置
本文为官方文档的翻译加个人理解.作者翻译时,elasticsearch(下面简称es)的版本为1.2.1. 1.系统级别及设置方面 1.1 es启动时,默认是作为一个前台程序启动.如果你想让e ...
- poj 3522 Slim Span (最小生成树kruskal)
http://poj.org/problem?id=3522 Slim Span Time Limit: 5000MS Memory Limit: 65536K Total Submissions ...
- AirDrop显示名字的修改问题
AirDrop的名字来源是设备登陆的iCloud账户 打开iCloud设置 把个人信息的名字改成自己的即可 前提是你的账号没有借朋友用过,如果朋友用过恰好没注销,你的通讯录又有你的朋友的号码,很有可能 ...
- 搭建 Android 开发环境,初试HelloWorld (win7) (下) (转)
5. 创建AVD 为使Android应用程序可以在模拟器上运行,必须创建AVD. 在Eclipse菜单中,选择 Windows -> Android Virtual Device Manage ...
- C: 数组形参
知识这个东西,真是知道的越多就不知道的越多,C/C++这塘水得多深啊,哈哈.看下面3个片段:<一> 1 void fun(char a[100]) { 2 fprintf( ...
- BindingFlags说明
为了获取返回值,必须指定 BindingFlags.Instance 或 BindingFlags.Static. 指定 BindingFlags.Public 可在搜索中包含公共成员. 指定 Bin ...
- 安装Redis完整过程
概述 首先报告一下我系统的版本: [root@firefish init.d]# cat /etc/issue 系统版本信息如下: 引用 CentOS release 6.4 (Final) K ...