缓慢查询日志中的Mysql锁定时间

我有一个运行良好的应用程序，但最近有两个项目已经开始在慢速查询日志中弹出。所有的查询都是复杂且丑陋的多连接可以使用重构的select语句。我相信它们都有斑点，意味着它们被写入磁盘。让我感到好奇的部分是为什么有些人有锁定时间与他们有关。没有任何查询具有由应用程序设置的任何特定锁定协议。据我所知，默认情况下，除非明确指定，否则您可以读锁。缓慢查询日志中的Mysql锁定时间

所以我的问题：什么情况下会导致选择语句不得不等待一个锁（从而在慢速查询日志中报告）？假设INNODB和MYISAM环境。

磁盘交互是否可以列为某种锁定时间？如果是，是否有文件说明了这一点？

在此先感谢。

来源

2011-11-15 cgr

的MyISAM会给你的并发性问题，当插入过程中整个表被完全锁定。

InnoDB的应该没有问题读取，甚至在写/事务正在进行中，由于它的MVCC。

然而，仅仅因为一个查询在慢速查询日志显示出来，并不意味着查询速度慢 - 多少秒，多少记录被检查？

戴上“解释”在查询前拿到考试查询正在进行的击穿。

here's a good resource用于了解EXPLAIN

来源

2011-11-16 00:27:25 thinice

这是愚蠢的me..i的（关于它的优秀MySQL文档之外）认为这是一本教科书的问题。我忘记了桌面在更新期间完全锁定。有很多微小的更新不断发生。这些时髦的慢速查询本质上导致了交通阻塞，并且不断的更新确保它永不放弃。 – cgr

我不确定MySql，但我知道在SQL Server中，select语句不会读取锁。这样做将允许您读取未提交的数据，并可能会看到重复记录或完全错过记录。原因是因为如果另一个进程正在写入表中，数据库引擎可能会决定是时候重新组织一些数据并将其转移到磁盘上。所以它会将您已经阅读的记录移动到最后，然后您再次看到它，或者从最后一个移动一个记录到更高的位置。

网络上有一个人实际上写了几个脚本来证明发生了这种情况，我试了一次，并且在重复出现之前只花了几秒钟。当然，他以一种更容易发生的方式来设计脚本，但它证明它肯定会发生。

这是好行为，如果您的数据不需要是准确的，并且肯定可以帮助防止死锁。但是，如果您正在处理类似人们的钱的应用程序，那就很糟糕了。

在SQL Server中，您可以使用WITH NOLOCK提示来告诉您的select语句忽略锁定。我不确定MySql中的等价物是什么，但也许有人会说。

来源

2011-11-15 23:47:20

缓慢查询日志中的Mysql锁定时间

回答

相关问题