当管理的MySQL主机越来越多的时候，遇到Bug的可能性也就越来越大了。基本上，每隔一段时间，我们都会遇到一个Bug或者版本兼容问题。有些Bug已经修复（Bug #44571），有些Bug无法重现或者修复（Bug #39168）。即使Bug能够重现，我们也不能期待MySQL/Innobase能够多快的给出Patch，他们没有这个义务，我们也没有权利要求。

如何处理Bug？

尝试到找Bug重现的场景，确定他是一个Bug，而不是一个Mistake。一般遇到Bug，都能在MySQL Bug找到线索，如果能够确定是Bug，可以看看新的版本是不是已经修复，如果修复则可以考虑升级小版本号。对于更高的小版本号，我们有如下假设（或者认为）

• 更高的小版本号解决了更多Bug；
• 如果更高的小版本有新特性，那么意味着新特性可能带来更多的Bug；
• 更高的小版本，仍然会有和老版本不兼容的地方；
• 更高的小版本，有很cool的新特性；
• 一般，小版本的升级不会影响应用。

所以，一般遇到Bug，新的小版本如果有修复，我们将优先考虑升级小版本号。

另外，找到Bug重现的场景，还可以考虑绕过Bug（workaround），让自己的应用或者DDL尽量避免Bug出现。有时候，新版本新特性会带来一些Bug，不得以我们还可以考虑降级版本，虽然这是不推荐的做法，因为这样的可能陷入死循环。

Bug？Debug！

纵然，Innobase/MySQL AB已经被Oracle收购，MySQL的源代码仍然受到GPL的保护，所以我们仍然能够获得源代码，这就意味着我们自己Debug也成为可能。很多做开源方案的团队、公司已经发布了很多Patch，一般是做性能提升或者功能增强，他们也在MySQL Bug上提交了很多Patch建议。

这里的另一个问题是，自己的团队是否可能去Debug、打补丁？一般地，如果能够找到源代码的Bug，将其提交到MySQL Bug上，等待更加理解整个架构的人去将代码Merge到源码树中，一般是比较靠谱的办法。这大概也是为什么，目前开源社区、团队产生的一般是性能提升或者功能增强补丁，而很少Debug补丁。