Had an interesting situation come up today with a client. We had a situation where a server crashed because it ran out of memory. The calculation we used to monitor memory usage did not take into account all factors. When looking at this, I noticed a couple of things:\tThere are numerous calculations available online.\tIt seems that none of them take everything in account.Wouldn't it be nice if there was a total possible memory consumption status value? It can be a valuable piece of information. (And while I am requesting things, what about peak memory usage by the mysqld server since it has been online?) Realistically, there is almost no case where you would actually use the maximum amount of memory. But knowing how much memory that MySQL server could possibly use would be a very useful bit of information to know.Second, why isn't there an "official" formula that actually shows everything? It's easy to forget things.  []

If you are using InnoDB Hot Backup utility and the innobackup.pl wrapper script, be very careful if you are not running backups under the system "mysql" user. There is a bug which causes InnoDB Hot Backup to sometimes report a successful backup when it actually failed.

MySQL 5.1.38 includes the InnoDB plugin. This article shows how to install the plugin, using MySQL Sandbox and the binary snapshots.

In this sample chapter from MySQL Tutorial, published by MySQL Press, authors Luke Welling and Laura Thomson explain the basics of transactions, and how the InnoDB storage engine can be used to achieve ACID compliance.(2004-08-11)

How to copy InnoDB table to different database.

This session describes investigations into performance and scalability of InnoDB when using the binlog for replication, focusing primarily on the replication master. The session will highlight tools and techniques used to reveal scalability bottlenecks within the MySQL and InnoDB code, approaches used to eliminate those bottlenecks, and current results. The discussion will focus on a current prototype patch that achieves substantial throughput increases for read/write workloads, and enables concurrent commits for InnoDB XA transactions. - Note that the video must be downloaded to be able to view it!

Tim Cook from Sun Labs explains issues and opportunities with locking in InnoDB. - Note that the video must be downloaded to be able to view it!

This session describes investigations into performance and scalability of InnoDB when using the binlog for replication, focusing primarily on the replication master. The session will highlight tools and techniques used to reveal scalability bottlenecks within the MySQL and InnoDB code, approaches used to eliminate those bottlenecks, and current results. The discussion will focus on a current prototype patch that achieves substantial throughput increases for read/write workloads, and enables concurrent commits for InnoDB XA transactions. - Note that the video must be downloaded to be able to view it!

Tim Cook from Sun Labs explains issues and opportunities with locking in InnoDB. - Note that the video must be downloaded to be able to view it!

The goal of this session is to introduce users to new standard conforming and engine-neutral implementation of foreign keys, which is being developed for 6.1 version of server. The session will describe capabilities of this new implementation (including limitations for different engines), give a glance at its performance and provide comparison with current InnoDB-specific implementation.

Ever get frustrated because you can't enforce foreign key constraints between partitioned tables? Perhaps you'd like the ability to spread innodb partitions across multiple file systems / directories? During this session, we'll be looking at creative ways to use Triggers to get around a few of those annoying limitations, and what kind of impact they might have on your application in production.

The InnoDB storage engine has been modified to use memcached as a level 2 cache, the InnoDB buffer pool being the level 1. Important reduction of the disk load and performance boost has been observed. This opens a new way of scaling out MySQL.

The Falcon Storage Engine is designed to take advantage of multi-core computers. It is reaching GA at a time when computer performance is being increased mostly by adding more cores. Falcon's unique characteristics will be explained and contrasted with InnoDB and other MySQL storage engines.

This presentation describes InnoDB on-disk file formats, the new file format management, as well as InnoDB source code structure.

InnoDB is well-known and popular, but naturally there's room for improvement. There are many hard-coded constants – what happens if we turn them into command-line parameters? InnoDB is also incredibly complex, with a lot going on under the covers. What algorithms can we change to make InnoDB faster and more scalable, especially on modern hardware?