☰

为什么在慢查询日志中设置时间戳？

tag-icon • tag-icon mysql5
为什么在慢查询日志中设置时间戳？

我使用 mysql Ver 14.12 Distrib 5.0.86，对于 unknown-linux-gnu (x86_64) 使用 readline 5.1，我在慢查询日志中看到以下查询：

# Time: 110907  7:00:09
# User@Host: XXX[XXX] @  [10.1.10.1]
# Query_time: 3  Lock_time: 0  Rows_sent: 1  Rows_examined: 347519
SET timestamp=1315378809;
# administrator command: Quit;

# User@Host: XXX[XXX] @  [10.1.10.1]
# Query_time: 3  Lock_time: 0  Rows_sent: 0  Rows_examined: 0
use XXX;
SET timestamp=1315378809;
# administrator command: Quit;

# User@Host: XXX[XXX] @  [10.1.10.1]
# Query_time: 3  Lock_time: 0  Rows_sent: 1  Rows_examined: 1
use XXX;
SET timestamp=1315378809;
# administrator command: Quit;

它位于一个主服务器上，并附有一个从服务器。

为什么在慢查询日志中设置时间戳？ 有人能帮帮我吗？

答案1

为什么在慢查询日志中设置时间戳？

因为它用于检查如果查询应该记录为缓慢。

有人可能会认为可以使用 MySQL 慢查询日志来记录所有慢查询，以捕获有问题的查询或用于审计目的。但事实上，并非所有查询都会被记录。我已经提到过，mysql 从属查询不会记录到慢查询日志中，看来我将其与复制联系起来是错误的。

事实上，线程是复制线程并不是导致查询从慢查询日志中被忽略的原因，而是因为线程使用了 SET TIMESTAMP 功能。如果您在正常连接中执行此操作，结果将是相同的。

为什么会发生这种情况？我猜是因为代码的结构。在查询启动期间，当前时间戳被存储为特殊值，该值将由所有 NOW() 调用内部时间戳分配等用于查询执行。在某个时候，有人认为能够回到未来或过去是个好主意，于是实现了 SET TIMESTAMP，它不是修补一堆函数，而是简单地将不同的时间戳写入此变量。当查询执行完成时，通常使用另一个 time() 来获取当前时间，并使用开始时间和结束时间之间的时间差来检查是否应将查询记录为慢查询。如果开始时间可以是将来或过去，这显然不起作用，因此必须对此类查询禁用慢查询日志记录。

这是什么意思？简单来说，您不能真正信任标准慢查询日志——其中可能会省略一些查询。此外，如果有人想对您隐藏复杂查询，可以在运行查询之前使用 SET TIMESTAMP 语句轻松实现。

相关内容