what are the main technical reasons to use innodb type of tables most of the time, rather than myiasm.
I searched for it, but not satisfied / confused.
some are saying it depends on the requirement.
can anyone explain how it depends on the requirement and where it differs in performance?
There's a whole wikipedia page just for this discussion :-)
http://en.wikipedia.org/wiki/Comparison_of_MySQL_database_engines
InnoDB is a right choice if you are using MySQL v5.6 as InnoDB supports full text search (FTS)
You can refer my existing answer from here https://dba.stackexchange.com/questions/1/what-are-the-main-differences-between-innodb-and-myisam/46663#46663
Related
I know we can define Partition Pruning explicitly. But, I want to know if it is provided by default. I have tried the official documentation site for MySQL. The site says, "In MySQL 5.6.8 and later, partition pruning is disabled for all tables using a storage engine that provides automatic partitioning, such as the NDB storage engine used by MySQL Cluster". A quick and to the point answer with explanation will be worth.
Thanks In Advance
Short answer: Yes.
Long answer: Watch out for some subtle terminology...
InnoDB does not have "automatic partitioning"; one must explicitly specify partitioning. NDB automatically partitions the data.
InnoDB will automatically prune down to the partition(s) that the WHERE clause specifies implicitly via a condition on the 'partition key'.
But, be aware that pruning is often no better than crafting a good composite index on a non-partitioned table.
I claim there are only 4 use cases where PARTITIONing provides any performance benefit. Furthermore, I claim that BY RANGE is the only flavor that helps.
If you would like to show us your SHOW CREATE TABLE and SELECT, we can discuss whether PARTITIONing is of any benefit. And, if no benefit, why.
I have a database program that was written a few years back using MYISAM tables in a MYSQL database. It is a pretty simple structure but I wasn't the one who set it up.
All the current releases of MYSQL are all set for INNODB and I just wondered how hard it would be to convert the current application from MYISAM to INNODB or is this something better handled by starting all over.
Considering I am not a database expert :) Whatever way is the easiest.
I have found most if not all the declaratives in the modules that state for the program to use MyIsam and it sure would be nice if I could just change the necessary parts to restate that as INNODB and get it to work
Is there a physical obstruction to using innodb that would prevent the change fro MYISAM?
As I said these are very small databases maybe 25 fields in 100 records total maximum.
Thanks for any insight
There are several differences between MyISAM and InnoDB, nicely described in this discussion:
https://dba.stackexchange.com/questions/1/what-are-the-main-differences-between-innodb-and-myisam
The only aspect which could prevent the use of InnoDB would be the full text search capabilities of MyISAM, which were introduced in InnoDB with version 5.6 of MySQL. So if your program does not make use of full text search, or if your MySQL version supports full text search with InnoDB, there is no real obstruction.
Given the small size of the database, and assuming a small traffic as well, I would not expect any substantial difference in terms of performances.
I'm currently doing research on the best ways to provide an advanced search for my php project.
I have narrowed it down to using FULLTEXT search rather than using LIKE to find matching strings in a table row. However, to do this it appears I need to sacrifice using the InnoDB engine which will make me lose the ACIDity of transactions and table relationships.
Is it really worth using the MYISAM mysql engine or are there better ways of providing search functionality.
Any pointers would be appreciated!
It really depends on the application... Using MyISAM for anything that needs referential integrity is an instant fail. At the same time, it's text search isn't all that efficient.
Basically, there are two ways to go. If you find you don't need true referential integrity, consider a NoSQL datastore. MongoDB is a great document store database.
If, on the other hand, you really need referential integrity, but also need fast, indexed full-text searching, you might do better to use Sphinx or Apache Solr to create an indexed cache for full-text search.
Either way, I consider MyISAM to be a legacy datastore. I wouldn't use it on a new project. YMMV.
MyISAM has several drawbacks - lack of transaction support, table-level locks which makes it very slow in heavy read+write load type. Another inconvenience of MyISAM tables - they are not crash safe so you can lost some data in case of unexpected shutdown or power loss on server. However MyISAM is very fast on some queries.
Regarding the FullText search I would suggest to use InnoDB + external search engine like Lucene or Sphinx so you could benefit from both safe and reliable storage engine and fast Full-text queries.
For quick start with InnoDB and Sphinx you can refer to http://astellar.com/2011/12/replacing-mysql-full-text-search-with-sphinx/
MySQL 5.6 supports FULLTEXT indexes with InnoDB (released Feb 2013). See:
http://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html
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.
I read the following article yesterday (http://blogs.sitepoint.com/2010/11/19/mysql-mistakes-php-developers/) and it wrote the following:
MySQL has a number of database engines but you’re most likely to encounter MyISAM and InnoDB.
MyISAM is used by default. However, unless you’re creating a very simple or experimental database, it’s almost certainly the wrong choice! MyISAM doesn’t support foreign key constraints or transactions which are essential for data integrity. In addition, the whole table is locked whenever a record is inserted or updated: it causes a detrimental effect on performance as usage grows.
The solution is simple: use InnoDB.
I've always used MyISAM because it was the default. What do you think?
If I were to upgrade to InnoDB, in phpMyAdmin, can I just edit each table and change it to innoDB or is there a more complex process to perform?
Thanks!
Yes, you can swap in and out engines like used underwear, if you like, without much trouble. Just change it in phpmyadmin.
But I wouldn't change it for the sake of changing it. Do you need to use foreign keys? Change it. Do you need row-level-locking instead of table-locking? Change it.
It's worth noting that there are good reasons to use MyISAM, too. Take a look at FULLTEXT indexing. You can't do that with InnoDB.
UPDATE
As of MySQL 5.6 FULLTEXT has been implemented for InnoDB tables as well. Here is the manual.
Sorry for bumping an old question, but this also helped me a lot to choose which engine, especially since MyISAM is faster for reads and my database tables had more read the write:
http://www.rackspace.com/knowledge_center/article/mysql-engines-myisam-vs-innodb