MySQL单引号引起的严重性能问题

最近在工作中遇到一个MySQL update的严重性能问题，语句大概是这样的:

update t_user set fstate=0 where fuid in (11111, 22222, ....,  .....)

in后的括号中，有1000个fuid的样子

表结构如下：

存储引擎是Innodb, 版本是MySQL 4.0.18

其中fuid是主键, 由于表数据量在300W左右，所以刚开始更新很慢，我以为是表数据量太大引起的性能问题，

起初一直在寻求优化MySQL数据库配置，结果都是浮云，语句还是那么的慢。

偶然期发现自己用的是varchar字段类型，但却在赋值时没有加单引号：

对于varchar或者char字段里，如果只放数字类型的字符串，可以不加单引号执行SQL语句，不报错：

例如：

正常的写法是：

select  * from t_user where fuid='11111';

但你可以写这样写：

select  * from t_user where fuid=11111;

这条语句完全可以正常执行，但是表数据量很大的时候速度很慢。

但如果这样写：

select * from t_user where fuid=abcdef;

SQL执行时会报错，于是用explain分析：

在未加单引号时：

加入单引号时：

执行计划里type说明了问题所在，不加单引号的会造成全表扫描，所以表数据量越大速度越慢，找出了问题所在，

给原来的update语句加上了单引号，在300W数量级的表中，速度快了200倍的样子。

我在最新版本的MySQL 5.1里也实验过，同样有这个问题，百思不得其解，为什么MySQL在检查到where后查询条件

字段是varchar，不强制限制赋值必须用单引号，字母的可以检测到，但数字就不会。

MySQL为什么这样做：

原因是mysql不是把你的数字转成了字符串，而是把每个查询到的结果转成了数字去比较：

http://dev.mysql.com/doc/refman/5.0/en/how-to-avoid-table-scan.html

You are comparing indexed columns with constant values and MySQL has calculated (based on the index tree) that the constants cover too large a part of the table and that a table scan would be faster. See Section 7.3.1.2, “WHERE Clause Optimization”.