Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

What are the main differences between InnoDB and MyISAM?

share|improve this question
3  
This thread might be useful. –  Lazer Jan 3 '11 at 21:01
3  
If you want a database engine, use InnoDB. You can't compare the two. –  Jeremy Stein Jan 10 '13 at 15:12
add comment

8 Answers

First major difference I see is that InnoDB implements row-level lock while MyISAM can do only a table-level lock. You will find better crash recovery in InnoDB. However, it doesn't have FULLTEXT search indexes, as does MyISAM. InnoDB also implements transactions, foreign keys and relationship constraints while MyISAM does not.

The list can go a bit further. Yet, they both have their unique advantages in their favor and disadvantages against each other. Each of them is more suitable in some scenarios than the other.

So to summarize (TL;DR):

  • InnoDB has row-level locking, MyISAM can only do full table-level locking.
  • InnoDB has better crash recovery.
  • MyISAM has FULLTEXT search indexes, InnoDB doesn't.
  • InnoDB implements transactions, foreign keys and relationship constraints, MyISAM does not.
share|improve this answer
    
dear sir, so ultimately what shall one use? MyISAM or InnoDB ? am totally confused...my website is using mysql and i need to decide this. –  sqlchild Aug 30 '12 at 11:44
2  
depends on the application, write down a list with the features you'll need ( eg. fulltext search, foreign keys ... ) and try to decide on one ( try to rate each feature and then count the score ). you wont be able to have them all but it's up to you to decide witch feature is needed the most . –  poelinca Aug 30 '12 at 12:14
1  
I edited his post for clarification. –  Mathias Lykkegaard Lorenzen Jul 23 '13 at 6:24
    
@MathiasLykkegaardLorenzen thanks, that's one of the reasons we like stackexchange –  poelinca Jul 25 '13 at 23:37
add comment

Another major difference not as yet mentioned is how caching for each storage engine is done.

MYISAM

The main mechanism used is the key cache. It only caches index pages from .MYI files. To size your key cache, run the following query:

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1))
recommended_key_buffer_size FROM
(SELECT LEAST(POWER(2,32),KBS1) KBS
FROM (SELECT SUM(index_length) KBS1
FROM information_schema.tables
WHERE engine='MyISAM' AND
table_schema NOT IN ('information_schema','mysql')) AA ) A,
(SELECT 2 PowerOf1024) B;

This will give the Recommended Setting for MyISAM Key Cache (key_buffer_size) given your current data set (the query will cap the recommendation at 4G (4096M). For 32-bit OS, 4GB is the limit. For 64-bit, 8GB.

InnoDB

The main mechanism used is the InnoDB Buffer Pool. It caches data and index pages from InnoDB tables accessed. To size your InnoDB Buffer Pool, run the following query:

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 2 PowerOf1024) B;

This will give the Recommended Setting for the size of the InnoDB Buffer Pool (innodb_buffer_pool_size) given your current data set.

Don't forget to resize the InnoDB Log Files (ib_logfile0 and ib_logfile1). MySQL Source Code places a cap of the combined sizes of all InnoDB Log Files must be < 4G (4096M). For the sake of simplicity, given just two log files, here is how you can size them:

  • Step 1) Add innodb_log_file_size=NNN to /etc/my.cnf (NNN should be 25% of innodb_buffer_pool_size or 2047M, whichever is smaller)
  • Step 2) service mysql stop
  • Step 3) rm /var/log/mysql/ib_logfile[01]
  • Step 4) service mysql start (ib_logfile0 and ib_logfile1 are recreated)

CAVEAT

At the End of both queries is a an Inline Query (SELECT 2 PowerOf1024) B

  • (SELECT 0 PowerOf1024) gives the Setting in Bytes
  • (SELECT 1 PowerOf1024) gives the Setting in Kilobytes
  • (SELECT 2 PowerOf1024) gives the Setting in Megabytes
  • (SELECT 3 PowerOf1024) gives the Setting in Gigabytes
  • No powers less that 0 or greater than 3 is accepted

EPILOGUE

