Mysql数据库锁等待问题

topbasemaster 2016-04-23 10:26:27
在生产环境里面 这几天查到有两个查询语句 锁住,导致后面好多语句都waiting lock
有 insert into 有 update 也有select 的 waiting lock

Update xxx_table Set allmeter = allmeter + 5039 where shoe_id = 73854

select name,current_value,increment from sys_sequence where name = 'user_shoe' for update 获取seq

这两个语句导致之前查mysql锁住了,

问题1:
如何上面的sql语句有没有可以优化的地方?

问题2:
在业务 sql 语句编写里面 有些什么好的方法 避免锁的等待?
...全文
408 2 打赏 收藏 转发到动态 举报
写回复
用AI写文章
2 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
建议在shoe_id 上创建索引。 还有对name字段也创建索引。 一般来说,这种单个没有多表关联的sql是速度很快的。 阻塞一般是由于运行速度太慢,导致后面的一大堆sql都被阻塞了,所以通过上面的创建索引,应该可以加快查询速度,减少阻塞
gikod 2016-04-24
  • 打赏
  • 举报
回复
假定楼主的表是InnoDB的
引用 楼主 topbasemaster 的回复:
Update xxx_table Set allmeter = allmeter + 5039 where shoe_id = 73854
shoe_id是xxx_table的pk吧,那么这条语句产生的只是对于shoe_id = 73854的一个排他行锁(X模式)。这很轻。只要马上commit,没有持有等待就不会产生死锁。
引用 楼主 topbasemaster 的回复:
select name,current_value,increment from sys_sequence where name = 'user_shoe' for update 获取seq
这是用自己的表模拟auto_increment吧。这的确会产生持有等待,不过接下来想必是 update set seq = seq + 1 之类的操作,如果马上做完commit的话,应该也只是很短的顺序化。看不到和上面的语句冲突的地方。 另外,用自己的表,比用auto_increment要有更多开销。
引用 楼主 topbasemaster 的回复:
问题1: 如何上面的sql语句有没有可以优化的地方?
语句1没有什么特别的。 语句2如果能改用auto_increment会好很多,如果设计分布式的sequence,可以用radis或memcached,性能会好不少。 再进一步就是做业务逻辑上的调整了。
引用 楼主 topbasemaster 的回复:
问题2: 在业务 sql 语句编写里面 有些什么好的方法 避免锁的等待?
用乐观锁,使用timestamp或version number

56,675

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