Sometimes I got asked on some interviews: what benefits does InnoDB have against MyISAM and when MyISAM is better than InnoDB? It's all clear about the first part of question: InnoDB is transaction compliant, row-level blocking instead of table-level blocking, foreign key support and some others, these points just came to mind immidiately.
But when MyISAM is really better than InnoDB?
MyISAM is better than InnoDB when you don't need those advanced features and storage speed is more important than other concerns. MyISAM also allows full-text searches to be performed inside the database engine itself, instead of needing to query results and then search them as an array or whatever in your application.
InnoDB is a reasonable choice if you need to store data with a high degree of fidelity with complicated interactions and relationships. MyISAM is a reasonable choice if you need to save or load a large number of records in a small amount of time.
I wouldn't recommend using MyISAM for data that matters. It's great for logging or comments fields or anything where you don't particularly care if a record vanishes into the twisting nether. InnoDB is good for when you care about your data, don't need fast searches and have to use MySQL.
It's also worth mentioning that InnoDB supports row-level locking, while MyISAM only supports table-level locking - which is to say that for many common situations, InnoDB can be dramatically faster due to more queries executing in parallel.
The bottom line: Use InnoDB unless you absolutely have to use MyISAM. Alternatively, develop against PostgreSQL and get the best of both.
MyISAM doesn't support transactions (and the other things mentioned) so it can work faster. MyISAM is a way to achieve higher performance in those situations when you do not need these features.
MyISAM supports full text, as mentioned, but also supports the MERGE table type. This is handy when you have a large table and would like to "swap" out/archive parts of it periodically. Think about a logging or report data that you want to keep the last quarter and/or year. MyISAM handles large amounts of data like this better, when you are mainly inserting and rarely updating or deleting.
InnoDB performance drops pretty quickly and dramatically once you can't fit the indexes in memory. If your primary key is not going to be a number (i.e. auto increment), then you may want to rethink using InnoDB. The primary key is replicated for every index on an InnoDB table. So if you have a large primary key and a few other indexes, your InnoDB table will get very large very quick.
There are a few features that MySQL only has implemented for MyISAM (such as native fulltext indexing).
That said, InnoDB is still typically better for most production apps.
Also: Full-text search in mySQL is only supported in myISAM tables.
MyISAM has a very simple structure, when compared with InnoDB. There is no row versioning, there's one file per table and rows are stored sequentially. However, while it supports concurrent inserts (SELECTs and 1 INSERT can run together), it also has table-level locks (if there are 2 INSERTs on the same table, 1 has to wait). Also, UPDATEs and DELETEs are slow because of the structure of the data files.
MyISAM doesn't support transactions or foreign keys.
Generally, MyISAM should be better if you work on general trends (so you don't care about the correctness of individual rows) and data is updated by night or never. Also, it allows to move individual tables from one server to another, via the filesystem.
InnoDB supports very well concurrency and transactions. Has a decent support for fulltext and an almost-decent support for foreign keys.
Related
I read that Innodb is better to use on a table that get a lot's of insert records simultaneously. My application gets about 50 records per seconds. So for these tables should I use Innodb, right?
In the other hand i have some tables that are only used for select, they get few updated or have few new insert. Is MyIsam faster for select ?
If it's the case, is it better to leave some table with MyIsam and some with Innodb or should i use all tables with the same engine ?
My application also searches a lot on the tables that i want to pass in Innodb. What should i do ?
you can check these:
Reasons to use MyISAM:
Tables are really fast for select-heavy loads
Table level locks limit their scalability for write intensive multi-user environments.
Smallest disk space consumption
Fulltext index
Merged and compressed tables.
Reasons to use InnoDB:
ACID transactions
Row level locking
Consistent reads – allows you to reach excellent read write concurrency.
Primary key clustering – gives excellent performance in some cases.
Foreign key support.
Both index and data pages can be cached.
Automatic crash recovery – in case MySQL shutdown was unclean InnoDB tables will still
recover to the consistent state- No check repair like MyISAM may require. All updates have to pass through transactional engine in
InnoDB, which often decreases - performance compared to
non-transactional storage engines.
quoted from here
and for the last part:
REMEMBER! It's OK to mix table types in the same database! In fact it's recommended and frequently required. However, it is important to note that if you are having performance issues when joining the two types, try converting one to the other and see if that fixes it. This issue does not happen often but it has been reported.
quoted from here
I hope that's enough :D
Yes you can, but I'd go with InnoDB only unless there is some serious performance bottleneck
same question on SO
MySQL forum
In short yes you can mix and match to your hearts content.
Keep the following in mind:
InnoDB is ACID complaint. Thus is you need any ACID features use InnoDB. MyISAM is does not support a lot of things like foreign key constraints for example.
Now speed is hard to quantify exactly. Depending on execution paths you might get very big or very small speed differences.
Test and check there is no right or wrong answer here.
I make my first eshop using Prestashop and I'm not sure if is better use MyISAM or InnoDB. In eshop could be max about 3 000 items.
I think that most important for that question is how much items will be in eshop, but if I didn't write some other important information, please ask me.
This decision is dependent on read/write ratio. MYISAM uses table level level, so if a table is locked only one query can run on it hence MYISAM has serious performance issues. Also on prior version from 5.6 only MYISAM has support of FULLTEXT search. tables of MYISAM are really fast for SELECT queries and it takes less space on disk.
On the other hand, INNODB supports row-level locking hence concurrent select with insert is possible. It has support of doing ACID transactions hence each statement is atomic and durable in the event of crash.
So my decision is to use INNODB for application like eshop.
I would use InnoDB because it supports transactions and that's likely necessary for an eshop. For much more detailed information, check out the answers to this question:
MyISAM versus InnoDB
I've read various threads about which is better between InnoDB and MyISAM. It seems that the debates are to use or the other. Is it not possible to use both, depending on the table?
What would be the disadvantages in doing this? As far as I can tell, the engine can be set during the CREATE TABLE command. Therefore, certain tables which are often read can be set to MyISAM, but tables that need transaction support can use InnoDB.
You can have both MyISAM and InnoDB tables in the same database. What you'll find though, when having very large tables is, MyISAM would cause table-lock issues. What this ultimately does is, it locks the whole table for a single transaction, which is very bad if you have many users using your website. e.g If you have a user searching for something on your site and the query takes minutes to complete, no other users could use your site during that period because the whole table is locked.
InnoDB on the other hand uses row-level locking, meaning, that row is the only row locked from the table during a transaction. InnoDB can be slower at searches because it doesn't offer full text search like MyISAM, but that isn't a big problem when you compare it to table-level locking of MyISAM. If you use InnoDB, like many large sites, then you could use a server side search engine like Sphinx for full text searches. Or you could even use a MyISAM table to do the searching like f00 suggested. I'd personally recommended InnoDB mainly because of the row-level locking feature, but also because you can implement full text searching in many other ways.
Basically, if you have a message board application with lots of selects, inserts as well as updates, InnoDB is probably the generally appropriate choice.
But if you're not building something like that (or any other thing with registered users) and your working mostly with static content (or more reads than writes), then you could use MyISAM.
Yes indeed you may use both in the same database, you may choose for each table separately.
In short, InnoDB is good if you are working on something that needs a reliable database that can handles a lot of INSERT and UPDATE instructions.
and, MyISAM is good if you needs a database that will mostly be taking a lot of read (SELECT) instructions rather than write (INSERT and UPDATES), considering its drawback on the table-lock thing.
you may want to check out;
Pros and Cons of InnoDB
Pros and Cons of MyISAM
You don't choose InnoDB or MyISAM on a database level, but instead on a table level. So within the one database you could have some tables running the InnoDB engine and some running MyISAM. As you pointed out, you could choose to use InnoDB on the tables that require transactions etc, and MyISAM where you need other features such as fulltext searching.
I have 2 tables in which I want more robustness and fortunately don't require frequent rapid fulls of data and examination.
All other tables would inevitably be MyISAM.
Can I safely use both (I've read a handful of discouragements from this) without fearing bugs or data getting affected by differences between engines?
You CAN but this introduces a number of disadvantages:
Your server tuning will now necessarily be a compromise - you cannot use all the memory for either MyISAM OR InnoDB (NB: This does not apply if they are on different servers)
Replication fails in a number of edge-cases, because if you have a failed transaction which contained changes to some MyISAM tables, it can neither correctly commit it nor roll it back
You still can't back up your server using MVCC, because you'd still not get a consistent snapshot of MyISAM tables
So basically, I'd encourage you to switch wholly to InnoDB. Then you can pretty much forget about MyISAM and not devote resources to it, and get the full benefits of using InnoDB. Anyone who thinks MyISAM is faster is either not tuning InnoDB correctly, or has such small data that who cares.
MyISAM does faster table scans, but if you're doing those on large tables, you have bigger problems.
Yes, you can.
Note that only InnoDB tables support transactions and FOREIGN KEY relationships.
I heard this today during interview for java developer. I had to list some advantages of MyISAM over InnoDB and why it's still being widely used. And they were waiting to hear from me the answer as the title of this question.
As I understand from their own answer: MyISAM doesn't have foreign keys and DB can be easily clustered (one table per server for example). But why can't we simply create InnoDB tables without foreign keys? This explaination sounds strange to me..
There is no silver bullet answer here. You need to know the pros and cons of each before you make a decision on which one you use for any particular application.
InnoDB:
supports FK's
supports transactions
uses a large memory buffer for operation
supports row level locking
But has a much higher maintenance cost -- you really need to tune your memory usage, configure your table files, etc.
MyISAM:
has a bunch of special column features that InnoDB doesn't, like:
full text indexes
spatial columns (I'm pretty sure this doesn't work with InnoDB)
Very fast for primary read/append use cases (table locks for updates, deletes, but not for inserts)
Also typically has faster inserts
caches indexes in memory (key buffer), but relies on the OS to buffer the actual data pages
For example, I'd use InnoDB for things like ecommerce, user databases or anything that I want to use transactions in.
For data warehouses, logging, reporting, etc I'd probably use MyISAM.
I had to list some advantages of MyISAM over InnoDB
FULLTEXT search
...
no, that's it.
(OK, there are some cases where MyISAM is faster than InnoDB, but rarely enough that it's worth putting up with the lack of ACID-compliance. Today the main reason for doing anything with MyISAM is to get fulltext search which is sadly not supported in InnoDB.)
I am not sure if this is no longer true MyISAM is faster than InnoDB for reads.
Also, MyISAM tables are stored in separate files and (from what I can remember) you can actually transport those files to another MySQL database and is easier to backup.
By default InnoDB databases are stored in one huge glob on the file system.
As for why it is still being widely used, I always figured it was because it is the default option. Personally, I still believe that the advantages of InnoDB triumphs MyISAM and MyISAM also has problems with data integrity from my experience.
You certainly could create InnoDB tables without foreign keys, but that is cutting out one of the main advantages of it: referential integrity.
However, since MyISAM isn't built with the intent of referential integrity table keys can be stored differently, and perhaps more efficiently.
There are also some differences in locking and access. InnoDB supports row level locking, whereas MyISAM only supports table-level locking. Depending on the queries you're performing (SELECTS versus INSERTS/UPDATES) this can have a noticeable effect on performance.
You prolly need to read up on the Mysql Peformance blog.