Ooops! Mark Callaghan of Google is one of world’s experts in InnoDB, and a frequent blogger on its performance characteristics. The InnoDB Plugin 1.0.3 is much more scalable on multi-core systems because of the contributions he has made (along with Ben Handy).

Mark will deliver a keynote the on Google’s use of MySQL and InnoDB on Tuesday morning at the MySQL Conference, and another talk on Wednesday. As Mark says, “Although Innodb is not in the title, it is prominent in both of the talks I will do”:

• This is not a web app – the evolution of a MySQL deployment at Google Tues, 9am
• …

That should read “Talks, Talks, Talks” … There will be several presentations by InnoDB experts at the upcoming 2009 MySQL Conference and Expo. Whether you’re a newbie or an experienced DBA deeply familiar with InnoDB, you won’t want to miss these important talks about InnoDB:

• Innovative Technologies for Performance and Data Protection by Ken and Heikki, Tues, 11:55am
• Crash Recovery and Media Recovery in InnoDB by Heikki, Wed, 2pm
• InnoDB Internals: InnoDB File Formats & Source Code Structure by Heikki and Calvin, Wed, 5:15pm
• …

InnoDB executes a lot of transactions for MySQL users. And users and technical experts in the InnoDB community exchange lots of information about InnoDB … transacting in ideas … all the time. A great opportunity to participate in some of these transactions is the upcoming MySQL Conference and Expo.

Does your InnoDB-based application need more transactions to execute more quickly and reliably? Come hear these noted speakers present information that can help you get the most out of InnoDB:

• Distributed InnoDB Caching w/memcached — Matthew Yonkovit & Yves Trudeau (MySQL), Tue 2pm
• InnoDB database recovery techniques — Peter Zaitsev (MySQL Performance Blog), Wed 3:05pm
• …

My previous blog entry on MySQL scalability on the T5440 is now completed by a Sun BluePrint that you can find here.

See you next time in the wonderful world of benchmarking....

Well I am still not happy with a lot of the code, but I have had some people ask me to help test my attempt at a new MySQL benchmark. So I cleaned up the code a bit and pushed what I had to LaunchPad. It’s way to early for this to be ready for prime time, I am using it to stress flash, but as I do i am still finding issues, so use at your own risk. My goal is to make this more generic and allow user customizable SQL files to be loaded in…. something like:

1 | select * from table where a =?  |  rand | a | 1000
2 | select * from table1,table2 where table1.id=table2.id and c = ? and d=? | rand,1-200 | c,d | 10

This would mean execute query #1 , using a random value from a 1000 times in a loop before exiting… and then execute query 2, 10 times using a rand value from c, and a value between 1-200 for d….

But that is a ways off.

For now I support 4 tests which are hard coded in:

mx = mixed wokload of …

My previous blog entry on MySQL scalability on the T5440 is now completed by a Sun BluePrint that you can find here.

See you next time in the wonderful world of benchmarking....

My previous blog entry on MySQL scalability on the T5440 is now completed by a Sun BluePrint that you can find here.

See you next time in the wonderful world of benchmarking....

How many fat marathon runners do you know? I have yet to see anyone run the Boston marathon who looks like me. What about a fat man competing in the 100 yard dash in the the Olympics? no? It seems to make sense then that maybe a fat/bloated index or primary key may not be able to compete for the performance crown.  As you may have read,  One of my common performance mistakes is using incorrect or bloated datatypes in your table design ( shameless plug: stop by the MySQLCamp unconference at the UC and hear me babel on about common PT mistakes). Unfortunately even wise datatype selection can result in suboptimal indexes. Raise your hand if you have heard someone tell you not to use a char/varchar as a PK in innodb?

Not everyone has. Two weeks in a row makes a trend, and a trend means I should probably blog about this. Ran into a pair of clients who are using char/varchar primary key fields in Innodb. I strongly urge my clients …

Yesterday I posted on the curse of the autocommit when using jdbc, but as sholmi commented you can also see a ton of “show variables”  statements as the connector J tries to figure what settings the database is using.   I have seen this before as well and  you can reduce these calls as well, to do so try setting the cacheServerConfiguration paramter to true, which caches the variables instead of rechecking.  The official doc says:

“Should the driver cache the results of ‘SHOW VARIABLES’ and ‘SHOW COLLATION’ on a per-URL basis?”

In my travels I do a lot of analysis of the slow query and the general query logs. In many Java shops I end up seeing the most frequently called command is

set autocommit=1;

Sometimes this statement is called 300-400x more then any other statement. What’s surprising to most of these shops, is that they are leaving autocommit on… so logically they are baffled why the statement is appearing over and over again. You see by default the autocommit statement wraps the calls to the database. So if you trace the calls you will see:

set autocommit=1;
select * from sometable
set autocommit=1;

Yep, even select statements see this behavior. So what, Its a small set statement right? . But that small set statement has to traverse the network, be parsed, be executed, then return something. Lets assume that adds 2ms to your transaction, over the course of a day that’s going to really add up. Over a million queries that …