There is no substitute for common sense. If you have limited memory, a mixture of storage engines, or a combination thereof, you will have to adjust for different scenarios.

  • If you have 2GB RAM and 16GB of InnoDB, allocate 512M as innodb_buffer_pool.
  • If you have 2GB RAM and 4GB of MyISAM Indexes, allocate 512M as key_buffer_size.
  • If you have 2GB RAM and 4GB of MyISAM Indexes and 16GB InnoDB, allocate 512M as key_buffer_size and 512M as innodb_buffer_pool_size.

Possible scenarios are endless !!!

Remember, whatever you allocate for, leave enough RAM for DB Connections and the Operating System.

share|improve this answer
    
Those are bad formulas! –  Rick James Jun 23 '11 at 0:06
    
(oops - keep forgetting can't have paragraphs)... I'll add an "answer". –  Rick James Jun 23 '11 at 0:07
    
Rolando's formulas for cache sizes are not practical. -- Powers of 2 are not needed. -- 4GB on a 32-bit OS is impossible -- Etc. Here's my rundown on what to set them to: mysql.rjweb.org/doc.php/memory (It addresses various other settings that affect memory usage.) –  Rick James Jun 23 '11 at 0:13
1  
@Rick : The powers of 2 were meant to display the answers in different units. Doing (SELECT 2 PowerOfTwo) Sets the Display of the Answer in MB. Doing (SELECT 3 PowerOfTwo) Sets the Display in GB. (SELECT 1 PowerOfTwo) Displays in KB. (SELECT 0 PowerOfTwo) Displays in Bytes. That's what the (SELECT 2 PowerOfTwo) does. So it is needed to DISPLAY ONLY, not impose any assumed values in the architecture. –  RolandoMySQLDBA Jun 23 '11 at 2:25
1  
@Rick : You know what ? I will actually give you a +1 for two very big reasons. 1) Your URL confirms my answer was correct in that 4GB is the biggest number to assign to the key_buffer_size. 2) Your answer, with your URL, makes sense for machines very low memory. I'll give credit where credit is due. –  RolandoMySQLDBA Jun 23 '11 at 2:41
show 6 more comments

