这是一个严重bug不？

我们先来仔细看上面这个图，4个sql的where条件完全一样，两个表关联，有两个sql有结果，两个sql...





我们先来仔细看上面 这个图，4个sql的where条件完全一样，两个表关联，有两个sql有结果 ，两个sql没有结果 。

按道理，应该是没有结果的.  所以，看来是严重的bug --------原因是使用了聚合函数min() 造成的 ？

其实，上面的实验，是作者搜了一下官方的bug 表，然后发现了下面 这个 bug 号 。bug号73946，截图如下



看标题相当吃惊，以为在没有结果集的情况下使用聚合函数，就会出现错误的结果。所以想自行验证一下。完整的测试过程如下：

mysql> create table  parenttab(parent_id int auto_increment primary key , parent_field varchar(200));

Query OK, 0 rows affected (0.06 sec)

mysql> create table  childtab(child_id int auto_increment primary key , parent_id int,  child_field varchar(200));

Query OK, 0 rows affected (0.21 sec)

mysql> insert into parenttab(parent_field)  values('aaaa');

Query OK, 1 row affected (0.02 sec)

mysql> insert into childtab(parent_id,child_field) values(1,'bbbb');

Query OK, 1 row affected (0.02 sec)

mysql> select  p.parent_id,min(c.child_field) from  parenttab  p  join  childtab c  where p.parent_id=1 and p.parent_id=c.parent_id and c.child_field='zzz';

+-----------+--------------------+

| parent_id | min(c.child_field) |

+-----------+--------------------+

|         1 | NULL               |

+-----------+--------------------+

如bug号73946上的表述， 出现了错误的结果集。

mysql> select  p.parent_id,c.child_field from  parenttab  p  join  childtab c  where p.parent_id=1 and p.parent_id=c.parent_id and c.child_field='zzz';

Empty set (0.01 sec)

上面这个sql,去掉聚合函数min(),则不出现结果。结果是正常的。

但仔细的看一下第一个sql, 对于使用聚合函数，标准的写法不是应该加个group by 莫？ 于是加上group by ,结果正常显示。

mysql> select  p.parent_id,min(c.child_field) from  parenttab  p  ,  childtab c  where p.parent_id=1 and p.parent_id=c.parent_id and c.child_field='zzz' group by p.parent_id;

Empty set (0.01 sec)

mysql> select  p.parent_id,min(c.child_field) from  parenttab  p  ,  childtab c  where p.parent_id=1 and p.parent_id=c.parent_id and c.child_field='zzz';

+-----------+--------------------+

| parent_id | min(c.child_field) |

+-----------+--------------------+

|         1 | NULL               |

+-----------+--------------------+

如上这种使用了聚合函数却不加group by ,   最后导致出现了结果错误，对于这个现象，个人觉得可以引用当下流行的一句话”no zuo no die " .

各位，你如何看待这个bug ?  官方把其标为s1级bug，看结果确实很严重，但是如果按照标准写sql,则可以避免。

看来为了安全起见，做啥事标准化，规规矩矩还是可以少很多麻烦。

历史文章

Mysql的JSON与SequoiaDB的比较

一个会导致Mysql crash 的半同步的bug

主键无序插入对性能的影响以及innodb buffer的效率指标分析

有一种主键重复冲突叫自增字段溢出

Mysql的表中含有Blob字段对性能的影响有几何？

又一个有趣的mysql死锁测试与源码分析

Mysql5.7 的错误日志中最常见的note级别日志解释

pt-table-checksum检查mysql5.7主从一致性的小bug.

mysql5.6与mysql5.7的半同步对比测试

mysql性能分析

mysql再一个有趣的死锁现象--删除空行导致

Xtrabackup 是否支持mysql 5.7 ?

又一个有趣的mysql死锁测试与源码分析

Mysql的meta data lock 源码分析-初篇

mysql的purge线程知多少

replace into与insert into ...on duplicate key update的区别以及陷阱

在MYSQL中通过唯一性索引删除同一条纪录出现死锁的分析与总结

MySQL5.7事务提交过程以及无损复制源码解析

Mysql5.7半同步复制源码解析-last

从一个调试结果来看mysql5.7的无损复制

    关注 数据库随笔