我见过很多慢速查询日志,但从来没有像这样的:
/usr/sbin/mysqld, Version: 5.1.46-log (SUSE MySQL RPM). started with:
Tcp port: 3306 Unix socket: /var/run/mysql/mysql.sock
Time Id Command Argument
# Time: 160627 9:10:05
# User@Host: sysop[sysop] @ [127.0.0.1]
# Query_time: 3.768728 Lock_time: 0.034402 Rows_sent: 734 Rows_examined: 734
use asterisk;
SET timestamp=1467033005;
select PostID, lead_id, list_id from vdlist_temp where Posted is null;
# Time: 160627 10:35:11
# User@Host: sysop[sysop] @ [192.168.0.248]
# Query_time: 35.563521 Lock_time: 0.000054 Rows_sent: 1222017 Rows_examined: 2444034
SET timestamp=1467038111;
SELECT `vicidial_list`.`lead_id`, `vicidial_list`.`source_id` FROM `vicidial_list` ORDER BY `vicidial_list`.`source_id`;
# User@Host: sysop[sysop] @ [127.0.0.1]
# Query_time: 0.000095 Lock_time: 18446744073699.406250 Rows_sent: 2 Rows_examined: 1
SET timestamp=1467038111;
call spUpdate_VDList_from_temp(0, 0, 1324903);
# Time: 160627 10:35:12
# User@Host: sysop[sysop] @ [127.0.0.1]
# Query_time: 0.000055 Lock_time: 18446744073699.359375 Rows_sent: 0 Rows_examined: 0
SET timestamp=1467038112;
call spMoveXDrop(10376163);
# Time: 160627 11:26:14
# User@Host: sysop[sysop] @ [127.0.0.1]
# Query_time: 0.000057 Lock_time: 18446744073697.218750 Rows_sent: 3 Rows_examined: 0
SET timestamp=1467041174;
call spUpdate_VDList_from_temp(10795520, 616062301, 1955758);
这似乎表明我有超过500,000年的查询等待锁。(存储过程是我写的,我还没那么老!)不知怎么的,我觉得那不对。这些都是MyISAM表。(这不是我的选择。)我做了一个mysqldump和恢复数据库,重新启动服务器,我仍然看到这样的锁时间。
谁能给我一个线索在哪里找这个问题?(服务器时间都很好。)编辑:这个MySql版本:5.1.46-log附带一个开源项目vicdial。很明显,Lock_time是一个bug。问题是,我正在查看缓慢的查询日志,以跟踪用户对web服务器响应缓慢的投诉。我希望有人能知道是什么触发了这个错误,以帮助我找到实际的问题。从日志中可以看到,大多数慢速查询具有相同的Lock_times。存储过程和PHP生成的查询都会产生疯狂的Lock_time。我看到的唯一共同点是它们都从表vicdial_list中选择或更新。
有时候时间好像倒着走。这个问题已经存在了十多年。它似乎是无害的。
请注意,如果-1
存储在BIGINT UNSIGNED
中,您将获得与您所看到的18446744073699.406250
非常相似的值。
这些查询不是stock vicdial的一部分,所以我可能会建议对那些您正在尝试运行的自定义查询进行一些查询优化。此外,在我们的VICIbox ISO安装程序的最新版本中,我们使用了MariaDB,以及一个更新的版本,与您正在使用的旧版本MySQL相比,它有很多错误修复和优化。