一个sql语句,怎么这么慢

chencliff 发布于 2011/08/02 10:01
阅读 601
收藏 1

我的程序最近经常出现错误:Lock wait timeout exceeded; try restarting transaction

查看了一下mysql的慢日志,发现一个sql语句老出现:

# Time: 110801 22:24:52
# User@Host: chen[chen] @ localhost [127.0.0.1]
# Query_time: 121  Lock_time: 0  Rows_sent: 0  Rows_examined: 0
update user set place=440003,lastlogin='2011-08-01 22:21:17',lastend ='2011-08-01 22:22:51',toltime=183,msgchannel='1111111111' where id= 1005 LIMIT 1;

这个语句在用户下线的时候执行,记录上下线的时间等信息,user表一共38个字段。诡异的是并不是所有执行的这个语句都需要这么长时间....

place是samllint,lastlogin和lastend都是datetime,tottime是int,msgchannel是varchar,id是主键。好像没什么问题吧。。。。。

以下是问题补充:

@chencliff:还有,Lock wait timeout出现后,后面紧接着会连续出现相同的错误(包括操作其他表的时候)。在mysql中把等待的那个连接直接关闭后恢复正常。 (2011/08/02 10:03)
@chencliff:user是innodb的,数据库很小,大约12000行左右。 (2011/08/02 12:25)
@chencliff:user表只有一个id主键,没有索引 (2011/08/02 12:30)
加载中
1
恺哥
恺哥

对表做写操作的时候,会触发索引的重建,所以写多读少的表,建议少见索引;

建议你阅读一下mysql的锁机制

如果使用的是myisam引擎的话

当发起select时,会给表增加读锁,此时如果有一个用户下线的话,会触发写锁

写操作要等读操作ok后才能执行,所以如果读的时间过长的话,写就会等待

曾经看了一篇文章,上边描述的比较清楚,引用:

我们来运行一个时间很长的查询
1)、客户端1:

mysql> select count(*) from content group by content;
...
客户端2:
mysql> update content set content = 'I love you' where id = 444;
Query OK, 1 row affected (30.68 sec)
Rows matched: 1  Changed: 1  Warnings: 0

用了半分钟。
2)、我们现在终止客户端1。
此时客户端2:
mysql> update content set content = 'I hate you' where id = 444;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

仅仅用了20毫秒。

建议你还是修改实现方式,因为你目前的实现方式个人感觉不太妥当

0
恺哥
恺哥

该表的索引情况是怎样的?

该表的数据量有多大?

如果仅作上下线的log,为何不把这些字段从user剥离出来

而且上下线的log大多是写多,读少,所以建议在这种情况下尽量去掉索引

如果有统计的话,建议在单独建立以下统计表

另外,可以使用clickstream开源组件实现session的追踪,也很有效

0
红薯
红薯
这是锁的问题哦,应该是有更新同一条记录导致的吧
0
恺哥
恺哥

user表的存储引擎是什么?

0
chencliff
chencliff

引用来自“恺哥”的答案

该表的索引情况是怎样的?

该表的数据量有多大?

如果仅作上下线的log,为何不把这些字段从user剥离出来

而且上下线的log大多是写多,读少,所以建议在这种情况下尽量去掉索引

如果有统计的话,建议在单独建立以下统计表

另外,可以使用clickstream开源组件实现session的追踪,也很有效

恩,单独建立log表是个想法。单不设索引的话,更新的时候是不是不好找更新的行。
0
chencliff
chencliff

引用来自“红薯”的答案

这是锁的问题哦,应该是有更新同一条记录导致的吧
我觉得不会同时这么多更新,一个用户最多有两个线程操作,这么超时了呢?
0
fmxzhou
fmxzhou
这个很有帮助,看了,谢谢了
0
返回顶部
顶部