前段时间发生了一个mysql数据库查询数据的BUG,一个多表关联 的sql没有查询出来数据（实际数据库数据是存在），查找了很长时间，也不知道什么原因导致的，狠毒啊，来看看下面执行过程及结果，看图：
图1的 sql和图2的sql的结果是有交集的，但执行图3的sql时，结果显示为空，有毒啊。继续做下一个测试：
看到图4的执行结果，是不是觉得很神奇，去掉 test3表关联就能查询到数据，大家可以觉得 test3这个表的数据有毒，接下来我们继续看看 test3的数据情况：
看到这样的结果，大家是不是打消这个念头了，再进一步测试一下：
图5的执行结果也是能查询到数据，这也怀疑到了test1表的问题了，这样有了两个嫌疑人出现了，上面所有的图表结果都可以证明数据应该是没有问题的，接下去我们去查看一下他们的数据结构来看看有没有线所可寻，
看结构所有表的字符集都是 utf8mb4,collate 校准规则（也称排序规则） uftmb4_bin,这样规则的含义暂时就不详说了，知道是区别大小的就可以了（下篇再介绍字符集和排序规则知识）。上面唯一有区别是 test3中的OBJECT_ID是 utf8mb4_general_ci:是不区分大小写的，如果相关的条件有大小写的情况是可以解释的通，但是相同的结果中"0878e074ccdb405bb1a2a3c90c2a7955"并没有大小字符，事实就是只这个唯一的区别，试着把它们的校准规则调整一致。
修改这个 test3的结构还是查询不到结果，罪魁祸首原来是 copy表，于时就将 copy表调整下：
看到这个结果一脸？？？？？，我不接受这个结局！！！为了证明这个说不通的结果，重新构建了一个相同结构数据库和表数据，用同样的 sql查询数据，竟然是可以查询出来的结果的，这个结果虽然与上面不一样，但还是符合我的预期的，这原理规则才能说得通。问题虽解决了，凶手还是没有抓获很是苦恼，测试了好几天都无法在其的库还原这个问题，也使用了原数据库中复制数据表到原库中也无法还原这个问题。自建库测试结果：
今天突然想起了一个事情，同事都是使用 navicat客户端操作，听说这个客户端工具经常会出一起问题，数据库中还有一个实例是从问题库复制过来的，也有这种问题。我咨询了这位同事复制时使用的工具也是navicat，确认之后用navicat继续做测试：
测试navicat复制表几次就都是查询不到结果，使用sqlyog复制数据就可以，最可以证实这个了最后凶手就是 navicat导致的，虽然是它造成的，但是我自己不一小心给了它一个有机可趁的机会，建库建表字符集，排序规则一定要保持一致，切记！！！（下期学习下字符集，排序规则）
