了解mysql.log的输出

我已启用mysql查询日志以了解我的django应用程序中一些mysql查询的流程。我的日志文件的一个流输出类似于下面，那里是因为手动调试我在步骤中引入的延迟：了解mysql.log的输出

160111 17:58:43 131 Connect [email protected] 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 [email protected] 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具体，我在这里失踪？

来源

2016-01-11 mu 無

情况下产生的，我不知道这是正确的，但我敢肯定，这涉及到'LogEntry'细节，如果他们显示在顺序相同的[文档】（https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#logentry-objects）然后其'日期/ time'（正确），接着谁执行的用户它......（至少，一个LogEntry的init方法可能是一个断点的好地方！） – Sayse

@Sayse这是一个有趣的想法。我粘贴的日志是API访问期间的响应，与用户相同。 –

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

它看起来最有可能的是，131/132是对象ID

片断砍倒版本

160111 17:58:43 131 Connect [email protected] 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 [email protected] on database 
      # Perform queries with 132

你的第二个查询也遵循这个模式，就好像它的一些初步的行动出现最初的父对象的id为131，但是您查找132的外键以执行更多操作。

我想它看起来是增量式的，因为它最有可能的是fk对象是在它的父对象的同一时间创建的，但fk表中还有一个额外的条目。如果

这些日志上面是正确的为LogEntry

来源

2016-01-11 13:27:40 Sayse

了解mysql.log的输出

回答

相关问题