关于MySQL隐式转换以及聚集函数问题
原本是因为一个小小的问题，所以想对数据库里的东西做个统计，看看有没有什么奇奇怪怪的数据，然后就是漏打了个单引号，发现了一个奇怪的现象。执行的SQL如下：
select vc_full_name from t_fund_company_info WHERE vc_full_name=0;
结果发现，哎，这怎么能查出数据库里所有的数据呢，而且这里边一个符合条件的结果都没有，是不是MySQL抽了。
所以去问了一下别人，原来是MySQL的隐式转换。
什么叫隐式转换？
就是说，当我们对不同类型的值进行比较的时候，为了使得这些数值「可比较」（也可以称为类型的兼容性)，MySQL会做一些隐式转化（Implicit type conversion）。
所以，上面那个语句，MySql在比较varchar类型和0的时候，会把varchar类型转换成数字0
当然MySQL也提供了这个cast（）函数，可以使用它来转换成相应的类型，就比如下面这个SQL：
select vc_full_name, cast(vc_full_name as SIGNED INTEGER) from t_fund_company_info;
结果如下：
那么，隐式转换有什么规则呢，规则如下：
1.如果一个或两个参数都是空的，比较的结果为null。null与null比较，结果为null，无需进行转换。
2.如果两个比较的两个参数都是string，按string比较，不做类型转换。
3.如果两个比较的两个参数都是integer，按integer比较，不做类型转换。
4.十六进制的值和非数字做比较时，会被当做二进制串来比较。
5.有一个参数是 TIMESTAMP 或 DATETIME，并且另外一个参数是常量，常量会被转换为 timestamp。
6.有一个参数是 decimal 类型，如果另外一个参数是 decimal 或者整数，会将整数转换为 decimal 后进行比较，如果另外一个参数是浮点数，则会把 decimal 转换为浮点数进行比较
7.所有其他情况下，两个参数都会被转换为浮点数再进行比较。
然后网上大家给出了一个需要注意的问题，就是：
假如password类型为字符串，查询条件为 int 0 则会匹配上。
然后我就去数据库操作了一下，发现有惊喜。
也就是说，这里是可以做SQL注入的。。如果网站登录模块做的比较挫的话。
所以说，为了防止在进行查询、更新或者删除操作的时候，多操作更多的数据，千万记得写SQL的时候加引号！
PS：最后冲哥还给出了一个重要结论， MySQL 隐式类型转换本身也是非常耗费 MySQL 服务器性能的，所以非常不推荐这样使用。
第二个事情，是聚集函数的问题。这个聚集函数，平时查数据库也会用很多。
本来只想查下库里一个文本字段，最大长度是多少。结果发现，这个里面的内容跟对应的长度不符合。按照往常的习惯，没多想，都是这样写的：
SELECT vc_fund_id,vc_fund_name,vc_Investment_field_txt,max(CHARACTER_LENGTH(vc_Investment_field_txt)) FROM t_fund_info;
但是TXT字段明显没有1305个字符。
后来才意识到，没有加group by。。
在《数据库系统概念》这本书中用如下的表述：
当SQL查询使用分组时，一个很重要的事情是需要保证出现在select语句中但是没有被聚集的属性只能是出现在group by子句中的那些属性，换句话说，任何没有出现在group by子句中的属性如果出现在select子句中的话，那么该属性只能出现在聚集函数的内部，否则，这样的查询就是错误的。
所以说，比如有这样一个表info，有如下字段：
id name num price
那么你这样查：
select * from info group by id;
select id,sum(price) from info where price >= 10;
select id,count(price) from info where price >= 10;
select id, count(*) as num_prods, price from info where price >= 10;
这些都是错的！
第一个语句当中，这个查询按照id分组，然而select子句中的代表info中的所有属性，更进一步的，除了id之外，该表的其他属性都未出现在group by子句中。所以是错的。
余下两个也是一样的。
最关键是，即使你这样写，MySQL也不会报错。。。但是结果却让你很困惑。。
大概所有数据库都存在这种问题吧，像oracle、SQLserver等。
