mysql - 什么会导致 InnoDB 表的单个 UPDATE 性能非常低？

Question

我的网络应用程序中有一个表用于存储 session 数据。它表现不佳，我不明白为什么。慢速查询日志显示更新一行需要 6 到 60 秒。

CREATE TABLE `sessions` (
    `id` char(40) COLLATE utf8_unicode_ci NOT NULL,
    `payload` text COLLATE utf8_unicode_ci NOT NULL,
    `last_activity` int(11) unsigned NOT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `session_id_unique` (`id`) USING HASH
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

PK 是一个 char(40)，它存储由该项目使用的框架 (Laravel) 生成的唯一 session 哈希。

(我知道 PK 和唯一索引的冗余，但我已经尝试了所有组合，并且它对我的测试性能没有任何影响。这是它的当前状态。)

表格很小 - 不到 200 行。

来自慢速查询日志的典型查询如下所示:

INSERT INTO sessions (id, payload, last_activity) 
VALUES ('d195825ddefbc606e9087546d1254e9be97147eb', 
        'YTo1OntzOjY6Il90b2tlbiI7czo0MDoi...around 700 chars...oiMCI7fX0=', 
        1405679480) 
ON DUPLICATE KEY UPDATE 
    payload=VALUES(payload), last_activity=VALUES(last_activity);

我做过很明显的事情，比如检查表格是否损坏。我试过添加一个专用的 PK 列作为自动增量 int，我试过没有 PK，没有唯一索引，将 text 列换成非常非常大 varchar，随你便。

我已经尝试将表切换为使用 MyISAM，但它仍然很慢。

我所做的一切似乎都没有任何区别 - 表格执行速度非常慢。

我的下一个想法是查询。这是由框架生成的，但如果失败，我已经测试过将其破解成带有 INSERT 的 UPDATE。 UPDATE 语句继续缓慢。

我读过很多关于慢速 INSERT 和 UPDATE 语句的问题，但这些问题通常与批量交易有关。这只是每个用户每个请求的一个插入/更新。该站点不是远程繁忙，它在自己的 VPS 上，资源丰富。

什么可能导致速度缓慢？

Answer 1

这不是答案，但 SE 评论长度太短了。所以。

如果您直接在命令行上运行相同的 INSERT ... ON DUPLICATE KEY UPDATE... 语句会发生什么情况？请在实际使用和不使用该应用程序的情况下进行尝试。应用程序可能人为地减慢了这个更新(例如，在 INNODB 中一个事务可能被打开，但是在消耗了很多时间之后提交。你也用不支持事务的 MyISAM 进行了测试。也许在那种情况下一个显式的 LOCK 可以占同样的效果。如果框架使用这个trick，我不确定，我不知道laravel)尝试进行基准测试，看看是否有并发效果。

另一个问题:这是单台服务器吗？或者它是复制到一个或多个从机的主机？

除了这个问题，还有一些观察:

• id 的值是十六进制字符串。该列是 unicode。这意味着 3*40 个字节被保留，而只有 40 个被使用。这是一种浪费，通常会使事情效率低下。使用 BINARY 或 ASCII 作为字符编码会好得多。更好的是，将 id 列更改为 BINARY 数据类型并存储(未十六进制的)二进制值
• innodb PK 表的散列将跨页面分散数据。使用 auto_incrment pk 或根本不显式声明 pk(这将导致 innodb 在内部创建它自己的自动增量 pk)的想法是个好主意。
• 看起来负载是 base64 编码的。再次将字符编码指定为 unicode。 Ascii 或二进制(字符编码，而不是数据类型)更为合适。
• ID唯一索引中的HASH关键字无意义。 InnoDB 没有实现 HASH 索引。不幸的是，MySQL 对此完全保持沉默(参见 http://bugs.mysql.com/bug.php?id=73326)

(虽然这个列表确实提供了改进的角度，但似乎不太可能用这个来解决极度缓慢的问题。一定有其他事情发生了)