我正在从事一个涉及大量数据库写入的项目(70%的插入和30%的读取)。这个比率还包括我认为是一个读一个写的更新。读取可能是脏的(例如,在读取时我不需要100%准确的信息)。 该任务每小时将处理超过100万个数据库事务。

我在网上读了一堆关于MyISAM和InnoDB之间区别的东西,对于我将用于这个任务的特定数据库/表来说,MyISAM似乎是显而易见的选择。从我看来,InnoDB在需要事务时是很好的,因为它支持行级锁。

有人有这种负载(或更高)的经验吗?MyISAM是正确的选择吗?


当前回答

人们经常谈论性能、读写、外键等等,但在我看来,存储引擎还有一个必须具备的特性:原子更新。

试试这个:

Issue an UPDATE against your MyISAM table that takes 5 seconds. While the UPDATE is in progress, say 2.5 seconds in, hit Ctrl-C to interrupt it. Observe the effects on the table. How many rows were updated? How many were not updated? Is the table even readable, or was it corrupted when you hit Ctrl-C? Try the same experiment with UPDATE against an InnoDB table, interrupting the query in progress. Observe the InnoDB table. Zero rows were updated. InnoDB has assured you have atomic updates, and if the full update could not be committed, it rolls back the whole change. Also, the table is not corrupt. This works even if you use killall -9 mysqld to simulate a crash.

性能当然是可取的,但不丢失数据更重要。

其他回答

对于这样的读写比率,我猜InnoDB会表现得更好。 既然您可以接受脏读,那么您可以(如果您负担得起)复制到一个从服务器,并让您的所有读都到从服务器。另外,考虑批量插入,而不是一次插入一条记录。

底线:如果你离线工作,选择大量的数据,MyISAM可能会给你更好的(好得多)速度。

在某些情况下,MyISAM比InnoDB的效率要高得多:离线操作大型数据转储时(因为表锁)。

示例:我正在从NOAA转换一个csv文件(15M条记录),它使用VARCHAR字段作为键。InnoDB的运行时间很长,即使有大量的内存可用。

这是CSV的一个例子(第一个和第三个字段是键)。

USC00178998,20130101,TMAX,-22,,,7,0700
USC00178998,20130101,TMIN,-117,,,7,0700
USC00178998,20130101,TOBS,-28,,,7,0700
USC00178998,20130101,PRCP,0,T,,7,0700
USC00178998,20130101,SNOW,0,T,,7,

因为我需要做的是运行观察到的天气现象的批量离线更新,我使用MyISAM表接收数据,并在键上运行join,这样我就可以清理传入的文件,并将VARCHAR字段替换为INT键(与原始VARCHAR值存储的外部表相关)。

我知道这不会受欢迎,但我还是这么说:

myISAM缺乏对数据库基本要素的支持,如事务和引用完整性,这通常会导致应用程序出现故障/ bug。如果您的数据库引擎甚至不支持这些基础知识,那么您不可能不学习正确的数据库设计基础知识。

在数据库世界中不使用引用完整性或事务就像在软件世界中不使用面向对象编程一样。

InnoDB已经存在了,使用它吧!尽管myISAM是所有遗留系统的默认引擎,但MySQL开发人员最终还是同意在新版本中将其更改为默认引擎。

不,无论您是在读写还是有什么性能考虑,使用myISAM都会导致各种各样的问题,比如我刚刚遇到的这个问题:我正在执行数据库同步,同时其他人访问了一个访问myISAM表的应用程序。由于缺乏事务支持,这个引擎的可靠性也很差,导致整个数据库崩溃,我不得不手动重启mysql!

在过去15年的开发中,我使用了许多数据库和引擎。在此期间,myISAM在我身上崩溃了十几次,其他数据库只有一次!那是一个microsoft SQL数据库,其中一些开发人员编写了错误的CLR代码(公共语言运行时-基本上是在数据库内部执行的c#代码),顺便说一下,这并不是数据库引擎的错误。

我同意这里的其他答案,即高质量的高可用性、高性能应用程序不应该使用myISAM,因为它不起作用,它不够健壮或不够稳定,无法带来无挫折的体验。详见Bill Karwin的回答。

附注:我喜欢myISAM的粉丝们投反对票,但不能告诉你这个答案的哪一部分是错误的。

简而言之,如果你的工作需要一个可靠的数据库来处理大量的INSERT和UPDATE指令,InnoDB是很好的选择。

而且,如果你需要的数据库需要大量的读(SELECT)指令而不是写(INSERT和UPDATES), MyISAM是很好的,考虑到它在表锁方面的缺点。

你可能想去看看; InnoDB的优缺点 MyISAM的利弊

我不是数据库专家,也不是凭经验说的。然而:

MyISAM表使用表级锁定。根据您的流量估计,您每秒有接近200个写入操作。有了MyISAM,在任何时候只有其中一项可以进行。您必须确保您的硬件能够跟上这些事务,以避免超时,即单个查询的时间不能超过5毫秒。

这就意味着你需要一个支持行级锁的存储引擎,比如InnoDB。

另一方面,编写几个简单的脚本来模拟每个存储引擎的负载,然后比较结果应该是相当简单的。