? ? ? ?数据库为了保证SQL能够正常执行，总会提供一些友好性来满足那些看起来对的SQL正常执行，比如隐式类型转换的使用，万字不如code，来看个具体碰到的问题：

? ?首先创建表：

create table  CONVERT_SHOW 
(
   USER_ID              bigint(8),
   NAME                  varchar(8),
   OP_TIME              timestamp default CURRENT_TIMESTAMP
);

?插入模拟数据：

insert into CONVERT_SHOW(user_id,name)values(0,'cast');

业务前台需要查询表中的数据时一般使用的查询SQL：

?

select USER_ID,NAME,OP_TIME from CONVERT_SHOW where USER_ID= ?;

?

一般处理这样的参数，都会以'参数值'?来替换"?"，替换后的SQL可能是这样的：

select USER_ID,NAME,OP_TIME from CONVERT_SHOW where USER_ID= '查询参数';

?这时，隐藏的一个陷阱就可能出现：数据库为了SQL正常工作，会使用隐式类型转换使得参数变成bigint类型，如果传递的参数不是整数会出现什么样的情况？

? ? 看看MySQL的类型转换：

select cast('查询参数' as UNSIGNED ) ;

? ? 结果是：0

? ? 如果恰好表里存在一条user_id为0的数据，就会被返回，接着就是让人的各种着急，连在Google上使用那些关键字上来查找原因都比较难描述^_^

? ? ?如果前端能够做到对参数进行类型校验，肯定可以避免问题出现，但大多时候都是无心挖出来的坑，那真是满头的黑线啊！！！

? ??