Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
MYISAM, are storage engines for
These two differ on their locking implementation:
InnoDB locks the particular row in the table, and
MyISAM locks the entire
You can specify the type by giving
InnoDB while creating a table in DB.
Have a look at
InnoDB is a storage engine for MySQL,
included as standard in all current
binaries distributed by MySQL AB. Its
main enhancement over other storage
engines available for use with MySQL
is ACID-compliant transaction support
MyISAM is the default storage engine
for the MySQL relational database
management system versions prior to
5.5 1. It is based on the older ISAM code but has many useful extensions.
The major deficiency of MyISAM is the absence of transactions support.
Versions of MySQL 5.5 and greater have
switched to the InnoDB engine to
ensure referential integrity
constraints, and higher concurrency.
They are storage engines.
MyISAM: The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
InnoDB: A transaction-safe (ACID compliant) storage engine for MySQL that has commit, rollback, and crash-recovery capabilities to protect user data. InnoDB row-level locking (without escalation to coarser granularity locks) and Oracle-style consistent nonlocking reads increase multi-user concurrency and performance. InnoDB stores user data in clustered indexes to reduce I/O for common queries based on primary keys. To maintain data integrity, InnoDB also supports FOREIGN KEY referential-integrity constraints.
InnoDB is a transactional storage engine of MySQL whereas MyISAM is a non-transactional storage engine. In other words, InnoDB follows the ACID properties to maintain the integrity of data but MyISAM doesn’t follow ACID properties thus failing to maintain the integrity of the data.
In an InnoDB (transactional) table, the transactional changes can be
easily undone if a rollback is required. But changes made to a MyISAM
(non-transactional) table cannot be undone when rolling back a
transaction is required.
For example, you want to transfer money from your checking account to saving account. This is done by a transaction which includes 5 queries.
1 START TRANSACTION; 2 SELECT balance FROM checking WHERE customer_id = 10233276; 3 UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 10233276; 4 UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276; 5 COMMIT;
Suppose, the process crashes at step 4. If a InnoDB table was used here, a rollback would undo the changes and you are saved from the risk of losing money. Literally, the table is unaware of any crash as the changes will not be commited to the table unless step 5 is successfully executed.
But in the case of a MyISAM table, one cannot undo the transactional changes when a rollback is called or if there is a crash leading to the failure of the transaction. This means, if the transaction crashed at step 3, money will be deducted from your checking account. But money wouldnot have been added to your savings account.
Example courtesy: “High Performance MySQL: Optimization, Backups, and Replication” –
Book by Arjen Lentz, Derek J. Balling, Jeremy Zawodny, Peter Zaitsev, and Vadim Tkachenko
I wanted to add that having ability to specify a specific storage engine per table is one of the key strengths of MySQL (besides easy of use and good performance with no tweaking). For all operations where transactions are needed, just stick with InnoDB. However, MyISAM can really speed things up when transactions are not needed in certain situations – and requires less disk space and RAM compared to InnoDB.
That said, InnoDB is getting better all the time:
MyISAM does not follow ACID as opposed to InnoDB which follows transactions to maintain integrity of the data.
MyISAM supports concurrent inserts: If a table has no free blocks in
the middle of the data file, you can INSERT new rows into it at the
same time that other threads are reading from the table. MySqlDoc
That is why, MyISAM is faster and takes less space. For instance, the MySQL MyISAM Storage Engine does not support tranactions.constraints of MySQL MYISAM There is a bit called concurrent-insert
By default, the variable is set to 1 and concurrent inserts are handled as just described. If it is set to 0, concurrent inserts are disabled. If it is set to 2, concurrent inserts at the end of the table are permitted even for tables that have deleted rows. An INSERT statement can be executed to add rows to the end of the table with select at same time if there are no holes/deleted rows in middle of table (at time of concurrent insert).
The default isolation level og mysql InnoDB is “Read Repeatable”. For MyISAM, there is no transaction. InnoDB uses row level locking while MyISAM can only use table level locking that is why InnoDB has crash revovery is better than MyISAM. One has to manually acquire the table level lock in MyISAM if one wants to avoid the concurrency effects.
When your MySQL server crashes, the data can be recovered much easier from a set of MyISAM tables than from that big InnoDB transaction file. Each MyISAM table has a separate file, and if no write operations were being made to this table during the crash – it will be totally unaffected. In case of InnoDB, the entire transaction file of the entire MySQL server has to be re-indexed or whatever it does after a crash. That can get quite messy.
InnoDB is the default NOT myISAM
“InnoDB is the default MySQL storage engine. Unless you have configured a different default storage engine, issuing a CREATE TABLE statement without an ENGINE= clause creates an InnoDB table”