MySQL现行版本中存在一个count(distinct)语句返回结果错误的bug，表现为，实际结果存在值，但是用count(distinct)统计后返回的是0。

原因分析

　　Count(distinct f)的语义就是计算字段f的去重总数，计算流程大致如下：

　　流程一:

　　流程二：

1. 构造一个unique 集合A1 2、 插入item过程中若大小超过tmp_table_size，则将A1暂时写到文件中，再构造集合A2 3、 重复步骤2直到所有的item插入完成 因此若item很多则可能重复生成多个集合A1～An。 4、 对A1～An作合并操作。由于只是每个集合A保证unique，因此需要做类似归并排序的操作（实际上不需要排序，只是扫一遍） 5、 因此合并操作需要一个临时内存，长度为n，单元大小为key_length （key大小）。这个临时内存，用的也是tmp_table_size定义的大小。实际上在合并过程中还需要长为key_length的预留空间作临时内存保存。因此需要的空间为 (n+1)key_length。 6、 在进行合并前会判断tmp_table_size >=(n+1)key_length， 不满足则直接放弃合并。其结果就是返回为0。

案例分析

　　以上面这个case为例。字段v的单key大小为65 (65 = 322+1) 加上tree节点字占空间24字节共89字节。单个集合只能放11个item （1024/89）， 因此n为 24 （24>=256/11）, 在合并时需要 (24+1)65= 1625字节的临时空间，大于1024，放弃合并。

Sql_big_tables

解决方法

　　运维上，set sql_big_tables是一个方法，不过会影响性能。调高tmp_table_size算是正招。当然本质上这是一个bug。 　　代码上，对于已经走到合并操作的这个逻辑，如果tmp_table_size不够，应该直接申请新的临时空间用于合并，完成后释放。虽然会造成临时征用内存，不过以现有的逻辑来看，临时征用的内存已经不少了.

　　另外一种时间换空间的方法，就是作多次合并。

　　相比之下第一种改造比较简单安全。该bug在RDS MySQL 5.5 中已经修复。