Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

MyISAM vs InnoDB for BI / batch query performance (ie, _NOT_ OLTP)

Sure, for a transactional database InnoDB is a slam dunk. MyISAM doesn't support transactions or row-level locking.

But what if I want to do big nasty batch queries that touch hundreds of millions of rows?

Are there areas where MyISAM has relative advantage over InnoDB??

eg, one (minor) one that I know of ... "select count(*) from my_table;" MyISAM knows the answer to this instantly whereas InnoDB may take a minute or more to make up its mind.

--- Dave

like image 542
Dave Dopson Avatar asked May 08 '11 01:05

Dave Dopson


People also ask

How MyISAM is faster than InnoDB?

MyISAM vs InnoDBStorage: Performance InnoDB supports transactional properties, i.e. rollbacks and commits, and has a higher speed of writing. The performance of InnoDB for large volumes of data is better as compared to MyISAM. MyISAM doesn't support transactional properties and is faster to read.

Is InnoDB better than MyISAM?

Over recent years, InnoDB has shown to perform better and be more reliable. A big reason to use InnoDB over MyISAM, is the lack of full table-level locking. This allows your queries to process faster.

Which engine is best for performance in MySQL?

General purpose MySql/MariaDB EnginesXtraDB is the best choice in the majority of cases. It is a performance-enhanced fork of InnoDB and is MariaDB's default engine until MariaDB 10.1. InnoDB is a good general transaction storage engine.

What is MyISAM and InnoDB in MySQL?

Storage engine type Let's begin with MySQL engine types. InnoDB is a transactional storage engine, while MyISAM belongs to the non-transactional category. The former means that, if your data manipulation involved a transaction, then a rollback will be triggered automatically in case the transaction is not completed.


2 Answers

MyISAM scales better with very large datasets. InnoDB outperforms MyISAM in many situations until it can't keep the indexes in memory, then performance drop drastically.

MyISAM also supports MERGE tables, which is sort of a "poor man's" sharding. You can add/remove very large sets of data instantaneously. For example, if you have 1 table per business quarter, you can create a merge table of the last 4 quarters, or a specific year, or any range you want. Rather than exporting, deleting and importing to shift data around, you can just redeclare the underlying MERGE table contents. No code change required since the name of the table doesn't change.

MyISAM is also better suited for logging, when you are only adding to a table. Like MERGE tables, you can easily swap out (rotate "logs") a table and/or copy it.

You can copy the DB files associated with a MyISAM table to another computer and just put them in the MySQL data directory and MySQL will automatically add them to the available tables. You can't do that with InnoDB, you need to export/import.

These are all specific cases, but I've taken advantage of each one a number of times.

Of course, with replication, you could use both. A table can be InnoDB on the master and MyISAM on the slave. The structure has to be the same, not the table type. Then you can get the best of both. The BLACKHOLE table type works this way.

like image 134
Brent Baisley Avatar answered Oct 23 '22 04:10

Brent Baisley


Here's a great article comparing various performance points http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/ - you'll have to evaluate this from quite a few angles, including how you intend to write your queries and what your schema looks like. It's simply not a black and white question.

like image 45
David Fells Avatar answered Oct 23 '22 05:10

David Fells