__ 1. Disks

The fundamental battle in a database server is usually between the CPU(s) and available disk I/O performance; 
we'll discuss memory momentarily. The CPU in an average server is orders of magnitude faster than the hard disks. 
If you can't get data to the CPU fast enough, it must sit idle while the disks locate the data and transfer 
it to main memory...

__ 2. Memory

To bridge the gap between blazingly fast CPUs and comparatively slow disks, we have memory. With respect to 
performance, it's in the middle - significantly faster than disks but still much slower than the CPU. The 
underlying operating system generally uses free memory to cache data read from and written to disk. That 
means if you frequently query the same small MyISAM table over and over, there's a very good chance 
you'll never touch the disk. Even though MySQL doesn't cache row data for MyISAM tables (only the index blocks), 
the entire MyISAM table is likely in the operating system's disk cache. 

__ 3. MySQL's buffers and caches

By adjusting how much memory MySQL uses, you can often realize significant performance improvements. 
To do that effectively, you first need to understand how MySQL uses memory. Most of the memory MySQL 
allocates is used for various internal buffers and caches. These buffers fall into two major groups: 
global buffers and per-connection buffers. As their name implies, global buffers are shared among 
all the connections (or threads) in MySQL.

__ 4. Network

The performance of your network usually doesn't have much bearing on MySQL. In most deployments, 
clients are very near the servers - often connected to the same switch - so latency is low, and 
available bandwidth is quite high. But there are less common circumstances in which the network 
can get in the way.

__ 5. Threading

As a multithreaded server, MySQL is most efficient on an operating system that has a well implemented threading 
system. Windows and Solaris are excellent in this respect. Linux, as usual, is a bit different. Traditionally, 
Linux has had a slightly unusual threading implementation - using cloned processes as threads. It performs 
well under most circumstances, but in situations with thousands of active client connections, it imposes a 
bit of overhead.

__ 6. Caching

If your queries are already optimized and using the most efficient indexes, it's still possible to run into 
I/O bottlenecks at some point. Simply running too many queries, no matter how efficient they are, can become 
too much for the disk(s) to keep up with. If so, it's time to consider caching. The easiest thing to do is 
make sure you're using the MySQL query cache. Available since MySQL 4.0, the query cache keeps the results 
of frequently executed SELECTs in memory so that MySQL doesn't need to perform any disk I/O at all. Taking 
things a step further, you might consider application-level aching. If there's data that doesn't change 
frequently at all, query for it once in a while and store it in memory or on local disk until you requery for it.

And more...

__ Features that Contribute to Fast MySQL Performance
(question: are you taking advantage of these features in your DB design?)

Query Cache - besides the standard SQL/data/index/log caches offered by other database vendors, 
MySQL provides a unique query cache that has the potential to substantially increase overall response time, 
especially if identical queries are repetitively issued. If enabled, MySQL retains not only the SQL 
query that was issued, but also the query's result set. This differs from just keeping the query 
and the raw data in memory, as MySQL does not have to re-produce the result set each time. 
This results in a dramatic decrease in logical and physical I/O and a near instantaneous response time rate. 

Robust Indexing Choices - MySQL provides standard B-tree indexing as well as support for Clustered, G
eospatial, Hash, Sparse, and Full-Text indexes. Key to any fast database system is good index design, 
and MySQL does not disappoint with respect to providing numerous choices for indexing a table. 

Fast Data Load Options - MySQL serves as the backend for receiving huge volumes of information for many 
customer installations. Few database systems offer the type of write performance as MySQL. This can be 
contributed to things like MySQL's unique multi-insert statement capability, the Archive storage engine 
(which is the fastest engine in MySQL when it comes to data load performance), a parallel load utility,
and other miscellaneous features. 

High-Speed Connection Pool - applications that serve high volumes of concurrent users will benefit 
from MySQL's server-side thread pools and connection thread caching. These features allow for the 
fast establishment of incoming user connections so that a user's work can immediately be carried out. 

Main Memory Data Access - as has already been mentioned, MySQL offers a number of different storage 
engines, two of which offer continuous main memory access to data. While data caches exist for the 
majority of core MySQL storage engines, the Memory storage engine and the NDB Cluster storage engine 
offer the ability to guarantee a table's information is always in RAM for the fastest possible access. 

Easy Scale-Out Implementation - many MySQL customers create scale-out architectures that partition and 
load balance workloads across many commodity servers. MySQL's incredibly easy-to-use and reliable 
replication mechanisms are used to scale performance so that no workload becomes too great to handle.

__ Performance 5.0 vs 4.1

The following TM1 benchmark was run against MySQL 4.1 and 5.0, on an Intel P4, 2.8 GHz, 1G RAM 
machine using the InnoDB storage engine (both 5.0 and 4.1 with the same settings), 10 clients and 
500K subscribers, using a connection through ODBC. The final end result was: 

Maximum Qualified Throughput (MQth) 
MySQL 4.1:				416.5 
MySQL 5.0:				554.6 
Improvement in 5 vs.4:		33%