MySQL升级问题-分析通用查询日志的脚本

Question

当从MySQL 5.0.x转移到较新的版本(如5.1.x或5.5.x)时，主动发现向后兼容性问题的最佳方法是什么？这里有很多文档，比如关于从一个版本转移到另一个版本的官方指南和changelogs，但是有谁知道已经创建了哪些脚本来确定可能的问题呢？除了mysql_upgrade (但请参阅下面的说明)，我找不到一个。

听起来，使用mysql_upgrade可以在表中找到一些问题，但我不认为它会找到所有可能的问题(比如带有查询的问题)--例如，我们在过去遇到过一个问题，在这个问题中，我们有一个设置MySQL变量(max_allowed_packet)的查询。这以前是允许的，但是当我们从5.0.95升级到5.0.95时，这个查询开始失败，因为MySQL在5.0.84时将其更改为只读。

为了捕捉查询本身的兼容性问题，是否有什么可以分析来自一般查询日志的查询(假设这是打开一段时间来捕获查询)？最好在sysadmin方面尽可能多地进行全局识别，而不是让开发人员去寻找问题。即使遍历了所有的变更集和指南，仍然有一个步骤来查看哪些查询需要更改，如果脚本已经存在以减少手动/半手动检查，这将是非常理想的。

Answer 1

pt-升级可以在两个服务器上执行查询并比较结果。这是在主要版本迁移之前要执行的步骤之一