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

时间：2022-09-20 10:29:53
像这样：
# Query_time: 1.310542  Lock_time: 0.000000 Rows_sent: 0  Rows_examined: 0
use data_xxx;
SET timestamp=1441008434;
commit;

9 个解决方案

#1

你的慢查询时间是多久？应该是1s吧，好像是提交耗费时间。
你是一下子提交还是一条条提交

#2

该回复于2015-09-02 12:57:18被版主删除

#3

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

#4


这是我机器上的慢日志： 

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;

#5


另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来

#6


我觉得，楼主可以修改一下参数设置，我的是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>

#7

引用 5 楼 yupeigu 的回复:
另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来



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

#8

引用 7 楼 mchdba 的回复:
Quote: 引用 5 楼 yupeigu 的回复:


另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来



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


我这里主要是查询较多，数据量较大，一般只要在3分钟以内就可以了。

之前帮同时看语句，查询大概10条数据，大涉及到多表关联和复杂的条件，原来大概1秒多，后来降到0.006秒，oracle的cost从3099降到136.

所以，你说的对，不同应用领域要求会不一样，但实际上 只要是返回少量数据，查询速度应该就能优化到极快的程度，如果是数据量较大几千，几万，也可以优化，但可能不会优化到1秒的程度。

#9

引用 8 楼 yupeigu 的回复:
Quote: 引用 7 楼 mchdba 的回复:

Quote: 引用 5 楼 yupeigu 的回复:


另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来



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


我这里主要是查询较多，数据量较大，一般只要在3分钟以内就可以了。

之前帮同时看语句，查询大概10条数据，大涉及到多表关联和复杂的条件，原来大概1秒多，后来降到0.006秒，oracle的cost从3099降到136.

所以，你说的对，不同应用领域要求会不一样，但实际上 只要是返回少量数据，查询速度应该就能优化到极快的程度，如果是数据量较大几千，几万，也可以优化，但可能不会优化到1秒的程度。

是的，不同的应用环境，不同的需求方式，没有一定的准则

#1

你的慢查询时间是多久？应该是1s吧，好像是提交耗费时间。
你是一下子提交还是一条条提交

#2

该回复于2015-09-02 12:57:18被版主删除

#3

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

#4


这是我机器上的慢日志： 

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;

#5


另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来

#6


我觉得，楼主可以修改一下参数设置，我的是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>

#7

引用 5 楼 yupeigu 的回复:
另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来



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

#8

引用 7 楼 mchdba 的回复:
Quote: 引用 5 楼 yupeigu 的回复:


另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来



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


我这里主要是查询较多，数据量较大，一般只要在3分钟以内就可以了。

之前帮同时看语句，查询大概10条数据，大涉及到多表关联和复杂的条件，原来大概1秒多，后来降到0.006秒，oracle的cost从3099降到136.

所以，你说的对，不同应用领域要求会不一样，但实际上 只要是返回少量数据，查询速度应该就能优化到极快的程度，如果是数据量较大几千，几万，也可以优化，但可能不会优化到1秒的程度。

#9

引用 8 楼 yupeigu 的回复:
Quote: 引用 7 楼 mchdba 的回复:

Quote: 引用 5 楼 yupeigu 的回复:


另外，我看你的 # Query_time: 1.310542 

也就是，你设置的 long_query_time 可能是1秒，这个有必要吗？

如果你运行了好多语句，虽然每条数据都很快，但是在最后commit的时候，由于是大批量数据的提交，就会导致commit很慢，就会被记录下来



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


我这里主要是查询较多，数据量较大，一般只要在3分钟以内就可以了。

之前帮同时看语句，查询大概10条数据，大涉及到多表关联和复杂的条件，原来大概1秒多，后来降到0.006秒，oracle的cost从3099降到136.

所以，你说的对，不同应用领域要求会不一样，但实际上 只要是返回少量数据，查询速度应该就能优化到极快的程度，如果是数据量较大几千，几万，也可以优化，但可能不会优化到1秒的程度。

是的，不同的应用环境，不同的需求方式，没有一定的准则
标签：

相关文章