InnoDB排序真的很慢吗？

Question

我在myISAM中拥有了所有表,但是当我长时间运行更新作业时,表级锁定开始杀了我.我将我的主表转换为InnoDB,现在我的许多查询都需要花费1分钟才能完成,这些查询几乎是在myISAM上完成的.他们通常陷入困境Sorting result.我做错什么了吗？

例如 :

SELECT * FROM `metaward_achiever` 
 INNER JOIN `metaward_alias` ON (`metaward_achiever`.`alias_id` = `metaward_alias`.`id`) 
 WHERE `metaward_achiever`.`award_id` = 1507  
 ORDER BY `metaward_achiever`.`modified` DESC 
 LIMIT 100  

现在大约需要90秒.这是描述:

+----+-------------+-------------------+--------+-------------------------------------------------------+----------------------------+---------+---------------------------------+-------+-----------------------------+
| id | select_type | table             | type   | possible_keys                                         | key                        | key_len | ref                             | rows  | Extra                       |
+----+-------------+-------------------+--------+-------------------------------------------------------+----------------------------+---------+---------------------------------+-------+-----------------------------+
|  1 | SIMPLE      | metaward_achiever | ref    | metaward_achiever_award_id,metaward_achiever_alias_id | metaward_achiever_award_id | 4       | const                           | 66424 | Using where; Using filesort | 
|  1 | SIMPLE      | metaward_alias    | eq_ref | PRIMARY                                               | PRIMARY                    | 4       | paul.metaward_achiever.alias_id |     1 |                             | 
+----+-------------+-------------------+--------+-------------------------------------------------------+----------------------------+---------+---------------------------------+-------+-----------------------------+

现在看来我的查询中的TONS卡在"排序结果"步骤中:

mysql> show processlist;
+--------+------+-----------+------+---------+------+----------------+------------------------------------------------------------------------------------------------------+
| Id     | User | Host      | db   | Command | Time | State          | Info                                                                                                 |
+--------+------+-----------+------+---------+------+----------------+------------------------------------------------------------------------------------------------------+
| 460568 | paul | localhost | paul | Query   |    0 | NULL           | show processlist                                                                                     | 
| 460638 | paul | localhost | paul | Query   |    0 | Sorting result | SELECT `metaward_achiever`.`id`, `metaward_achiever`.`modified`, `metaward_achiever`.`created`, `met | 
| 460710 | paul | localhost | paul | Query   |   79 | Sending data   | SELECT `metaward_achiever`.`id`, `metaward_achiever`.`modified`, `metaward_achiever`.`created`, `met | 
| 460722 | paul | localhost | paul | Query   |   49 | Updating       | UPDATE `metaward_alias` SET `modified` = '2009-09-15 12:43:50', `created` = '2009-08-24 11:55:24', ` | 
| 460732 | paul | localhost | paul | Query   |   25 | Sorting result | SELECT `metaward_achiever`.`id`, `metaward_achiever`.`modified`, `metaward_achiever`.`created`, `met | 
+--------+------+-----------+------+---------+------+----------------+------------------------------------------------------------------------------------------------------+
5 rows in set (0.00 sec)

为什么这个简单的更新停留了49秒？

如果有帮助,这里是模式:

| metaward_alias | CREATE TABLE `metaward_alias` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `modified` datetime NOT NULL,
  `created` datetime NOT NULL,
  `string_id` varchar(255) DEFAULT NULL,
  `shortname` varchar(100) NOT NULL,
  `remote_image` varchar(500) DEFAULT NULL,
  `image` varchar(100) NOT NULL,
  `user_id` int(11) DEFAULT NULL,
  `type_id` int(11) NOT NULL,
  `md5` varchar(32) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `string_id` (`string_id`),
  KEY `metaward_alias_user_id` (`user_id`),
  KEY `metaward_alias_type_id` (`type_id`)
) ENGINE=InnoDB AUTO_INCREMENT=858381 DEFAULT CHARSET=utf8 | 

