MyISAM and InnoDB tables in one database - mysql

I have a database with about 30 tables and 5 tables of them is write-intensive.
I'm considering
Convert 5 write-intensive tables to use InnoDB engine and keep the rest on MyISAM engine
Convert all tables to use InnoDB engine.
I wonder which approach is better?
To be more specific
The reason I want to keep some table on MyISAM engine is some of them has around 1,000,000 rows. I'm not sure how slower it will be for queries like "SELECT COUNT(*)" on these tables after converted to InnoDB.
I haven't done a test. I prefer getting some advices from any of you before start the switch.

These days, I always default to using InnoDB, especially on the write-intensive tables you mention where MyISAM suffers from full table locking. Here's a to-the-point comparison.
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.
The above was taken from this site, which no longer seems to be working.

pros and cons for each.
for (1)
pros: less disk space usage, myisam much faster for read-heavy access patterns
cons: memory must be shared between the innodb buffers and myisam key buffers. innodb tables are about 4x bigger than their myisam counterparts. programmatic code must be adapted for deadlock handling.
just remember innodb will also lock if you're changing an indexed column or primary key.

Related

Can i use some tables with InnoDB engine and some with MyIsam on my MySQL database?

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.

When MyISAM is better than InnoDB?

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.

MySQL: Why InnoDB? [duplicate]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What are the differences between MyISAM and Inno DB types in MySql?
The main difference is that InnoDB supports transactions while MyISAM does not.
There are numerous other differences, however the common one's i am aware of are:
MyISAM has typically been considered faster at searching, but recent InnoDB improvements are removing this difference and improving high concurrency workload performance
InnoDB support transactions whilst MyISAM does not
InnoDB supports referential integrity whilst MyISAM does not
InnoDB handles indexes a bit differently, storing the primary key as part of every index (making indexes take up more room on the disk, but also making a covering index more likely)
MyISAM does table level locking while InnoDB can do row level locking
Different memory/buffer/index settings are used in the MySQL configuration files
InnoDB is typically said to have better crash recovery
As mentioned in another answer, the data is store on disk differently. I believe InnoDB is configurable in this area and can have one file per table etc. if required
I'm sure a google search or the MySQL site will bring up numerous other differences in more detail.
InnoDB and MyISAM
Features and Performance comparison:
InnoDB is newer while MyISAM is older.
InnoDB is more complex while MyISAM is simpler.
InnoDB is more strict in data integrity while MyISAM is loose.
InnoDB implements row-level lock for inserting and updating while MyISAM implements table-level lock.
InnoDB has transactions while MyISAM does not.
InnoDB has foreign keys and relationship contraints while MyISAM does not.
InnoDB has better crash recovery while MyISAM is poor at recovering data integrity at system crashes.
MyISAM has full-text search index while InnoDB has not.
In light of these differences, InnoDB and MyISAM have their unique advantages and disadvantages against each other. They each are more suitable in some scenarios than the other.
Advantages of InnoDB
InnoDB should be used where data integrity comes a priority because it inherently takes care of them by the help of relationship constraints and transactions.
Faster in write-intensive (inserts, updates) tables because it utilizes row-level locking and only hold up changes to the same row that’s being inserted or updated.
Disadvantages of InnoDB
Because InnoDB has to take care of the different relationships between tables, database administrator and scheme creators have to take more time in designing the data models which are more complex than those of MyISAM.
Consumes more system resources such as RAM. As a matter of fact, it is recommended by many that InnoDB engine be turned off if there’s no substantial need for it after installation of MySQL.
No full-text indexing.
Advantages of MyISAM
Simpler to design and create, thus better for beginners. No worries about the foreign relationships between tables.
Faster than InnoDB on the whole as a result of the simpler structure thus much less costs of server resources.
Full-text indexing.
Especially good for read-intensive (select) tables.
Disadvantages of MyISAM
No data integrity (e.g. relationship constraints) check, which then comes a responsibility and overhead of the database administrators and application developers.
Doesn’t support transactions which is essential in critical data applications such as that of banking.
Slower than InnoDB for tables that are frequently being inserted to or updated, because the entire table is locked for any insert or update.
The comparison is pretty straightforward. InnoDB is more suitable for data critical situations that require frequent inserts and updates. MyISAM, on the other hand, performs better with applications that don’t quite depend on the data integrity and mostly just select and display the data.
Reference:
Comparison InnoDB and MyISAM
You can also check it out here for further details:
MyISAM Or InnoDB MySQL engine?
Hope this helps.
MyISAM supports (non-standard-SQL) fulltext indexing which InnoDB still does not. This is the only reason we ever use MyISAM today.
The most important difference between MyISAM and InnoDB is that InnoDB supports transactions and foreign keys. If you need foreign keys and related functionality (for example automatically cascading deletes), you will need to use InnoDB.
InnoDB is slower than MyISAM for most uses, but can perform faster in certain conditions due to a better locking mechanism; MyISAM locks the whole table for reading while inserts/updates are executing. InnoDB can do row-level locking, thus allowing multiple concurrent writes and read on the table.
You can have more information about MyISAM & InnoDB in MySQL Documentation:
http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html
http://dev.mysql.com/doc/refman/5.1/en/innodb-overview.html
The major difference is that InnoDB supports transactions, whereas MyISAM doesn't.
MyISAM and InnoDB also store their data on disk differently. MyISAM uses a data file and an index file for each table, stored in a directory named after the database. InnoDB seems to lump everything together in a file called ibdata1.
NFS support
Unlike MyISAM, InnoDB may have problems on NFS.
From Configuring InnoDB (MySQL version 5.5)
Caution
If reliability is a consideration for
your data, do not configure InnoDB to
use data files or log files on NFS
volumes. Potential problems vary
according to OS and version of NFS,
and include such issues as lack of
protection from conflicting writes,
and limitations on maximum file sizes.
InnoDB Features
1. Provides Full transaction capability with full ACID (Atomicity, Consistency, Isolation, and Durability) compliance.
It has row level locking.By supporting row level locking, you can add data to an InnoDB table without the engine locking the table with each insert and this speeds up both the recovery and storage of information in the database.
The key to the InnoDB system is a database, caching and indexing structure where both indexes and data are cached in memory as well as being stored on disk This enables very fast recovery, and works even on very large data sets.
InnoDB supports foreign key constraints
InnoDB supports automatic crash recovery
InnoDB supports table compression (read/write)
InnoDB supports spatial data types (no spatial indexes)
Innodb support non-locking ANALYZE TABLE and is only required when the server has been running for a long time since it dives into the index statistics and gets the index information when the table opens.
Innodb does not have separate index files so they do not have to be opened.
Innodb builds its indexes one row at a time in primary key order (after an ALTER), which means index trees aren't built in optimal order and are fragmented.There is currently no way to defragment InnoDB indexes, as InnoDB can't build indexes by sorting in MySQL 5.0. Even dropping and recreating InnoDB indexes may result in fragmented indexes, depending on the data.
A table can contain a maximum of 1000 columns.
The InnoDB internal maximum key length is 3500 bytes, but MySQL itself restricts this to 3072 bytes. (1024 bytes for non-64-bit builds before MySQL 5.0.17, and for all builds before 5.0.15.)
The default database page size in InnoDB is 16KB. By recompiling the code, you can set it to values ranging from 8KB to 64KB. You must update the values of UNIV_PAGE_SIZE and UNIV_PAGE_SIZE_SHIFT in the univ.i source file.
InnoDB tables do not support FULLTEXT indexes.
MYISAM Features
No Transaction support
Table level locking
Provides Full Text search
No limit to data in table.
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)
By using DATA DIRECTORY='/path/to/data/directory' or INDEX DIRECTORY='/path/to/index/directory' you can specify where the MyISAM storage engine should
put a table's data file and index file. The directory must be the full path name to the directory, not a relative path.
you can find more detail at
http://faisalbhagat.blogspot.com/2014/09/innodb-vs-myisam.html
Here is a description of differences between InnoDB and MyIsam:
Differences between InnoDB and MyIsam
Few differences:
MYISAM doesnt support any database transactions,
INNODB will provide transactions
MYISAM provides a table level locking,
INNODB provides a row level locking
INNOBD supports foreign keys, MYISAM does not...
MyISAM is more convienient when it comes to backup, since it's rather simple to just lock all tables and copy the files directly in the filesystem. (mysqlhotcopy which is a perl-script is even part of mysql afaik)
InnoDB is a little more complex and just copying the files won't do since they cannot be restored on another machine out-of-the-box.
However, there are commercial software that offers InnoDB hotcopying.
While transaction support is the major difference, table-level locking can be an issue if you have long-running SELECT queries mixed with UPDATE statements.

