不寻常的MySQL表锁定问题

我们都知道InnoDB更新是行锁定，MyISAM更新是表锁定，但您如何解释这一点？下面是当问题出现的时候显示完整进程列表的结果：

╔═════════╦════════╦═════════╦════════════════════════════════╗
║ Command ║ Time   ║ State   ║ Info                           ║
╠═════════╬════════╬═════════╬════════════════════════════════╣
║ Query   ║ 0      ║ NULL    ║ SHOW FULL PROCESSLIST          ║
║ Query   ║ 121    ║ end     ║ UPDATE [InnoDB table]          ║
║ Query   ║ 121    ║ update  ║ INSERT INTO [MyISAM table]     ║
║ Query   ║ 121    ║ Locked  ║ INSERT INTO [MyISAM table]     ║
║ Query   ║ 120    ║ Locked  ║ INSERT INTO [MyISAM table]     ║
║ Query   ║ 120    ║ Locked  ║ INSERT INTO [MyISAM table]     ║
╚═════════╩════════╩═════════╩════════════════════════════════╝

为了节省空间，我省略了一些列。以上所有内容都发生在一个数据库中，并引用一个InnoDB表和一个MyISAM表。下面还有很多类似于底部三行的行，但我还是忽略了它们

问题是由InnoDB表上的更新引起的，该更新似乎锁定了MyISAM表。数据库作为一个整体没有被锁定，因为每秒都有数百个SELECT查询发生，而且它们没有被卡住。请注意，第一次插入的状态是“更新”，这可能是导致后续插入被锁定的原因，但这就引出了一个问题：什么是插入更新？自动增量？表索引？大概但是为什么这样的更新会被另一个表的更新所阻止呢？请参见此处，了解各州含义的详细信息：

以下是我到目前为止得出的结论：

• 查询没有问题-更新被适当地索引，插入和更新查询通常都需要<100毫秒的时间来执行，但是正如您所看到的，这一次需要2分钟以上
• 几乎所有在数据库上执行的查询都是选择和插入-更新是例外
• 肯定是更新导致了问题，因为它是半可复制的——如果我执行类似的查询，有时它会重新创建问题，有时它会像正常情况一样快速执行
• 似乎只有这个特定的InnoDB表有问题，因为数据库中的其他InnoDB表更新没有问题，但它是最大的—它包含约100万行，大小约为40 MB
• 更新是在多个服务器上复制的，但长时间的执行似乎只发生在负载较大的服务器上
• 当问题发生时，我已经检查了服务器上的CPU负载和空闲RAM，它们都很好

服务器规格：

• Debian挤压
• MySQL 5.1
• 8芯
• 32 GB内存

在您提问之前，以下是一些[mysqld]配置设置：

skip-external-locking
innodb_file_per_table
innodb_flush_method     = O_DIRECT
innodb_buffer_pool_size = 512M
key_buffer              = 1500M
read_rnd_buffer_size    = 512k
table_open_cache        = 4096
tmp_table_size          = 256M
max_heap_table_size     = 256M
concurrent_insert       = 2
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
max_connections         = 2000
open_files_limit        = 60000
query_cache_limit       = 1M
query_cache_size        = 512M

在大量的谷歌搜索之后，我仍然不知所措，所以任何帮助都将得到感激

增加

为InnoDB表创建语法：

CREATE TABLE `tablename` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `column1` bigint(20) unsigned NOT NULL,
  `column2` int(10) unsigned NOT NULL,
  `column3` int(10) unsigned NOT NULL,
  `column4` int(10) unsigned NOT NULL,
  `column5` int(10) unsigned DEFAULT NULL,
  `column6` enum('yes','no') NOT NULL DEFAULT 'no',
  PRIMARY KEY (`id`),
  UNIQUE KEY (`column1`),
  KEY (`column2`),
  KEY (`column5`)
) ENGINE=InnoDB AUTO_INCREMENT=993266 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;

---

因为你的状态是“结束”。这些事情可能发生

对于结束状态，以下操作可能根据发生：

◾ 更改表中的数据后删除查询缓存项

◾ 将事件写入二进制日志

◾ 释放内存缓冲区，包括Blob

---

我建议禁用查询缓存或将其设置为较小的大小。现在它与整个缓冲池一样大。

更新是在事务中还是在纯更新语句中？您的自动提交设置是什么？您还应该显著增加innodb\u buffer\u pool\u大小。如果所有查询都使用相同的连接，这可能就是问题所在。由于每个查询必须在连接接受新查询之前完成…@KayNelson更新是“纯”的，即不在事务中。自动提交默认为so 1。所有查询都使用不同的连接。我可以增加缓冲池大小，但InnoDB的总数据大小约为70 MB，因此似乎没有太大意义-除非您知道其他情况？请您将表def和更新语法放在这里好吗？谢谢，听起来似乎有道理-我会尝试一下。由于某种原因，我错过了上面的信息，因为它处于“init”状态而不是“end”状态@Philip，有什么进展吗？我已经实现了解决方案，但我要等一两周才能确认问题已经解决。@Philip cool，你是完全禁用了还是降低了缓存的大小？祝你好运，我希望它能解决你的问题！我决定完全禁用它，因为在执行的SELECT查询中几乎没有重复，它们都是v。快速且只返回一个字段。不是DBA，我以前没想过！