【问题标题】:Mysql Lock times in slow query log慢查询日志中的Mysql锁定时间
【发布时间】:2011-11-15 23:39:11
【问题描述】:

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

所以我的问题是:什么情况会导致 select 语句必须等待锁定(从而在慢查询日志中报告)?假设 INNODB 和 MISAM 环境。

可以将磁盘交互列为某种锁定时间吗?如果是,是否有相关文档说明了这一点?

提前致谢。

【问题讨论】:

    标签: mysql locking mysql-slow-query-log


    【解决方案1】:

    MyISAM 会给你带来并发问题,在插入过程中整个表被完全锁定。

    InnoDB 在读取方面应该没有问题,即使由于它是 MVCC,在写入/事务正在进行时也是如此。

    但是,仅仅因为查询显示在慢查询日志中并不意味着查询很慢 - 需要检查多少秒、多少条记录?

    将“EXPLAIN”放在查询前面,以获得查询正在进行的检查的细目。

    here's a good resource 用于了解 EXPLAIN(在优秀的 MySQL 文档之外)

    【讨论】:

    • 这对我来说太愚蠢了..我认为这是一个教科书问题。我忘记了表在更新期间完全锁定。有很多微小的更新不断发生。这些时髦的慢查询本质上会导致交通堵塞,而不断的更新确保它永远不会停止。
    【解决方案2】:

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

    网络上某个地方的某个人实际上编写了几个脚本来证明会发生这种情况,我尝试了一次,只花了几秒钟就出现了副本。当然,他设计脚本的方式会使其更有可能发生,但这证明它绝对可以发生。

    如果您的数据不需要准确并且肯定有助于防止死锁,这是可以的行为。但是,如果您正在开发一个处理诸如人们的钱之类的应用程序,那就非常糟糕了。

    在 SQL Server 中,您可以使用 WITH NOLOCK 提示告诉您的选择语句忽略锁。我不确定 MySql 中的等价物是什么,但也许这里的其他人会说。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-10-19
      • 1970-01-01
      • 2012-06-01
      • 1970-01-01
      • 2017-04-27
      • 2010-10-09
      相关资源
      最近更新 更多