For past few days I was in a great confusion deciding whether to use MyIsam or Innodb, with both having their own pros and cons. My table will have large amount of data with heavy INSERT, UPDATE and SELECT operations.
I decided to create two tables of same structure; tbl_mytbl_innodb(innodb engine) and tbl_mytbl_myisam(myisam engine) I then created two triggers on tbl_mytbl_innodb for INSERT and UPDATE events that will insert/update tbl_mytbl_myisam. So it will always write to tbl_mytbl_innodb and read from tbl_mytbl_myisam.
Is this process correct, or do I need to do it a better way?
That's a silly way to go. The only time you should use both in parallel is if you require transactions+foreign keys AND fulltext indexes. You'd use triggers to sync up the fulltextable fields in a MyISAM table, and otherwise keep everything in InnoDB.
There's few usage cases where MyISAM is preferable over InnoDB, and the major one is the lack of fulltext support in InnoDB.
I'd say that's the opposite of a correct process. My personal recommendation is use InnoDB for almost all business activities, as it supports transactions... the only use I've found for MyISAM is full text searches (dunno why that's not available in InnoDB) but I freely admit that's a personal preference.
Using triggers to synchronize the same data across multiple tables can't be good. Define your business requirements and choose an engine. If you need to use the other engine for a specific requirement, define that and populate a subset of data as necessary.
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.
One of my friends, who is a DBA, commented that mixing MyISAM and InnoDB is fairly common among the DBA community, while designing schema in MySQL.
My question is, if this is true, then how good it is? Does it have any effect in the maintainability, scalability etc?
There are generally very few good reasons remaining to use MyISAM. Newer versions of MySQL (5.5+) have extended InnoDB to support all the features that were previously only available on MyISAM (such as fulltext and geospatial indexing), and InnoDB performance is usually considerably better than MyISAM when configured properly.
Unless you are working with an older version of MySQL, or if you have a very good reason for doing so, I'd recommend just using InnoDB throughout any new database design.
IMHO, this is one of the terrible things about MySQL: that it makes you choose between speed and full-text indices (MyISAM) and referential integrity and transactions (InnoDB). If you can, I highly recommend switching to PostgreSQL: in addition to a number of other advantages, you get speed, full-text indices, transactions, and referential integrity in one storage engine. (I no longer use MySQL for new projects at all.)
If you must stick with MySQL, I recommend using InnoDB on all tables unless you have a particular reason not to.
On a practical note.
I have done it a number of times. Notably on one system where queries were locking a whole table as myisam and we converted a number of the critical tables to innodb so they locked at the row level. This removed some bottlenecks from the process and i was with the company for another 18 months after this change with no problems from that solution. The application being supported made fairly intensive use of the database as well so any inadequacies tended to come to light quite quickly.
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.
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 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.