Is it true that MyISAM engine is more preferable than InnoDB when we are building clustered storage? Why if it is so?

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.

MySql: MyISAM vs. Inno DB! [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What are the differences between MyISAM and Inno DB types in MySql?
The main difference is that InnoDB supports transactions while MyISAM does not.
There are numerous other differences, however the common one's i am aware of are:
MyISAM has typically been considered faster at searching, but recent InnoDB improvements are removing this difference and improving high concurrency workload performance
InnoDB support transactions whilst MyISAM does not
InnoDB supports referential integrity whilst MyISAM does not
InnoDB handles indexes a bit differently, storing the primary key as part of every index (making indexes take up more room on the disk, but also making a covering index more likely)
MyISAM does table level locking while InnoDB can do row level locking
Different memory/buffer/index settings are used in the MySQL configuration files
InnoDB is typically said to have better crash recovery
As mentioned in another answer, the data is store on disk differently. I believe InnoDB is configurable in this area and can have one file per table etc. if required
I'm sure a google search or the MySQL site will bring up numerous other differences in more detail.
InnoDB and MyISAM
Features and Performance comparison:
InnoDB is newer while MyISAM is older.
InnoDB is more complex while MyISAM is simpler.
InnoDB is more strict in data integrity while MyISAM is loose.
InnoDB implements row-level lock for inserting and updating while MyISAM implements table-level lock.
InnoDB has transactions while MyISAM does not.
InnoDB has foreign keys and relationship contraints while MyISAM does not.
InnoDB has better crash recovery while MyISAM is poor at recovering data integrity at system crashes.
MyISAM has full-text search index while InnoDB has not.
In light of these differences, InnoDB and MyISAM have their unique advantages and disadvantages against each other. They each are more suitable in some scenarios than the other.
Advantages of InnoDB
InnoDB should be used where data integrity comes a priority because it inherently takes care of them by the help of relationship constraints and transactions.
Faster in write-intensive (inserts, updates) tables because it utilizes row-level locking and only hold up changes to the same row that’s being inserted or updated.
Disadvantages of InnoDB
Because InnoDB has to take care of the different relationships between tables, database administrator and scheme creators have to take more time in designing the data models which are more complex than those of MyISAM.
Consumes more system resources such as RAM. As a matter of fact, it is recommended by many that InnoDB engine be turned off if there’s no substantial need for it after installation of MySQL.
No full-text indexing.
Advantages of MyISAM
Simpler to design and create, thus better for beginners. No worries about the foreign relationships between tables.
Faster than InnoDB on the whole as a result of the simpler structure thus much less costs of server resources.
Full-text indexing.
Especially good for read-intensive (select) tables.
Disadvantages of MyISAM
No data integrity (e.g. relationship constraints) check, which then comes a responsibility and overhead of the database administrators and application developers.
Doesn’t support transactions which is essential in critical data applications such as that of banking.
Slower than InnoDB for tables that are frequently being inserted to or updated, because the entire table is locked for any insert or update.
The comparison is pretty straightforward. InnoDB is more suitable for data critical situations that require frequent inserts and updates. MyISAM, on the other hand, performs better with applications that don’t quite depend on the data integrity and mostly just select and display the data.
Reference:
Comparison InnoDB and MyISAM
You can also check it out here for further details:
MyISAM Or InnoDB MySQL engine?
Hope this helps.
MyISAM supports (non-standard-SQL) fulltext indexing which InnoDB still does not. This is the only reason we ever use MyISAM today.
The most important difference between MyISAM and InnoDB is that InnoDB supports transactions and foreign keys. If you need foreign keys and related functionality (for example automatically cascading deletes), you will need to use InnoDB.
InnoDB is slower than MyISAM for most uses, but can perform faster in certain conditions due to a better locking mechanism; MyISAM locks the whole table for reading while inserts/updates are executing. InnoDB can do row-level locking, thus allowing multiple concurrent writes and read on the table.
You can have more information about MyISAM & InnoDB in MySQL Documentation:
http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html
http://dev.mysql.com/doc/refman/5.1/en/innodb-overview.html
The major difference is that InnoDB supports transactions, whereas MyISAM doesn't.
MyISAM and InnoDB also store their data on disk differently. MyISAM uses a data file and an index file for each table, stored in a directory named after the database. InnoDB seems to lump everything together in a file called ibdata1.
NFS support
Unlike MyISAM, InnoDB may have problems on NFS.
From Configuring InnoDB (MySQL version 5.5)
Caution
If reliability is a consideration for
your data, do not configure InnoDB to
use data files or log files on NFS
volumes. Potential problems vary
according to OS and version of NFS,
and include such issues as lack of
protection from conflicting writes,
and limitations on maximum file sizes.
InnoDB Features
1. Provides Full transaction capability with full ACID (Atomicity, Consistency, Isolation, and Durability) compliance.
It has row level locking.By supporting row level locking, you can add data to an InnoDB table without the engine locking the table with each insert and this speeds up both the recovery and storage of information in the database.
The key to the InnoDB system is a database, caching and indexing structure where both indexes and data are cached in memory as well as being stored on disk This enables very fast recovery, and works even on very large data sets.
InnoDB supports foreign key constraints
InnoDB supports automatic crash recovery
InnoDB supports table compression (read/write)
InnoDB supports spatial data types (no spatial indexes)
Innodb support non-locking ANALYZE TABLE and is only required when the server has been running for a long time since it dives into the index statistics and gets the index information when the table opens.
Innodb does not have separate index files so they do not have to be opened.
Innodb builds its indexes one row at a time in primary key order (after an ALTER), which means index trees aren't built in optimal order and are fragmented.There is currently no way to defragment InnoDB indexes, as InnoDB can't build indexes by sorting in MySQL 5.0. Even dropping and recreating InnoDB indexes may result in fragmented indexes, depending on the data.
A table can contain a maximum of 1000 columns.
The InnoDB internal maximum key length is 3500 bytes, but MySQL itself restricts this to 3072 bytes. (1024 bytes for non-64-bit builds before MySQL 5.0.17, and for all builds before 5.0.15.)
The default database page size in InnoDB is 16KB. By recompiling the code, you can set it to values ranging from 8KB to 64KB. You must update the values of UNIV_PAGE_SIZE and UNIV_PAGE_SIZE_SHIFT in the univ.i source file.
InnoDB tables do not support FULLTEXT indexes.
MYISAM Features
No Transaction support
Table level locking
Provides Full Text search
No limit to data in table.
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)
By using DATA DIRECTORY='/path/to/data/directory' or INDEX DIRECTORY='/path/to/index/directory' you can specify where the MyISAM storage engine should
put a table's data file and index file. The directory must be the full path name to the directory, not a relative path.
you can find more detail at
http://faisalbhagat.blogspot.com/2014/09/innodb-vs-myisam.html
Here is a description of differences between InnoDB and MyIsam:
Differences between InnoDB and MyIsam
Few differences:
MYISAM doesnt support any database transactions,
INNODB will provide transactions
MYISAM provides a table level locking,
INNODB provides a row level locking
INNOBD supports foreign keys, MYISAM does not...
MyISAM is more convienient when it comes to backup, since it's rather simple to just lock all tables and copy the files directly in the filesystem. (mysqlhotcopy which is a perl-script is even part of mysql afaik)
InnoDB is a little more complex and just copying the files won't do since they cannot be restored on another machine out-of-the-box.
However, there are commercial software that offers InnoDB hotcopying.
While transaction support is the major difference, table-level locking can be an issue if you have long-running SELECT queries mixed with UPDATE statements.