One more thing: you can backup InnoDB tables just by taking a snapshot of the filesystem. Backing up MyISAM requires using mysqldump and is not guaranteed to be consistent (e.g. if you insert into a parent and a child table, you might find only the child table's row in your backup).

Basically, if you have another copy of the data and are only caching it in MySQL e.g. to allow a standard means of accessing it from a PHP website, then MyISAM is fine (i.e. it's better than a flat CSV file or a logfile for querying and concurrent access). If the database is the actual "master copy" of the data, if you are doing INSERT and UPDATE using real data from users, then it is foolish to use anything other than InnoDB, at any sort of scale MyISAM is unreliable and hard to manage, you'll be doing myisamchk half the time, negating any performance gains...

(My personal experience: a 2 terabyte DB in MyISAM).

share|improve this answer
add comment

InnoDB offers:

  • ACID transactions
  • row-level locking
  • foreign key constraints
  • automatic crash recovery
  • table compression (read/write)
  • spatial data types (no spatial indexes)

In InnoDB all data in a row except for TEXT and BLOB can occupy 8,000 bytes at most. No full text indexing is available for InnoDB. In InnoDB the COUNT(*)s (when WHERE, GROUP BY, or JOIN is not used) execute slower than in MyISAM because the row count is not stored internally. InnoDB stores both data and indexes in one file. InnoDB uses a buffer pool to cache both data and indexes.

MyISAM offers:

  • fast COUNT(*)s (when WHERE, GROUP BY, or JOIN is not used)
  • full text indexing
  • smaller disk footprint
  • very high table compression (read only)
  • spatial data types and indexes (R-tree)

MyISAM has table-level locking, but no row-level locking. No transactions. No automatic crash recovery, but it does offer repair table functionality. No foreign key constraints. MyISAM tables are generally more compact in size on disk when compared to InnoDB tables. MyISAM tables could be further highly reduced in size by compressing with myisampack if needed, but become read-only. MyISAM stores indexes in one file and data in another. MyISAM uses key buffers for caching indexes and leaves the data caching management to the operating system.

Overall I would recommend InnoDB for most purposes and MyISAM for specialized uses only. InnoDB is now the default engine in new MySQL versions.

share|improve this answer
    
I read your answer and compared it with the others already here. Yours is the only one to mention BLOBs. They are usually taken for granted. Yours is also the only one mentioning myisampack, one of the unsung heroes of fast-readable MyISAM tables. Yours is a +1 today !!! –  RolandoMySQLDBA Aug 23 '11 at 3:45
    
+1 despite the not accurate "fast COUNT(*)s" –  ypercube Jun 28 '12 at 9:47
    
You may want to add that MyISAM offers spatial (R-tree) indices on spatial datatypes (while InnoDB no, only spatial datatypes) –  ypercube Aug 10 '12 at 8:14
    
Thanks, I have totally left out spatial indices. Would you be able to elaborate on the inaccurate fast COUNT(*)s? How should I rephrase it? –  dabest1 Aug 10 '12 at 16:48
1  
COUNT(*) is fast in MyISAM (no hitting the table at all), when there is no WHERE and no joins: SELECT COUNT(*) FROM tableName; If there are joins, where or group by conditions, that doesn't apply. –  ypercube Aug 10 '12 at 17:22
show 1 more comment

In my experience, the most significant difference is the way each engine handles locking. InnoDB uses row locking while MyISAM uses table locking. As a rule of thumb, I use InnoDB for write heavy tables and MyISAM for read heavy tables.

Other important differences include:

  1. InnoDB support transactions and foreign keys. MyISAM does not.
  2. MyISAM uses full text indexing.
  3. MyISAM does a poor job of enforcing data integrity.
share|improve this answer
add comment

I tend to view MyISAM as the 'default' table choice for MySQL, so I'll point out the differences for most users of InnoDB

share|improve this answer
4  
except the latest MySQL release no longer uses MyISAM as the default engine. In 5.5 they changed the default to InnoDB :). And I would disagree with the generalization that InnoDB in general just gets a 'performance hit'. Well designed InnoDB tables with proper indexing and well configured memory settings can make an InnoDB table perform as well as the same schema in MyISAM –  TechieGurl Jun 24 '11 at 13:44
3  
In many "high-use" situations InnoDB actually performs way better than MyISAM. MyISAM is a specific tool for a specific problem, while InnoDB will serve you better in the majority of situations (hence why the MySQL team made it the default engine). It's because MyISAM was the only engine for a long time that the MySQL community grew into the habit of using MyISAM by default, even after InnoDB matured. –  Nick Chammas Aug 15 '11 at 19:53
1  
FULLTEXT search for InnoDB was added partway through the MySQL 5.6 development cycle. The URL cited now covers InnoDB also. –  Max Webster Dec 20 '12 at 6:52
add comment

Includes MySQL 5.6 changes

INNODB STORAGE ENGINE:

  • It provides full ACID (atomicity, consistency, isolation, durability) compliance. Multi-versioning is used to isolate transactions from one another.
  • InnoDB provides auto-recovery after a crash of the MySQL server or the host on which the server runs.
  • InnoDB supports foreign keys and referential integrity, including cascaded deletes and updates.
  • MySQL 5.6 builds on the platform of InnoDB fully integrated as the default storage engine
  • Persistent Optimizer Stats: Provides improved accuracy of InnoDB index statistics, and consistency across MySQL restarts.
  • Pruning the InnoDB table cache: To ease the memory load on systems with huge numbers of tables, InnoDB now frees up the memory associated with an opened table. An LRU algorithm selects tables that have gone the longest without being accessed.
  • Supports Full-text search: A special kind of index, the FULLTEXT index, helps InnoDB deal with queries and DML operations involving text-based columns and the words they contain. These indexes are physically represented as entire InnoDB tables.
  • InnoDB seems to be way faster on Full-Text Search than MyISAM

So, there is no point in using MyISAM Engine if you are already upgraded to 5.6, if not then don't wait for upgrading to MySQL 5.6.

InnoDB VS MyISAM performance using MySQL 5.6

share|improve this answer
add comment

MYISAM

MYISAM provides table level locking , FULLTEXT searching. MYISAM has the most flexible AUTO_INCREMENTED column handling off all the storage engines. MYISAM does not support transactions.

INNODB

INNODB is transaction safe storage engine. INNODB has commit , rollback and crash-recovery capabilities. INNODB supports foreign key referential integrity.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.