
I've completed an initial round of testing InnoDB with data compression and the results are extremely promising. The testing was performed by setting up two shadows of a production database...

At the end of this note I describe how InnoDB can be much faster (2.5X) for high-concurrency workloads. However, what we really did is improve the code to not get 2.5X slower. InnoDB uses innodb_thread_concurrency to limit the number of threads that run concurrently...

InnoDB uses background threads to handle readahead (prefetch) requests. Requests are generated when it detects sequential or random access to most blocks in an extent. This is described in the 5.0 MySQL manual with new behavior in the plugin...

We have servers that run with innodb_log_file_size=256M and some of these servers do a lot of disk writes per second...

I am Domas Mituzas, and I have just joined Facebook MySQL team. I've been working at MySQL Support before, as well as did Wikipedia data and performance engineering on my free time - and I've blogged about that a bit...

InnoDB uses a 16kb page by default. I want to know whether performance improves with an 8kb database page for my workload. Two servers were setup to run a mirror of the production database workload. One used 8kb InnoDB pages and the other used 16kb...

I was debugging a server that had too many concurrent queries. From SHOW INNODB STATUS output, there were many long running transactions with uncommitted work and there were many more transactions blocked on InnoDB locks...

Hello. I'm Ryan Mack, a new member of the Facebook MySQL team. My first order of business is evaluating MySQL 5.1 and the new InnoDB plugin. So far things look very promising, but I came across one issue worth sharing...

My hack of the day for Tuesday was to add the my.cnf option innodb_mmap_buffer_pool that specifies the name of a directory in which a file is created. The file provides the buffer pool memory allocation when opened with mmap...

I pushed more changes to the Facebook patch on Launchpad. These include replacing SHOW TABLE_STATISTICS with an information_schema table, adding the option time_query_overhead to enable/disable the use of extra timers for performance monitoring and adding an option to measure more mutex contention...

Harrison and Konstantin (Kostja) did not like my plan for making FLUSH TABLES WITH READ LOCK faster and suggested an alternative that is non-blocking and faster. The new syntax is as beautiful as the one it replaces -- START TRANSACTION WITH CONSISTENT INNODB SNAPSHOT...

How important is page size matter for an IO-bound load? For this note results are limited to a disk-based server. InnoDB uses a 16kb page and you can recompile it to use an 8kb page. After making a few changes to it, I was able to use 4kb pages but I am not sure if that is safe to use in production...

I deployed a mysqld binary with support for show table_statistics and quickly realized I need to improve it by replacing the column Rows_changed with the columns Rows_updated, Rows_deleted and Rows_inserted. I also need to support this as a table in the information_schema...

Does a query with FORCE INDEX reduce the overhead from query optimization? For me it did not when using sysbench. I configured sysbench to only do primary key lookup queries and ran it with the client and mysqld on the same server...








