在使用 tcpdump 和 Maatkit 工具审计我们的数据库上运行的查询时，排名第一的查询是
RESET [int]
从 MySQL 命令行运行此语句会导致错误，因为 RESET 只应接受参数 master、query cache 和 slave。
我们的代码库中不存在此语句。我们确实运行了 MySQL Enterprise Monitor，但报告的用户不是我们的监控用户。我们还使用带有 mysqli 连接驱动程序的 Zend 框架，但未找到对此语句的任何调用。
您知道这可能是什么吗？
答案1
我怀疑这是 mk-query-digest 误解了 TCP 流量。由于数据包乱序、数据包丢失、重传等原因，作为旁观者重建流量从来都不是一门精确的科学。当 mk-query-digest 看到的内容中存在大量错误时，它有时会以虚假的方式解释流量，并似乎找到了可能不存在的东西。
我建议手动深入研究 tcpdump 输出。这很繁琐，而且协议很难手动解码，但如果您将一些数据转储到文件中，然后对其进行 mk-query-digest，mk-query-digest 将告诉您在文件中它找到打印出来的样本查询的字节偏移量。这应该可以让您缩小到一个数据包，并且使用 MySQL 内部手册中的协议文档，您应该能够查看该数据包是否真的是所谓的 RESET。我相信 RESET 可能与二进制（准备好的语句）协议有关，如果它是真实的；如果它是伪造的，我就猜不到了。
答案2
您使用的是 tcpdump，因此您可以通过查找该数据包来自哪个工作站来缩小范围。如果是所有工作站，那么您的假设就有问题。
答案3
如果您使用 tcpdump 观察它，您应该能够知道登录的用户和源端口。前者使您能够逐个更改凭据，直到有问题的查询更改它们使用的登录名，此时您将知道它们的来源。源端口让您知道远程 UID 是否为零（如果源端口小于 1024），并且它还使您能够使用netstat -ntp(*nix) 或netstat -nto(Windows) 来确定哪个 PID 实际生成了查询。