| metaward_award | CREATE TABLE `metaward_award` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `modified` datetime NOT NULL,
  `created` datetime NOT NULL,
  `string_id` varchar(20) NOT NULL,
  `owner_id` int(11) NOT NULL,
  `name` varchar(100) NOT NULL,
  `description` longtext NOT NULL,
  `owner_points` int(11) NOT NULL,
  `url` varchar(500) NOT NULL,
  `remote_image` varchar(500) DEFAULT NULL,
  `image` varchar(100) NOT NULL,
  `parent_award_id` int(11) DEFAULT NULL,
  `slug` varchar(110) NOT NULL,
  `true_points` double DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `string_id` (`string_id`),
  KEY `metaward_award_owner_id` (`owner_id`),
  KEY `metaward_award_parent_award_id` (`parent_award_id`),
  KEY `metaward_award_slug` (`slug`),
  KEY `metaward_award_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=122176 DEFAULT CHARSET=utf8 | 

| metaward_achiever | CREATE TABLE `metaward_achiever` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `modified` datetime NOT NULL,
  `created` datetime NOT NULL,
  `award_id` int(11) NOT NULL,
  `alias_id` int(11) NOT NULL,
  `count` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `metaward_achiever_award_id` (`award_id`),
  KEY `metaward_achiever_alias_id` (`alias_id`)
) ENGINE=InnoDB AUTO_INCREMENT=77175366 DEFAULT CHARSET=utf8 | 

这些在我的my.cnf中

innodb_file_per_table
innodb_buffer_pool_size = 2048M
innodb_additional_mem_pool_size = 16M
innodb_flush_method=O_DIRECT

Answer 1

如你所说,你应该从MyISAM搬到Innodb吗？(这是最近的):

Innodb需要调整作为关于MyisAM到Innodb迁移的最后一点,我应该提一下Innodb调整.Innodb需要调整.真.许多应用程序的MyISAM可以很好地使用默认值.我已经看到数百个GB数据库使用默认设置运行MyISAM,并且它运行合理.Innodb需要资源,并且它对默认值不会很好.从默认值调整MyISAM很少会提供超过2-3倍的增益,而对于Innodb表来说,尤其是写入密集型工作负载可能会高达10-50倍.点击此处了解详情.

所以,关于MySQL Innodb Settings,作者在Innodb性能优化基础知识中写道:

最重要的是:

innodb_buffer_pool_size 70-80%的内存是一个安全的赌注.我在16GB的盒子上把它设置为12G.

更新:如果您正在寻找更多详细信息,请查看有关调整innodb缓冲池的详细指南

innodb_log_file_size - 这取决于你的恢复速度需求,但256M似乎是合理恢复时间和良好性能之间的良好平衡

innodb_log_buffer_size = 4M 4M对于大多数情况都是好的,除非你在这种情况下将大块的blob送到Innodb增加一点.

innodb_flush_log_at_trx_commit = 2如果您不关心ACID,并且在完全操作系统崩溃的情况下可能会丢失最后一两秒的事务而不是设置此值.它可以产生戏剧性的效果,特别是对很多短写事务.

innodb_thread_concurrency = 8即使使用当前的Innodb可伸缩性修复程序,有限的并发性也有帮助.实际数字可能更高或更低,具体取决于您的应用程序和默认值8是正常的开始

innodb_flush_method = O_DIRECT避免双缓冲并降低交换压力,在大多数情况下,此设置可提高性能.如果您没有备用电池备份RAID缓存,请注意,因为写入IO可能会受到影响.

innodb_file_per_table - 如果你没有太多的表使用这个选项,那么你就不会有不受控制的innodb主表空间增长你无法回收.这个选项在MySQL 4.1中添加,现在足够稳定可供使用.

还要检查您的应用程序是否可以在READ-COMMITED隔离模式下运行 - 如果是 - 将其设置为缺省为transaction-isolation = READ-COMMITTED.此选项具有一些性能优势,特别是在锁定5.0甚至更多内容时,MySQL 5.1和行级复制.

仅仅为了记录,mysqlperformanceblog.com背后的人们运行了比较Falcon,MyISAM和InnoDB的基准.基准测试真的应该突出Falcon,除了它赢得了当天的InnoDB,几乎每次测试都是每秒查询猎鹰和MyISAM:InnoDB vs MyISAM vs Falcon基准测试 - 第1部分.