1

我想知道究竟是什么原因导致 mysql/innodb 上的插入查询在 CPU 相当强大的机器上持续至少 40 毫秒。“等效”查询在同一个 MyISAM 表上运行 <10 毫秒（表没有任何外键）。时间来自 MySQL 控制台。

这是用于复制的“尽可能简单”的数据库结构。

CREATE TABLE `test_table_innodb` (
  `id` int NOT NULL AUTO_INCREMENT,
  `int_column` int NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `test_table_myisam` (
  `id` int NOT NULL AUTO_INCREMENT,
  `int_column` int NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

我正在从 mysql 控制台运行相同的查询（在 InnoDB 的情况下自动提交事务）。当时没有在机器上执行其他查询，结果是：

 mysql> insert into test_table_myisam (int_column) values (5);
 Query OK, 1 row affected (0.00 sec)

 mysql> insert into test_table_innodb (int_column) values (5);
 Query OK, 1 row affected (0.06 sec)

事务开销是否会使查询对 InnoDB 表运行更长时间？或者？

4

2 回答 2

2

每个自动提交的 INSERT 都需要考虑三个方面

方面#1。高架

InnoDB 支持 MVCC 和事务隔离作为 ACID 兼容的存储引擎。为了适应这一点，在提交更改之前的行副本被写入系统表空间文件的撤消表空间部分ibdata1。如果您正在运行 INSERT，会写什么？一个空白行的副本。这样，回滚就可以简单地删除插入的尝试。当一个 INSERT 被提交时，Undo Tablespace 中的空白副本被删除。

方面#2。聚集索引

对于每个 InnoDB 表，都存在一个名为 的内部默认行索引gen_clust_index。无论是否存在 PRIMARY KEY，都会创建它。由于您的表具有 id 的 PRIMARY KEY，因此 gen_clust_index 被构造为与包含唯一 id 字段的行相关联。

方面#3。配置

信不信由你，有时开箱即用的 MySQL 4.1 比 MySQL 5.5 更快。听起来很震惊，不是吗？Percona 实际上对 MySQL 的几个版本进行了基准测试，发现情况确实如此。

我之前在 DBA StackExchange 上写过这个

于 2012-07-16T18:24:35.860 回答
1

CPU不是这里的因素。因素是磁盘。在 innodb 中该命令需要写入 log ，所以如果 log 磁盘是同一个磁盘或磁盘不是碎片或磁盘慢的话，你会有很大的不同。

于 2012-07-16T20:49:14.020 回答