InnoDB vs MyISAM vs Falcon benchmarks – part 1

InnoDB vs MyISAM vs Falcon benchmarks – part 1

PREVIOUS POST
NEXT POST

Several days ago MySQL AB made new storage engine Falcon available for wide auditory. We cannot miss this event and executed several benchmarks to see how Falcon performs in comparison to InnoDB and MyISAM.
The second goal of benchmark was a popular myth that MyISAM is faster than InnoDB in reads, as InnoDB is transactional, supports Foreign Key and has an operational overhead. As you will see it is not always true.


For benchmarks I used our PHPTestSuite which allows to test wide range tables and queries.
The script and instruction are available here:
https://www.percona.com/blog/files/benchmarks/phptestsuite.stable.tar.gz

We used table “normal” table structure which corresponds to typical structure you would see in OLTP or Web applications – medium size rows, auto increment primary key and couple of extra indexes.

In this benchmark we used only read (SELECT) queries with different typical data access patterns:
primary key single row lookup, primary key range lookup, same access types for primary key and full table scans.

To highlight different properties of storage engines we tested ranges with and without LIMIT clause, and tested queries which
need to read the data or can only be satisfied by reading the index.

This benchmark is so called “micro” benchmark which concentrates on particular simple storage engine functions and we use it to see performance and scalability in this simple cases. We also use CPU bound workload in this case (no disk IO) to see how efficient storage engines are in terms of CPU usage. In real life workload results are likely to be very different.

The schema and queries are described here

Used hardware

CentOS release 4.4 (Final)
2 Ñ… Dual Core Intel XEON 5130

model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
stepping : 6
cpu MHz : 1995.004
cache size : 4096 KB

16GB of RAM

MySQL version
We used MySQL 5.1.14-beta sources for MyISAM / InnoDB
and MySQL 5.1.14-falcon bitkeeper tree
bk://mysql.bkbits.net/mysql-5.1-falcon for Falcon
(Please note this is a first release of Falcon and it is still in alpha stage and performance parameters may vary a lot in next releases)
Compilation parameters:

mysqld startup params:

Method of benchmark:
1. Prepare table with 1,000,000 records (about 350Mb of data on disk)
2. Run each query for 1, 4, 16, 64, 128, 256 concurrent threads.
3. For each thread perform a warm-up run (duration 180 sec), and then
run three effective runs (duration of each is 60 sec).
As the final result we get a maximal result of three runs.

The raw numbers are available here:
https://www.percona.com/blog/files/benchmarks/innodb-myisam-falcon.html
(Note: This benchmark is synthetic micro benchmarks focusing on particular simple data access patterns. Results for your workload are likely to be different.)

There are interesting results I want to show graphics with comments

READ_PK_POINT
READ_PK_POINT
Query: SELECT name FROM $tableName WHERE id = %d
The very common query with access by primary key.
InnoDB is faster than MyISAM by 6-9%.
Falcon shows very bad scalabilty.

READ_KEY_POINT
READ_KEY_POINT
Query: SELECT name FROM $tableName WHERE country_id = %d
In this case Falcon is the best, because Falcon uses a tricky technic to retrieve rows (more
details with Jim Starkey’s comments in Part 2).
There MyISAM shows bad scalability with increasing count of thread. I think the reason is pread system
call MyISAM uses to access data and retrieving from OS cache is not scaled.

READ_KEY_POINT_LIMIT
READ_KEY_POINT_LIMIT
Query: SELECT name FROM $tableName WHERE country_id = %d LIMIT 5
The same query as previous but with LIMIT clause.
Due to Falcon’s way of key access Falcon cannot handle LIMIT properly and that is why
we see bad performance. We hope the performance of LIMIT queries will be fixed before release.
MyISAM shows stable result.
InnoDB is better than MyISAM by 58% in case with 4 threads, but does not scale good enough.
Perhaps there is still a problem with InnoDB mutexes.

READ_KEY_POINT_NO_DATA
READ_KEY_POINT_NO_DATA
Query: SELECT state_id FROM $tableName WHERE country_id = %d
This query is similar to previous READ_KEY_POINT with only different the values of accessed column is stored in key. MyISAM and InnoDB handle this case and retrive the value only from key.
InnoDB is better by 25-30%.
Falcon needs an access to data beside key access, and most likely this will not be fixed, as this is
specific Falcon’s way to handle multi-versioning. I think this is a big weakness of Falcon, as ‘using index’ is very common optimization we use in our practice.

READ_KEY_POINT_NO_DATA_LIMIT
READ_KEY_POINT_NO_DATA_LIMIT
Query: SELECT state_id FROM $tableName WHERE country_id = %d LIMIT 5
The previous query but with LIMIT.
Again the LIMIT is bad for Falcon.
InnoDB is better than MyISAM by 87% in case with 4 threads but drops down very fast.

READ_PK_POINT_INDEX
READ_PK_POINT_INDEX
Query: SELECT id FROM $tableName WHERE id = %d
Simple but very quick query to retrieve value from PK.
The results for InnoDB and MyISAM are comparable and I think this shows both engines are maximally optimized and the result is maximal that can be reached for this query.
Falcon scales pretty bad and there is a big room for optimization.

READ_PK_RANGE
READ_PK_RANGE
Query: SELECT min(dob) FROM $tableName WHERE id between %d and %d
Access by range of PK values.
MyISAM scales very bad, and reason is the same as for READ_KEY_POINT queries.
InnoDB is better than MyISAM by 2-26 times
and than Falcon by 1.64 – 3.85 times.

READ_PK_RANGE_INDEX
READ_PK_RANGE_INDEX
Query: SELECT count(id) FROM $tableName WHERE id between %d and %d
MyISAM scales good here, because of access only to key column and ‘pread’ syscall is not used.

READ_KEY_RANGE
READ_KEY_RANGE
Query: SELECT name FROM $tableName WHERE country_id = %d and state_id between %d and %d
As in case with READ_KEY_RANGE Falcon is the best here.
Falcon’s resuts better than InnoDB by 10-30%
MyISAM drops down with 128-256 threads

READ_KEY_RANGE_LIMIT
READ_KEY_RANGE_LIMIT
Query: SELECT name FROM $tableName WHERE country_id = %d and state_id between %d and %d LIMIT 50
Again Falcon does not hanle LIMIT and the results are much worse.

