One major problem in terms of MySQL performance that still stands in the way of InnoDB scalability is the trx_list scan on consistent read view creation. It was originally reported as a part of MySQL bug #49169 and can be described as follows. Whenever a connection wants to create a consistent read, it has to [...]
trx descriptors: MySQL performance improvements in Percona Server 5.5.30-30.2
April 12, 2013 By 2 Comments
Mystery Performance Variance with MySQL Restarts
February 20, 2013 By 18 Comments
Based on a lot of surprising comments about my MySQL 5.5 vs 5.6 performance post I decided to perform deeper investigation to see where my results could go possibly wrong. I had set up everything to be as simple as possible to get maximally repeatable results. I did Read Only ran which is typically a [...]
Is MySQL 5.6 slower than MySQL 5.5?
February 18, 2013 By 23 Comments
There have been a number reports/benchmarks showing MySQL 5.6 to be slower than MySQL 5.5 on variety of workloads. There are many possible reasons and I believe we will learn about many of them in the next few weeks and months as MySQL 5.6 is starting to get production battle-tested and there is inflow of [...]
InnoDB’s gap locks
March 27, 2012 By 15 Comments
One of the most important features of InnoDB is the row level locking. This feature provides better concurrency under heavy write load but needs additional precautions to avoid phantom reads and to get a consistent Statement based replication. To accomplish that, row level locking databases also acquire gap locks. What is a Phantom Read A [...]
Multiple purge threads in Percona Server 5.1.56 and MySQL 5.6.2
May 3, 2011 By 13 Comments
Part of the InnoDB duties, being an MVCC-implementing storage engine, is to get rid of–purge–the old versions of the records as they become obsolete. In MySQL 5.1 this is done by the master InnoDB thread. Since then, InnoDB has been moving towards the parallelized purge: in MySQL 5.5 there is an option to have a [...]
Innodb undo segment size and transaction isolation
January 12, 2011 By 3 Comments
You might know if you have long running transactions you’re risking having a lot of “garbage” accumulated in undo segment size which can cause performance degradation as well as increased disk space usage. Long transactions can also be bad for other reasons such as taking row level locks which will prevent other transactions for execution, [...]
Effect from innodb log block size 4096 bytes
January 3, 2011 By 19 Comments
In my post MySQL 5.5.8 and Percona Server: being adaptive I mentioned that I used innodb-log-block-size=4096 in Percona Server to get better throughput, but later Dimitri in his article MySQL Performance: Analyzing Percona’s TPCC-like Workload on MySQL 5.5 sounded doubt that it really makes sense. Here us quote from his article: “Question: what is a [...]
Reasons for run-away main Innodb Tablespace
June 10, 2010 By 2 Comments
So you’re running MySQL With innodb_file_per_table option but your ibdata1 file which holds main (or system) tablespace have grown dramatically from its starting 10MB size. What could be the reason of this growth and what you can do about it ? There are few things which are always stored in main tablespace – these are [...]
READ-COMMITED vs REPETABLE-READ in tpcc-like load
February 11, 2010 By 6 Comments
Question what is better isolation level is poping up again and again. Recently it was discussed in InnoDB : Any real performance improvement when using READ COMMITED isolation level ? and in Repeatable read versus read committed for InnoDB . Serge in his post explains why READ COMMITED is better for TPCC load, so why [...]
Paul McCullagh answers your questions about PBXT
November 20, 2009 By 2 Comments
Following on from our earlier announcement, Paul McCullagh has responded with the answers to your questions – as well as a few I gathered from other Percona folks, and attendees of OpenSQL Camp. Thank you Paul! What’s the “ideal” use case for the PBXT engine, and how does it compare in performance?  When would I [...]
