Comments on: Should you move from MyISAM to Innodb ?

By: Ernesto Vargas

Ernesto Vargas — Wed, 27 Apr 2011 17:00:06 +0000

@jayaram…

Do a SHOW VARIABLES and make sure have_innodb say YES. Then do an ALTER TABLE ENGINE INNODB and you will be it.

How many queries are getting stuck on with table level locking at peak time? With Innodb you will no have that problems since its ACID complaint.

By: jayaram

jayaram — Wed, 27 Apr 2011 16:21:24 +0000

I am working with one table it contains 30million entries about 3GB, which is MyISAM engine.
And my application uses this table as so many of read and writes with in 1sec.

Problem is most of queries in locking stage, i.e problem with table level locking.

Can i move to InnoDB ? , What are the -ve and +ve things..

Could you please help me………………

By: Sam

Sam — Thu, 24 Mar 2011 23:45:07 +0000

I am a native speaker and I understood it, but it was painful to read. Good work on publishing the info, and don’t mind the grammar police, they are just French descendants.

By: RamAM

RamAM — Fri, 11 Mar 2011 18:34:32 +0000

Solid article Peter.
FYI I’m not a native English speaker and I had zero problem understanding your article. Also if I had trouble understanding it I would consider that my problem not the universe’s and not yours

cheers

By: Dale Lancaster

Dale Lancaster — Wed, 02 Feb 2011 02:55:10 +0000

Eric, what do you mean InnoDB doesn’t develop overhead like MyISAM? We run it all the time and see no overhead/slowdown and we are talking millions of rows. Just curious the full thought behind the statement.

thanks

dale

By: Eric Gillette

Eric Gillette — Wed, 02 Feb 2011 02:12:49 +0000

Well, in my experience, performance-wise on a website that is run by a database, or where parsing occurs using SSI which is pulling information from an InnoDB as opposed to MyISAM is a major difference. I’ve noticed much faster response with InnoDB as opposed to MyISAM — plus InnoDB doesn’t develop overhead like MyISAM does. But. . .that’s just my opinion!

I can say for sure that as a PHP developer, I will be releasing ALL of my apps from now on with InnoDB assumed, and MyISAM as backup support if InnoDB doesn’t exist on the server. . .

By: DotCom

DotCom — Mon, 03 Jan 2011 21:31:37 +0000

I laughed the other day, reading on daniweb how “myisam” is faster than “innodb”. Maybe the need some kind of literature to clear their mind. myisam is for people who don’t know what they are doing, saying: “ok, i’ll just go with default”

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

InnoDB is even faster nowadays.

By: incognito

incognito — Wed, 10 Nov 2010 11:46:03 +0000

@Bacon Legs
If you are so sensitive to English, maybe you should skip more than half of the www, not only this article. If you would have learned some other languages (other) than English, you wouldn’t be so academic and sniffy and you would have understood what Peter wrote.

By: Bacon Legs

Bacon Legs — Sun, 07 Nov 2010 02:00:52 +0000

I really wish I could understand more than 60% of this article. PLEASE have a native English-speaker translate what the hell you are trying to say. It’s almost as annoying to read as it is to see you tell people in the comments to “skip the intelligible parts” – if you’re too important to take the time to write proper English, how about writing your articles in another language?

By: MikeTrest

MikeTrest — Mon, 01 Feb 2010 15:42:58 +0000

Business Continuity / Disaster Recovery using InnoDB? We use an internal process based on mysqldump and innodb file-per table.
Our “Database File-Per-Table Archives” web site summarizes like this: “31 Hosts 90 Databases 2919 Tables 91 Dates 354456 Backup Files”

The 31 Hosts are the Master hosts only. Add another 67 slaves in groups replicating upto 6 slaves machines per group. Largest instances top out at approx 60M rows. Most tables are < 0.5M rows. Some applications use MyISAM with partitioned tables. Since every machine is a dedicated instance, mixing engines is not an issue. All DBs are fronted by memcached machines (64 instances). All applications are written to use memcache before hitting DB. We use RAID0 with multiple disks on all SLAVES. MASTER machines use RAID5. Ratio of reads-to-writes is 7,000-to-1. Collectively, about 600M DB transactions per day after peeling off 78% of the reads on the memcaches.

Any table can be selected from the backup archive with a couple of clicks to choose date,table, and host instance. It can be restored to a master with a few more clicks by appropriately authorized DBA. For failures on a MASTER, we do a quick shift and make one of the slaves the new master. We then repair/reload the new master and SYNC it from one of the slaves before switching it back to MASTER. Slaves are simply rebuilt and added back to the mix when their SYNC is completed. Therefore, the HUGE/SLOW restore of large InnoDB tables is not an issue,

My suggestion to use all the tools and techniques available to you, icrease the use of MASTER-SLAVE replication, and use file-per-table management. Then restore-from-backup can be done a comfortable pace.