READ_KEY_RANGE_NO_DATA
READ_KEY_RANGE_NO_DATA
Query: SELECT city FROM $tableName WHERE country_id = %d and state_id between %d and %d

READ_KEY_RANGE_NO_DATA_LIMIT
READ_KEY_RANGE_NO_DATA_LIMIT
Query: SELECT city FROM $tableName WHERE country_id = %d and state_id between %d and %d LIMIT 50

READ_FTS
READ_FTS
Query: SELECT min(dob) FROM $tableName
The hardest query performs a scan of all million rows.
InnoDB is better than MyISAM by ~30% with 4-16 threads, but MyISAM scales a bit better in this case.
InnoDB is better than Falcon by 2-3 times.

PREVIOUS POST
NEXT POST

Share this post

Comments (119)

  • Moyed Ansari Reply

    Nice Stats, very useful
    Anyways thanks :)

    January 8, 2007 at 12:00 am
  • najdnc Reply

    I clearly think that the data given is relevant to everybody under the sun . Many thanks .
    Locksmith Nashville

    January 8, 2007 at 12:00 am
  • Johan Bergström Reply

    i can’t even check out the sources; it’s been bugging me the entire weekend 🙁

    OK-root OK
    ERROR-BAD CMD: export, Try help

    January 8, 2007 at 2:26 am
  • peter Reply

    As I remember Larry has just changed the protocol, so get new free client here:
    http://www.bitkeeper.com/Hosted.Downloading.html

    January 8, 2007 at 2:50 am
  • David Shrewsbury Reply

    Very good post and very informative. The InnoDB vs. MyISAM performance numbers were just as interesting as the performance of Falcon.

    -Dave

    January 8, 2007 at 6:04 am
  • Vadim Reply

    Johan,

    You need new free client and
    MySQL moved the falcon tree to new root
    bk://mysql.bkbits.net/mysql-5.2-falcon

    But I cannot clone it too:

    ./bkf clone bk://mysql.bkbits.net/mysql-5.2-falcon mysql-5.2-falcon
    ERROR-unable to lock repo for export, try later.

    Perhaps there is a maintenance, and the tree will be available later.

    January 8, 2007 at 7:27 am
  • Xaprb Reply

    I wanted to compare disk usage too. For the same table structure and data, how large is each engine’s data and index file? Do you have this information?

    January 8, 2007 at 8:03 am
  • peter Reply

    Falcon is shy telling its disk usage in SHOW TABLE STATUS:

    show table status\G
    *************************** 1. row ***************************
    Name: normal
    Engine: Falcon
    Version: 10
    Row_format: Dynamic
    Rows: 1000
    Avg_row_length: 0
    Data_length: 10000
    Max_data_length: 0
    Index_length: 0
    Data_free: 0
    Auto_increment: 1000001
    Create_time: NULL
    Update_time: NULL
    Check_time: NULL
    Collation: latin1_swedish_ci
    Checksum: NULL
    Create_options:
    Comment:
    1 row in set (0.00 sec)

    The file size was 354MB which is data + indexes together.

    MyISAM:

    Data_length: 167519584
    Index_length: 132239360

    Innodb:

    Data_length: 195772416
    Index_length: 156794880

    January 8, 2007 at 9:14 am
  • bp Reply

    Interesting results. Obviously Falcon isnt as mature as the other 2 engines. Though I am surprised about how InnoDB is better than MyISAM in a lot of areas. I’m not really informed about this stuff but, do you think MyISAM would perform better on smaller (single proc) machines? I would be interested in seeing how each performs on different machines like single proc, dual proc, and quad proc.

    January 8, 2007 at 9:50 am
  • LenZ Reply

    Thanks for the hint with regards to the updated BK client. I have updated my blog entry on how to compile MySQL from source. However, the locking problem still persists, we are working with the BitKeeper people on resolving this issue.

    January 8, 2007 at 9:51 am
  • pabloj Reply

    Thanks for the great benchmarks!
    Hope Jim will take this into account and work hard on Falcon, as this results are a bit of a “Falcon-killer”
    Also hope that MySQL will set for one or two preferred engines focusing efforts on those, as I see all this storage engine plethora as essentially duplicated efforts and unneeded complexity added, I mean that MyISAM and one of the transactional engines (InnoDB, Falcon, whatever they this is better) should be enough for most cases, leaving SoliDB and other for special cases.
    It would be interesting to run your benchmarks against Firebird/Vulcan to see if and how Jim’s new brainchild improves over the older designs.
    Regards

    January 8, 2007 at 9:52 am
  • LenZ Reply

    Just to let you know: we are aware of the problems with creating a clone with the free BK client and have contacted BitKeeper support to resolve this ASAP. Sorry for the inconvenience.

    January 8, 2007 at 10:13 am
  • </depesz> » Blog Archive » mysql - skalowalność. kolejna odsÅ‚ona Reply

    […] napisaÅ‚em ostatnio o kolejnych testach jakie robili kolesie z tweakers.net. bluszcz wtedy skomentowaÅ‚, że chciaÅ‚by zobaczyć testy postgresa z soliddb lub choćby falconem, a nie z kiepskawym innodb. prosiÅ‚ i ma blog mysql performance przeprowadziÅ‚ testy innodb, myisam i falcona. wÅ‚aÅ›nie pod kÄ…tem skalowalnoÅ›ci. efekt – ogólna, praktycznie caÅ‚kowita porażka falcona. przykÅ‚ady wykres wyników jednego z testów wyglÄ…da tak: przy czym uwaga: nie wybraÅ‚em takiego na którym falcon wyszedÅ‚ najgorzej. sÄ… takie wykresy gdzie linia od wydajnoÅ›ci falcona "leży" na osi. do tego dochodzi jeszcze takie jedno zdanie: "… Falcon cannot handle LIMIT properly …" (wyjÄ™te z kontekstu, ale sens niezmieniony). czekam teraz aż ktoÅ› pokaże testy z soliddb. wtedy też na pewno ja zaprezentujÄ™. […]

    January 8, 2007 at 10:17 am
  • Redwood City Startup » Blog Archive » InnoDB faster then MyIsam? Reply

    […] There’s an interesting post over at the Mysql Performance blog testing performance differences between several storage engines. Their tests show that for some micro benchmarks that cover a lot of the basic usage patterns of databases in a web type environment, that InnoDB can actually be much faster than MyIsam. This goes against the prevailing belief that MyIsam was the fastest for read access especially in the very read heavy world of Web applications and that InnoDb was only used when transactions were required. […]

    January 8, 2007 at 11:11 am
  • Charles Reply

    These numbers are devastating. I fear that they’ll be used as FUD against Falcon when it’s mature and actually performs well.

    That being said, it is interesting to see that InnoDB ends up having equal or better read performance compared to MyISAM. That really changes my perceptions of both of them…

    January 8, 2007 at 11:28 am
  • Vadim Reply

    2 bp:

    I don’t know how MyISAM will perform on single- or dual- CPU boxes in 5.1.14 release,
    at least I expect the scalability will be good enough.

    January 8, 2007 at 1:36 pm
  • peter Reply

    Yes, results are not great for Falcon so far. The worst problem though with LIMIT is already identified and Jim will look into fixing it.

    The good thing is we have now these results early and Jim will have time to look into these.

    Someone can misuse results, which is very frequent with benchmarks results but it is not much you can do about it.

    January 8, 2007 at 2:20 pm
  • Breezes Reply

    Interesting result of Falcon and between MyISAM and InnoDB. However I still think Falcon is helpful, since this test is carried out when all data resides in memory, so the advantage of Falcon’s record cache will not show.

    BTW: Why Falcon needs an access to data beside key access in the READ_KEY_POINT_NO_DATA. I know Falcon use private in-memory caches to hold modified index entries for each update transactions, but I still don’t know why. Could someone be so kind to tell me the reason?

    January 9, 2007 at 2:18 am
  • MySQL Reply

    Results are interesting, especialy MyISAM vs InnoDB.

    January 9, 2007 at 2:36 am
  • peter Reply

    Breezes,

    Actually this should show one of benefits of Falcon record cache – retrieving record from record cache generally should be faster as you do not need to lookup page by row_id and then look for the row on the page itself which could be implemented less efficiently.

    Regarding why Falcon can’t only read data from Index as I understand there are two reasons.

    1) Falcon stores collation values in the index not the data itself which means it is not always to perform reverse conversion and get real data from the index.

    2) Falcon index structure is rather minimal (to keep indexes short) this means you can’t say from index records itself it it should be visible inside current transaction etc.

    I personally thing this is serious matter as I frequently use covering indexes for optimization.

    January 9, 2007 at 3:08 am
  • BOLK Reply

    Very useful. Thank you!

    January 9, 2007 at 7:57 am
  • InnoDB vs. MyISAM vs. Falcon in MySQL | FuCoder.com Reply

    […] InnoDB vs. MyISAM vs. Falcon in MySQL MySQL Performance Blog — InnoDB vs MyISAM vs Falcon benchmarks. Great test and lots of figures and graphs. It highlights two things. (1) Falcon is far from being mature, Jim still got lots to do, but I guess that’s still pretty impressive after 11 months of work (2) MyISAM toasts InnoDB in read performance is a myth. InnoDB rules for now with low concurrency. Eagerly waiting for part II. Tagged in Linky, MySQL | 2007-01-10 11:07 […]

    January 9, 2007 at 6:10 pm
  • Details MySQL’s nieuwe storage engine beschikbaar | Scriptorama Reply

    […] Het populaire MySQL Performance Blog zit er boven op en heeft de eerste benchmarks tussen Falcon, MyISAM en InnoDB alvast online gezet en heeft ook z’n eigen gedachten over het ontwerp van Falcon geplaatst. Gerelateerde artikelen […]

    January 13, 2007 at 2:23 am
  • Aleksey Kishkin Reply

    Hi! Nowadays one million is pretty small number of records for database. Did you try similar benchmarks against, (say) 100 000 000 records? Or – (as we usualy did) against database 3 times bigger than RAM?

    January 15, 2007 at 3:31 am
  • peter Reply

    Alexey,

    Thanks for feedback. Right this is small database and CPU bound benchmark. We did not test IO bound yet as Jim mentioned there are some issues with insert speed at this point plus it will take more time and require a lot of other decisions, such as distribution type etc. We’ll do it as Falcon is closer to production stage 🙂

    January 15, 2007 at 4:21 am
  • Vadim Reply

    Alexey,

    I know you have an experience in benchmarks, so your results against 100.000.000 records are welcome 🙂

    January 15, 2007 at 4:58 am
  • Kee Hinckley Reply

    I’m curious whether you’ve run any benchmarks comparing InnoDB vs. MyISAM when queries are being done at the same time as new row creations. I had that situation a few years ago, and we tried InnoDB on the theory that table-level locking would benefit us. However we didn’t get the improvement we expected. We ended up taking advantage of MyISAM’s ability to do simultaneous select/creates if the table has no holes in it (we deferred all deletions until we could do a compact). That was a somewhat odd case though. The queries were large, but there weren’t a lot of simultaneous ones. Whereas the creates were going on pretty much continuously, and the rows contained several blobs.

    January 16, 2007 at 8:51 am
  • peter Reply

    Kee,

    Innodb may have some issues with auto_increment columns when it comes to inserts. You may have had that problem or it could be something else like suboptimal Innodb configuration or simply much larger Innodb tables so worse memory usage.

    The fact you had blobs is yet another question as Innodb may not be optimal with these.

    As always any benchmarks show performance in particular case – in your case opposite may well be true.

    January 16, 2007 at 8:58 am
  • Mixellaneous Reply

    InnoDB vs MyISAM vs Falcon 벤치마크…

    InnoDB vs MyISAM vs Falcon benchmarks – part 1, http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/Peter Zaitsevê°€ 자신의 블로그에 흥미로운 벤치마크 결과를 올렸다.The second goal of benchma…

    January 17, 2007 at 3:53 am
  • Fishpool Reply

    First thoughts regarding the MySQL Falcon storage engine…

    Unfortunately, just based on reading the Falcon documentation, I must draw the conclusion that without extensive further development, it won’t be usable for very large installations such as the ones we run for Habbo for a number of reasons. I’m usual…

    January 19, 2007 at 11:42 am
  • l1t Reply

    create table tf (id varchar(32),val1 decimal(20,2)) engine=falcon;
    create table tn (id varchar(32),val1 decimal(20,2)) engine=innodb;
    create table ti (id varchar(32),val1 decimal(20,2)) engine=myisam;

    delimiter //
    CREATE PROCEDURE inserttf(p1 int)
    BEGIN
    DECLARE v1 INT DEFAULT 0;
    WHILE v1 set autocommit=on;
    Query OK, 0 rows affected (0.00 sec)

    mysql> call inserttf(5000);
    Query OK, 1 row affected, 5000 warnings (3.27 sec)

    mysql> call inserttn(5000);
    Query OK, 1 row affected, 5000 warnings (2.73 sec)

    mysql> call insertti(5000);
    Query OK, 1 row affected, 5000 warnings (0.30 sec)

    mysql> set autocommit=off;
    Query OK, 0 rows affected (0.00 sec)

    mysql> call insertti(5000);
    Query OK, 1 row affected, 5000 warnings (0.31 sec)

    mysql> call inserttn(5000);
    Query OK, 1 row affected, 5000 warnings (0.25 sec)

    mysql> call inserttf(5000);
    Query OK, 1 row affected, 5000 warnings (0.17 sec)

    mysql> commit;
    Query OK, 0 rows affected (0.01 sec)

    mysql> call insertti(25000);
    Query OK, 1 row affected, 25000 warnings (1.52 sec)

    mysql> call inserttn(25000);
    Query OK, 1 row affected, 25000 warnings (1.25 sec)

    mysql> call inserttf(25000);
    Query OK, 1 row affected, 25000 warnings (0.88 sec)

    mysql> commit;
    Query OK, 0 rows affected (0.03 sec)

    March 11, 2007 at 6:24 pm
  • l1t Reply

    delimiter //
    CREATE PROCEDURE inserttf(p1 int)
    BEGIN
    DECLARE v1 INT DEFAULT 0;
    WHILE v1< p1 DO
    insert into tf values(replace(uuid(),’-‘,”),round(rand()*100,2));
    SET v1 = v1 + 1;
    END WHILE;
    END
    //
    delimiter ;
    delimiter //
    CREATE PROCEDURE inserttn(p1 int)
    BEGIN
    DECLARE v1 INT DEFAULT 0;
    WHILE v1< p1 DO
    insert into tn values(replace(uuid(),’-‘,”),round(rand()*100,2));
    SET v1 = v1 + 1;
    END WHILE;
    END
    //
    delimiter ;
    delimiter //
    CREATE PROCEDURE insertti(p1 int)
    BEGIN
    DECLARE v1 INT DEFAULT 0;
    WHILE v1< p1 DO
    insert into ti values(replace(uuid(),’-‘,”),round(rand()*100,2));
    SET v1 = v1 + 1;
    END WHILE;
    END
    //
    delimiter ;

    March 11, 2007 at 6:39 pm
  • smartgk Reply

    May please define:

    1. What are the major criteria before choosing an Database engine?
    2. Analyse Based on All aspects for all Engines.

    Regards,
    smartgk

    March 20, 2007 at 1:26 am
  • MySQL Performance Blog » PBXT benchmarks Reply

    […] This time I tested only READ queries, similar to ones in benchmark InnoDB vs MyISAM vs Falcon (http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1) The difference is I used new sysbench with Lua scripting language, so all queries were scripted […]

    April 8, 2007 at 12:08 pm
  • Michal Reply

    Hey there,
    I like your site very much, just found it somewhere, really nice and useful!

    Good article, but I decided to post a comment because I’m not really sure what to think.
    Recently we were importing 12GB of data in CSV format via PHP script into database. We used only 1 thread and we had to parse data before inserting into database.

    Each row in the CSV file used 11 queries max (5 selects, 6 insert on duplicate key updates). Using InnoDB on all tables, import took 8 hours, as we switched to MyISAM, import took only 2,5 hour.

    2 largest tables were 5,5mil and 1,4mil entries after import (before empty).
    All selects and on updates were using primary key.

    I’d be interested what made such difference, because I can see that InnoDb should be faster with 1 thread. What would be the performance increase using 3 threads?

    Machine is 4x Xeon, 2GB RAM, although load was only about 1.25 while importing.

    April 9, 2007 at 3:13 am
  • Catalinux Reply

    Hi Michal,

    Please tell me if you have done the followings
    1. set autocommit=0 so you do not commit after each insert. This is the difference between Innodb vs MyIsam
    2. disable index keys (not uniques ones which u might need)

    Catalinux

    April 10, 2007 at 10:56 am
  • Michal Reply

    Hi,

    thank you for your answer!

    1. we didn’t manipulated autocommit, it had default value. I understand what autocommit does, but MyIsam is writing data to disk after each query too, isn’t it?
    I’ll try importing data with autocommit=0 this night…

    2. we use as less indexes as we can. Basically each table has it’s primary id key and then for the smaller table (1.4mil entries) we use algorithm to create non unique integer hash out of string. Cardinality of this index is very low (16%), have to work on better algorithm, possibly unique.

    Btw I’ve heard Jay Pipes saying indexes with cardinality lower than 30% are worthless, true?

    April 10, 2007 at 2:31 pm
  • peter Reply

    Michal,

    For Innodb you are much better of loading data in primary key order.
    Also have Innodb buffer pool large and logs large this helps a lot.

    Transaction commit overhead is rarely the problem because data load transactions are typically large.

    April 11, 2007 at 2:23 am
  • Michal Reply

    Catalinux, Peter,

    thank you for helping me.

    With autocommit off we managed to outperform MyIsam by 10%, but without Peter I would be solving another problem, because our innodb & log buffer was set too low and commit didn’t go through the first time.

    Again thank you guys for your help!

    April 12, 2007 at 1:29 am
  • Bambarbia Kirkudu Reply

    Are you kidding? “Method of benchmark: 1. Prepare table with 1,000,000 records (about 350Mb of data on disk) …”
    – With 16GB of RAM!!!

    SolidDB also has published some tests, unbelievable “short-term” performance of Bonsai Tree, (NOT!!!) linear increase of performance by number of CPU.

    It is really difficult to write good test scripts which can simulate CPU overloading vs. HDD overloading vs. network overloading vs. software bottleneck (blocking threads) etc. Is it possible with PHPTestSuite? WOW!!! Is it multithreaded version of PHP, or pre-fork 😉

    The most important test scenario for the enterprise: maximum number of concurrent users successfully accessing a database with 3 seconds (!!!) response time. Yes, 3 seconds is a standard “acceptable” response time for modern distributed enterprise network applications. 1 second is “excellent”, and 10 seconds is “maximum allowable”.
    “Concurrent users” have a behavior: 2-3 events (mouse clicks) per minute. 20 seconds per decision made.

    For instance, single Apache HTTPD v.2 Worker can support about 20000 concurrent users (2Mhz CPU, 2Gb RAM, 20kb static HTML, mem-cache, keep-alive, …). Can MySQL back-end support 20000 concurrent users making simple SELECTs each 20 seconds and waiting for response 3 seconds?

    April 24, 2007 at 11:44 am
  • Bambarbia Kirkudu Reply

    Hi,

    I performed some tests with InnoDB and SolidDB. InnoDB outperforms (3-4 times faster) SolidDB. I noticed that my load-generator gets overloaded, but InnoDB (different machine) is still 15-20% CPU, and only 2 CPU from 4 are used. With SolidDB, I have equal load (Server + Client), and Server uses 50%-60% of all CPUs. I even disabled logging for SolidDB, still same results.

    InnoDB + UTF8 outperforms SolidDB + UCS2 – that’s unbelievable.

    I published some info in blog, sorry for not having the time to provide all details…
    http://bambarbiakirkudu.blogspot.com/
    Thanks!

    P.S.
    “Load Generator” is very specific; 300 Java Threads concurrently updating database, 100s ‘simple’ select/insert per ‘atomic’ transaction per thread.

    May 21, 2007 at 9:05 pm
  • Bambarbia Kirkudu Reply

    Sorry for typo: I was unable to use SolidDB + UCS2 with JDBC-based client. latin1 must be faster theoretically.
    >>InnoDB + utf8 outperforms SolidDB + latin1 – that’s unbelievable.

    May 21, 2007 at 9:07 pm
  • Vadim Reply

    Bambarbia Kirkudu,

    Thank you for info.
    I would like to see more details about benchmarks.
    Also 300 concurrent threads is not something typical for web-workload.

    May 22, 2007 at 1:41 am
  • Bambarbia Kirkudu Reply

    Hi Vadim,

    I updated blog today with more details. 300 threads are not typical; more typical are 1000 alive connections from Connection Pool (I am primarily Java developer). I set all thread-related numbers on MySQL InnoDB to high numbers; I/O threads = 512… Client application is a standalone Java process running concurrently 300 threads (each one has own connection), it’s not a web application. I even have evenly distributed loading (4 CPUs) on a single-instance MySQL dedicated box.

    I’ll try to perform 1-week crawl with InnoDB, 1-week crawl with SolidDB, and compare results (total number of successfully crawled pages).

    I had a problem with Oracle 10g, daily data corruption (Seagate Barracuda, probably overheated). After moving to Cheetah 15K.5 SAS no any problem during 6 months!!! Hope MySQL performs well; performance is much better than Oracle.

    May 22, 2007 at 9:40 am
  • Bambarbia Kirkudu Reply

    Even better and faster: I can design specific load-stress generator and run it instead; and to tune databases without making noise on Internet 😉 (without crawler).

    May 22, 2007 at 9:47 am
  • Vladimir Reply

    Nice test, nice results. This results have influence on my conclusion MyISAM vs InnoDB. InnoDB win :).

    May 24, 2007 at 12:50 pm
  • Scott Marlowe Reply

    Is it possible to get either the test data set and / or some data relating the selectivity of the various columns to I can try to re-create this test with some accuracy?

    Thanks.

    May 31, 2007 at 1:30 pm
  • Vadim Reply

    Scott,

    You can get sysbench and Lua script from
    http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks
    to generate dataset and load.

    Best,
    Vadim

    May 31, 2007 at 1:55 pm
  • Five months with MySQL Cluster « Ramblings of a web guy Reply

    […] too easy.  We ran a cluster on some dev boxes at first.  We did some generic testing using the PHPTestSuite from the guys at MySQL Performance Blog.  What we found was that while the cluster appeared slower […]

    June 7, 2007 at 10:09 am
  • William Wang Reply

    This test has a fundamental flaw to me. The test is read only. In real world, there are writing actions. Between MyISAM and InNoDB Let say R/W ratio is 10:1. I bet my pay check, you will see very different result (I will expect MyISAM are away better than others). If R/W ratio is 1:10. You may see something totally different from all others. So choose storage fits your needs. My question is how can I convince my boss to trash MS SQL. MS Tortures me :(.

    June 7, 2007 at 5:05 pm
  • Vadim Reply

    William,

    You are right that with Read/Write the result will be different, though I believe Read-only benchmark
    gives initial impression of Storage Engine.

    Read-Write benchmark is much more complex and requires more time to design, run and handle results.
    Complexity does not scare me, nut time is the problem.

    Unfortunatelly I’ve never dealt with MS SQL and moverover never had bosses who love MS SQL, so I am useless here.

    June 7, 2007 at 11:28 pm
  • chunning Reply

    Would you give us some Update test for large table, for example 30,000,000

    June 14, 2007 at 4:25 am
  • Da Man Reply

    The above charts are all nice but there are no write statements and results for write statements. My write test shows what InnoDB is slower than MyISAM when it comes to inserting new rows of data and updating those rows with new/updated information. I have not done any read tests but in my view the InnoDB will be slightly quicker than MyISAM, but only slighty. When it comes to writing data, MyISAM is about 30% quicker.

    July 10, 2007 at 2:07 am
  • Scott Marlowe Reply

    Da Man: When you test MyISAM do you test it with lots of parallel access going on at the same time?

    I think the main advantage InnoDB has is that it’s MVCC locking mechanism allows lots of writes to happen without blocking reads, and vice versa. I.e. it should scale better than MyISAM under parallel load.

    July 10, 2007 at 9:40 am
  • ire Reply

    Hi,
    exactly how could I possibly check to confirm the mysql engine on a given database, is there a command of some sort that could reveal whether or not the engine is innoDB or myISAM? Thanks.

    July 11, 2007 at 2:12 am
  • heiyeluren Reply

    [转]InnoDB vs MyISAM vs Falcon benchmarks – part 1…

    国外一篇关于Mysql存储引擎:InnoDB、MyISAM、Falcon(猎鹰) 的一些测试结果数据,可以明显发现InnoDB的性能已经略有超过MyISAM引擎,至于Falcon的性能就比较一般了,因为刚刚起步的原因。本文就是…

    August 3, 2007 at 6:08 pm
  • Christian Reply

    I have tried to perform some benchmarking myself today, allthough only to see if InnoDB could prove to yield greater performance than MyIsam on my system.

    I had 7 instances of a program set up on one server and basically had them hammer the database-table, first with 50.000 inserts each, and then wait until all inserts were done, and then all 7 programs performed an update on a random row (using primary key) of those inserted.

    And the numbers are so close between InnoDB and MyIsam, the differences is not really noticable, and this puzzles me greatly:
    I was under the impression that MyIsam performed a table-lock on each update, while InnoDB would only lock the row. So I expected InnoDB to win this one easily, not having to wait for the table to unlock all the time. Apparently this didn’t happen!

    Is there any special trick to enable this row-locking, or is it always on and working?

    And why isn’t the MyIsam results showing signs of having to wait for the locked table all the time?

    Are 7 threads simply not enough for innoDB to get the upper hand?

    August 14, 2007 at 4:52 am
  • Mike Reply

    You only had 7 connections which is why your performance between MySQL and Innodb was so close. Try increasing it to 100 threads and then 300 threads. I think you’ll see a difference.

    Mike

    August 26, 2007 at 12:33 pm
  • free ps3 Reply

    Thanks for the useful post!

    September 2, 2007 at 3:55 am
  • Rama Reply

    Need to know whether SolidDB is better/worse than InnoDB. I am evaluating SolidDB ?

    September 4, 2007 at 9:40 am
  • Falcoln in the belly « from Oracle to MySQL Reply

    […] and commentary available from MySQL Performance Blog at InnoDB vs MyISAM vs Falcon benchmarks – part 1 and Falcon Storage Engine Design […]

    September 6, 2007 at 12:13 pm
  • Bambarbia Kirkudu Reply

    Vadim,

    In general: each tool has an area to be applied for, and all ‘universal’ is called ‘horilla’ in MySQL forums: Oracle, DB2. Want to compare test results for a simple query SELECT COUNT(*) FROM …?

    Theoretically, InnoDB is faster than MyISAM (or MyISAM-based transactional SolidDB) for multi-user concurrent access because of physical data files format (in InnoDB, data is written into fixed-size blocks; in MyISAM, data is usually written at the end of file).

    My database currently consists from mixed InnoDB and MyISAM datafiles. I need MyISAM for dictionary-like tables (like as list of countries, cities, postal codes), and I need InnoDB for frequently updated data.

    One weakness: JDBC driver + Prepared Statements.

    Thanks

    September 20, 2007 at 7:12 am
  • azazel Reply

    Try this test SELECT COUNT(*) FROM $tableName;

    October 13, 2007 at 11:05 am
  • RDG Reply

    Any chance for “Part 2” based on more recent releases?

    October 19, 2007 at 12:17 pm
  • Vadim Reply

    RDG

    Yes, We are going to test next release of Falcon

    October 19, 2007 at 12:31 pm
  • Shaun Reply

    Great information.

    I was having trouble deciding between MyIsam and InnoDB. I wanted to create a log for everything that happened on my website, so I created a log table. But…what if a user inserts/updates something and then the PHP script fails before updating the log table?

    I realized that I should use transactions, but unfortunately I had to give up the “speed” of MyISAM for InnoDB. Your benchmarks make me feel much better about my decision. =)

    November 1, 2007 at 5:05 am
  • Jacob Reply

    Hi,

    I measured the performance of InnoDB vs MyISAM for insertion queries for up to 100 threads (see presentation “Measuring MySQL Server Performance for the Sensor Data Stream Processing” at MySQL User Conference 2006. Unless you have very short records (less than 200 bytes) MyISAM outpreforms InnoDB for insertion speed. For the recird sizes between 1KB and 10MB MyISAM is about twice faster.

    November 7, 2007 at 3:46 pm
  • Scott Marlowe Reply

    Inserts by themselves aren’t all that interesting. What is interesting is what happens to 20 reading threads when one inserting thread shows up.

    Or how do reading threads behave when updating threads show up.

    Or when you’ve got say 20 inserting threads, and then you start one long reading thread that hits a lot of data.

    Each of those use cases simulates some kind of real world behaviour.

    100 inserting threads, with no readers simulates a real world behaviour too, so I’m not slamming it. It’s a pretty common behavior in things like petroleum exploration.

    But, the situation where you have mixed selects, updates, and inserts if far more common, and usually far more interesting.

    November 7, 2007 at 4:57 pm
  • Jacob Reply

    I don’t think that statement “inserts by themselves aren’t all that interesting” is correct. What about logging? What if you have sensors writing into a database? Is the database able to keep up? Those are VERY interesting and important cases.

    For me pure reading is not not interesting at all – you have to insert before you read.

    Inserts are much slower than reads, so if you two times slower with inserts your reading speed might be not important – you have to wait for inserts to get your data.

    November 8, 2007 at 9:07 am
  • Scott Marlowe Reply

    QUOTE:
    What about logging? What if you have sensors writing into a database?
    UNQUOTE:

    Um, you did read my whole post, right? I made the point that write only is still used, and an example of petroleum exploration, which is exactly that, sensors writing into the database.

    Either table handler can likely keep up just fine with the insert load. But what happens if insert performance falls 50% on one table handler when a large query runs against your logs, while another table handler drops by only 2%? That’s far more interesting. Or what happens when you have a few small selects against that heavily written table running all the time?

    You ARE going to query the log table at some point, and if you’re like me, you’re likely going to need to query it at the worst possible times, in the middle of the day when the system is acting up. You need to read the logs, and if your table handler has a tendency to explode in sheets of flame when you do that, you really need to know THAT, so you can change table handlers (or databases etc…) before you find out in production. After all, what good would logs be that you can’t read?

    The point I’m making is that the INTERACTION of reads and writes is what makes for an interesting thing to study. The individual bits, just reads, or just writes are a nice baseline. It’s like chemistry class. Water, kinda intersting. Sodium, kinda interesting. Water AND sodium, much much more interesting.

    November 8, 2007 at 9:23 am
  • Christian Reply

    “I realized that I should use transactions, but unfortunately I had to give up the “speed” of MyISAM for InnoDB. Your benchmarks make me feel much better about my decision. =)”

    Allthough using transactions is desirable in many cases, you should also consider calling stored procedures if you are worried about some kind of client-failure, like a php-script crashing etc.
    If all the PHP-script did was to call a Stored Procedure with the required parameters, the crash would not hurt the database-operations.

    A real-world example:
    A typical user-signup process may call several checks, updates and inserts.
    In a php-script, this could look like (pseudo code)
    – Check validity
    – Insert user-data (which can be one or more rows in different tables)
    – Possibly fetch the new “auto-increment” id for the user, and use this to further insert rows in other tables
    – Other logic
    – Check and verify that everything went ok
    – Send feedback to the client

    Here you can easily make a stored procedure that handles everything, from checking, inserting, updating etc.
    The PHP-script would then simply look like
    – Check validity
    – Call the stored procedure with the required parameters
    – Send feedback to the client

    So, you could stick to MyIsam here, and still make sure crashing scripts do not cause problems.

    Just my 2 cents 🙂

    November 8, 2007 at 9:35 am
  • Christian Reply

    “The point I’m making is that the INTERACTION of reads and writes is what makes for an interesting thing to study. The individual bits, just reads, or just writes are a nice baseline. It’s like chemistry class. Water, kinda intersting. Sodium, kinda interesting. Water AND sodium, much much more interesting.”

    Indeed. More often than not, real-word usage consists of reading and writing to the database simultanously, and how one affects the other is of utmost importance. If Storeage-Engine A is faster when inserting data, this means nothing if the speed drops a lot when 30 threads are inserting at the same time.

    This is what makes Benchmarking difficult, and forces us to interpret results carefully.

    November 8, 2007 at 9:38 am
  • runescape money Reply

    The point I’m making is that the INTERACTION of reads and writes is what makes for an interesting thing to study. The individual bits, just reads, or just writes are a nice baseline. It’s like chemistry class. Water, kinda intersting. Sodium, kinda interesting. Water AND sodium, much much more interesting.”

    Indeed. More often than not, real-word usage consists of reading and writing to the database simultanously

    November 24, 2007 at 7:07 pm
  • Boycott Novell » Gaining Advantage Through Acquisitions, Deals, Defections Reply

    […] InnoDB vs MyISAM vs Falcon benchmarks – part 1 Several days ago MySQL AB made new storage engine Falcon available for wide auditory. We cannot miss this event and executed several benchmarks to see how Falcon performs in comparison to InnoDB and MyISAM. […]

    December 22, 2007 at 6:45 pm
  • Nadeem Reply

    Interesting but for selects.
    Can anyone suggest if which engine out of InnoDB and MyISAM should be used for a forum based site?

    December 24, 2007 at 9:41 am
  • karpakavalli Reply

    I can understood how the best is InnoDB from ur practical example.

    January 7, 2008 at 5:55 am
  • Antivirus Reply

    This is what makes Benchmarking difficult, and forces us to interpret results carefully.

    January 7, 2008 at 2:02 pm
  • Cevarief Reply

    Very interesting benchmark. Anyway, when will the InnoDB vs MyISAM vs Falcon benchmarks – part 2 availabe ? I’m very curious to see the progress after 1 year from part 1.

    January 8, 2008 at 9:54 pm
  • Armenian Eagle » MySQL Database Storage Engine: InnoDB vs. MyISAM Reply

    […] to use InnoDB, the best reason is the performance difference. I was reading an article by the MySQL Performance Blog which compared MyISAM, InnoDB and Falcon. First of all, I have never heard of Falcon, so I […]

    January 19, 2008 at 9:54 pm
  • Tomas Reply

    I found nice application stress test at spamassassin
    http://wiki.apache.org/spamassassin/BayesBenchmarkResults

    In this test MyISAM won, anyway quite interesting numbers.

    January 20, 2008 at 5:15 am
  • 環保袋 Reply

    The InnoDB vs. MyISAM performance numbers were just as interesting as the performance of Falcon.

    January 25, 2008 at 10:06 pm
  • MySQL Falcon Storage Engine Enters Beta Stage. | beer planet Reply

    […] alpha for years. Other popular storage engines include MyISAM, InnoDB, which Falcon is supposed to challenge (successfully? :-/), and the upcoming […]

    March 11, 2008 at 11:02 am
  • Edy Ursus Reply

    Thanks for sharing.

    March 17, 2008 at 12:13 am
  • 創盈分類資訊網 Reply

    Results are interesting, especialy MyISAM vs InnoDB.

    April 8, 2008 at 8:54 am
  • ffxi gil Reply

    Try increasing it to 100 threads and then 300 threads. I think you’ll see a difference.

    April 18, 2008 at 10:25 pm
  • MyISAM o InnoDB? | Maza's Cosas Reply

    […] Mas gráficos en http://www.mysqlperformanceblog.com/ […]

    April 22, 2008 at 10:45 am
  • MyISAM vs InnoDB « Developer Days Reply

    […] e integridad referencial. El mito de que MyISAM es siempre más rápido que InnoDB en lecturas no parece ser cierto siempre. Explore posts in the same categories: […]

    May 4, 2008 at 6:16 pm
  • InnoDB vs MyISAM « Developer Days Reply

    […] e integridad referencial. El mito de que MyISAM es siempre más rápido que InnoDB en lecturas no parece ser cierto siempre. […]

    May 17, 2008 at 10:11 pm
  • Renato Reply

    Vadim,
    I only have one question. Which type of MYISAM rows did you use ? Fixed or Dynamic ?
    I am pretty sure that the performance will be completely different when you use one or other !

    Thanks,

    Renato

    May 27, 2008 at 7:52 am
  • forum Reply

    Thank you for information,

    I useing MyISAM!

    May 27, 2008 at 1:28 pm
  • Design Reply

    Once we query the log table we read over the logs. Our table handler did very well with it. For each thread we performed the warm-up run (duration 180 sec), and then ran three effective runs (duration of each is 60 sec). Only problem our final result was much different.

    July 2, 2008 at 12:17 am
  • itix Reply

    Once we query the log table we read over the logs. Our table handler did very well with it. For each thread we performed the warm-up run (duration 180 sec), and then ran three effective runs (duration of each is 60 sec). Only problem our final result was much different.

    August 23, 2008 at 10:27 pm
  • highscalability.com and some funny comments they make… Reply

    […] InnoDB tables are mostly faster than MyISAM. The only thing MyISAM supports is full-text search which is crappy and slow on large datasets anyway. […]

    September 4, 2008 at 2:46 pm
  • runescape money Reply

    InnoDB tables are mostly faster than MyISAM. The only thing MyISAM supports is full-text search which is crappy and slow on large datasets anyway

    September 8, 2008 at 2:24 am
  • MySQL: InnoDB vs MyISAM | vdwaardenburg.nl Reply

    […] used engines are InnoDB and MyISAM. But, what are the advantages of using InnoDB vs MyISAM ? InnoDB seems to be faster, but what are the advantages and disadvantages while using InnoDB or MyISAM […]

    December 5, 2008 at 1:29 am
  • Dexter Reply

    Very intresting, i think i should migrate to InnoDB with my site’s.

    December 27, 2008 at 12:57 pm
  • iGuide Reply

    How about a speed test with a MyISAM-packed table vs InnoDB? InnoDB’s great, but if you’re uploading massive tables back and forth to your server, MyISAM will be less of a hassle due to much smaller files.

    January 9, 2009 at 10:18 pm
  • Andy Reply

    This test is not neutral. MyISAM is disadvantaged from the beginning, since MyISAM is optimized to be used in combination with CHAR fields in contrast to VARCHAR fields. This given, MyISAM is optimized for read access when fixed row size is given.
    To make a statement comparing the InnoDB and MyISAM engine the table has to be set up differently for MyISAM. Then it would be very interesting to see the results especially concerning reads for MyISAM compared to InnoDB and Falcon. Likely MyISAM will beat InnoDB is at least some of the stated queries above.

    April 23, 2009 at 1:02 am
  • viacesi » Archive du blog » Donc Oracle rachète Sun ! Reply

    […] MySQL avait choisi Falcon, une autre technologie en vue de la sortie de la version 6. En terme de performances, Falcon est encore très loin de rivaliser avec InnoDB.Sur Java, Mark Shuttleworth ne croit pas […]

    April 30, 2009 at 12:40 am
  • roga’s blog » MySQL 資料庫儲存引擎的選用 Reply

    […] 我找到一篇文章針對 MyIASM, InnoDB å’Œ Falcon 來做比較,在這裡面 MyIASMå’Œ InnoDB 表現都沒有差很多,唯獨在測 READ_PK_RANGE å’Œ READ_KEY_POINT 時候, MyIASM 爛掉了(不過主角其實是 Falcon 因為它被打趴了)。原因是:There MyISAM shows bad scalability with increasing count of thread. I think the reason is pread system call MyISAM uses to access data and retrieving from OS cache is not scaled. InnoDB vs MyISAM vs Falcon benchmarks – part 1 […]

    June 9, 2009 at 12:29 am
  • SayNoToFlash » 25 Point Basic MySQL Setup/Optimization Checklist Reply

    […] be making a mistake. InnoDB is superior in several areas (Reliability, Backups, Foreign Keys, and Performance in many situations) and while maybe not always the best option (Full Text Indexing), you should know why you’re […]

    July 21, 2009 at 2:29 pm
  • Difference Between InnoDB and MyISAM | Vadim Gabriel Reply

    […] to get a little more information about the performance of the two then there was a benchmark done here that shows some good results. […]

    July 30, 2009 at 12:03 am
  • MPB: InnoDB vs MyISAM vs Falcon | Admon Blog Reply

    […] Posted by Vadim at January 8, 2007, please check its original version here at http://www.mysqlperformanceblog.com […]

    September 11, 2009 at 3:43 am
  • links for 2009-09-11 « Gatunogatuno’s Weblog Reply

    […] InnoDB vs MyISAM vs Falcon benchmarks – part 1 | MySQL Performance Blog (tags: performance innodb falcon mysql scalability) […]

    September 11, 2009 at 6:41 am
  • Eric Reply

    In my case, I need to insert/update 40,000+ rows quite often
    InnoDB will take me around 1 hr
    compare with MyISAM only will take no more than 70 “SECONDS”

    February 9, 2010 at 6:49 pm
  • Alexandre Reply

    Eric, you should open a transaction (BEGIN TRAN) before inserting a large number of rows, them COMMIT.

    February 27, 2010 at 10:38 am
  • ddee Reply

    Falcon attack 🙂

    March 18, 2010 at 4:11 am
  • Dominic Watson Reply

    Can I second 54. Shaun?

    “I realized that I should use transactions, but unfortunately I had to give up the “speed” of MyISAM for InnoDB. Your benchmarks make me feel much better about my decision. =)”

    This is exactly the same thing I was led to believe… I keep thinking… mmm I NEED Transactions but I don’t want to lose the performance! Damn where did I get this idea from? I’ve only started looking into it deeply since MySQL stated they were moving to InnoDB as their default engine and that there are so many myths surrounding MyISAM being a ‘faster reader’ etc.

    Thanks for the great article… now I have to get ahold of your book as I feel there is so much I do not know and I should 🙂

    April 21, 2010 at 6:54 am
  • DostlukVadisi Forum Reply

    Thank you for information,

    I useing MyISAM!

    May 14, 2010 at 8:28 am
  • TRouBLeSHooTeR Reply

    thank you for researching.
    amazing results

    August 17, 2010 at 1:56 am
  • ionut Reply

    Great work but you just can’t compare myisam with innodb without a group by statement and 10 updates/seccond:)

    I wish I could do the test by my core duo is just too slow.

    August 25, 2010 at 1:59 pm
  • Farrukh Mahmood Reply

    hey Vadim,

    You have posted some extremely useful piece of work.
    I appreciate your efforts.
    many thanks.

    October 10, 2010 at 12:07 am
  • developer99 Reply

    My ISAM InnoDB
    Required full text Search Yes
    Require Transactions Yes
    frequent select queries Yes
    frequent insert,update,delete Yes
    Row Locking (multi processing on single table) Yes
    Relational base design Yes

    Hi, I have briefly discuss this matter by table so you can conclude which has to be chosen either innodb or MyISAM.
    http://developer99.blogspot.com/2011/07/mysql-innodb-vs-myisam.html

    July 22, 2011 at 2:51 pm
  • Mike Reply

    If we extrapolate many of the graphs it looks like 1024+ threads may start causing problems. So a bit shortsighted of the person doing the benchmarks not to test up the number of threads that appear useful. At least people can then decide which table engine is best based on the estimated number of threads for their application.

    March 4, 2012 at 4:23 pm
  • Jenna Reply

    I prefered use InnoDB

    March 22, 2012 at 9:43 pm
  • Himanshu Reply

    According to http://www.rackspace.com/knowledge_center/article/mysql-engines-myisam-vs-innodb if you use char instead of varchar in the table schema, MyISAM will perform better than InnoDB

    April 9, 2014 at 4:33 am
  • free stuff Reply

    This is what makes Benchmarking difficult, and forces us to interpret results carefully.

    May 10, 2015 at 7:05 am

Leave a Reply