慢查询日志里大量只有“commit”，没有查询语句，怎么回事？？

Question

像这样：
# Query_time: 1.310542  Lock_time: 0.000000 Rows_sent: 0  Rows_examined: 0
use data_xxx;
SET timestamp=1441008434;
commit;

Answer 1

通过binlog找到commit的时候是对哪些DML语句commit的

Answer 2

这是我机器上的慢日志：C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqld.exe, Version: 5.6.25-log (MySQL Community Server (GPL)). started with:
TCP Port: 3306, Named Pipe: (null)
Time                 Id Command    Argument
# Time: 150825 15:57:07
# User@Host: root[root] @  [192.168.100.50]  Id:    62
# Query_time: 101.961779  Lock_time: 0.000000 Rows_sent: 0  Rows_examined: 6479872
use world;
SET timestamp=1440489427;
update tb set idd = id;
# Time: 150825 15:58:41
# User@Host: root[root] @  [192.168.100.50]  Id:    62
# Query_time: 48.266485  Lock_time: 0.000000 Rows_sent: 0  Rows_examined: 6479872
SET timestamp=1440489521;
update tb set idd = id;
# Time: 150825 16:00:00
# User@Host: root[root] @  [192.168.100.50]  Id:    62
# Query_time: 54.506496  Lock_time: 0.000000 Rows_sent: 0  Rows_examined: 6479872
SET timestamp=1440489600;
update tb set idd = id;
# Time: 150825 16:01:57
# User@Host: root[root] @  [192.168.100.50]  Id:    65
# Query_time: 38.110867  Lock_time: 0.000000 Rows_sent: 501  Rows_examined: 6479872
SET timestamp=1440489717;
select * from tb where idd >= 1000 and idd <= 1500;

Answer 3

另外，我看你的 # Query_time: 1.310542 也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来

Answer 4

我觉得，楼主可以修改一下参数设置，我的是mysql默认的是10秒，然后设置为3秒：mysql> show variables like '%long_query_time%';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.01 sec)mysql> set global long_query_time = 3;
Query OK, 0 rows affected (0.04 sec)mysql> select @@global.long_query_time;
+--------------------------+
| @@global.long_query_time |
+--------------------------+
|                 3.000000 |
+--------------------------+
1 row in set (0.02 sec)mysql>

Answer 5

不知道你的应用是什么行业，其实很有必要的，在互联网电商领域，long_query_time 这个值一般都是1秒，甚至为了查问题，优化首页，long_query_time 这个值还可以设置成0.3秒的。

Answer 6

不知道你的应用是什么行业，其实很有必要的，在互联网电商领域，long_query_time 这个值一般都是1秒，甚至为了查问题，优化首页，long_query_time 这个值还可以设置成0.3秒的。我这里主要是查询较多，数据量较大，一般只要在3分钟以内就可以了。之前帮同时看语句，查询大概10条数据，大涉及到多表关联和复杂的条件，原来大概1秒多，后来降到0.006秒，oracle的cost从3099降到136.所以，你说的对，不同应用领域要求会不一样，但实际上 只要是返回少量数据，查询速度应该就能优化到极快的程度，如果是数据量较大几千，几万，也可以优化，但可能不会优化到1秒的程度。

Answer 7

不知道你的应用是什么行业，其实很有必要的，在互联网电商领域，long_query_time 这个值一般都是1秒，甚至为了查问题，优化首页，long_query_time 这个值还可以设置成0.3秒的。我这里主要是查询较多，数据量较大，一般只要在3分钟以内就可以了。之前帮同时看语句，查询大概10条数据，大涉及到多表关联和复杂的条件，原来大概1秒多，后来降到0.006秒，oracle的cost从3099降到136.所以，你说的对，不同应用领域要求会不一样，但实际上 只要是返回少量数据，查询速度应该就能优化到极快的程度，如果是数据量较大几千，几万，也可以优化，但可能不会优化到1秒的程度。
是的，不同的应用环境，不同的需求方式，没有一定的准则