Question

我启用了mysql查询日志，以了解我的django应用程序中的一些mysql查询的流程。我的一个流的日志文件的输出如下所示，由于我在步骤中引入了手动调试器，因此存在延迟：

160111 17:58:43   131 Connect   root@localhost on database
          131 Query SET NAMES utf8
          131 Query set autocommit=0
          131 Query set autocommit=1
          131 Query SET SQL_AUTO_IS_NULL = 0
          131 Query SELECT foo FROM bar WHERE condition_X
          132 Connect   root@localhost on database
          132 Query SET storage_engine=INNODB
          132 Query SET NAMES utf8
          132 Query set autocommit=0
          132 Query set autocommit=1
          132 Query SET SQL_AUTO_IS_NULL = 0
          132 Query set autocommit=0

160111 17:59:15   131 Query SELECT baz FROM bazbaz WHERE condition_Y
          131 Query SELECT baz FROM bazbaz WHERE condition_Y
          132 Query set autocommit=1
          132 Query set autocommit=0
          132 Query UPDATE bar SET foo = "something" WHERE condition_X
          132 Query commit
          132 Query set autocommit=1

我能弄清楚的是，数字131和132意味着什么 - 它看起来像是相关的，但为什么没有订单就将它写入日志中，即使存在足够的差距声明之间？有什么django具体我在这里失踪吗？

Answer 1

移动我的评论以消除噪音，并希望解释我的想法。

131/132很可能是对象ID

减少片段版本

160111 17:58:43   131 Connect   root@localhost on database
          # Perform some queries with object 131
          131 Query SELECT foo FROM bar WHERE condition_X 

          # You have now selected a new object so use that id (132)
          132 Connect   root@localhost on database
          # Perform queries with 132

您的第二个查询也遵循此模式，它看起来好像它对id为131的初始父对象执行了一些初始操作，但随后您查找132的外键以执行更多操作。

我认为它看起来是增量的，因为它很可能是fk对象与其父对象同时创建的，但fk表中还有一个额外的条目。

如果上述内容正确，则会生成这些日志作为LogEntry

的实例

了解mysql.log的输出

1 个答案: