Optimization Overview; Mysql Design Limitations And Tradeoffs; Designing Applications For Portability - Oracle 5.0 Reference Manual

8.10.8. Replication Slave Connection Thread States ........................................................... 742
8.10.9. MySQL Cluster Thread States ................................................................................ 743
This chapter explains different ways to optimize MySQL and provides examples. Optimization is
a complex task because ultimately it requires understanding of the entire system to be optimized.
Although it may be possible to perform some local optimizations with little knowledge of your system or
application, the more optimal you want your system to become, the more you must know about it.

8.1. Optimization Overview

The most important factor in making a system fast is its basic design. You must also know what kinds
of processing your system is doing, and what its bottlenecks are. In most cases, system bottlenecks
arise from these sources:
• Disk seeks. It takes time for the disk to find a piece of data. With modern disks, the mean time
for this is usually lower than 10ms, so we can in theory do about 100 seeks a second. This time
improves slowly with new disks and is very hard to optimize for a single table. The way to optimize
seek time is to distribute the data onto more than one disk.
• Disk reading and writing. When the disk is at the correct position, we need to read the data. With
modern disks, one disk delivers at least 10–20MB/s throughput. This is easier to optimize than seeks
because you can read in parallel from multiple disks.
• CPU cycles. When we have the data in main memory, we need to process it to get our result. Having
small tables compared to the amount of memory is the most common limiting factor. But with small
tables, speed is usually not the problem.
• Memory bandwidth. When the CPU needs more data than can fit in the CPU cache, main memory
bandwidth becomes a bottleneck. This is an uncommon bottleneck for most systems, but one to be
aware of.

8.1.1. MySQL Design Limitations and Tradeoffs

When using the
readers or a single writer. The biggest problem with this storage engine occurs when you have a
steady stream of mixed updates and slow selects on a single table. If this is a problem for certain
tables, you can use another storage engine for them. See
MySQL can work with both transactional and nontransactional tables. To make it easier to work
smoothly with nontransactional tables (which cannot roll back if something goes wrong), MySQL has
the following rules. Note that these rules apply only when not running in strict SQL mode or if you use
the
IGNORE
• All columns have default values.
• If you insert an inappropriate or out-of-range value into a column, MySQL sets the column to the
"best possible value" instead of reporting an error. For numeric values, this is 0, the smallest possible
value or the largest possible value. For strings, this is either the empty string or as much of the string
as can be stored in the column.
• All calculated expressions return a value that can be used instead of signaling an error condition. For
example, 1/0 returns NULL.
To change the preceding behaviors, you can enable stricter data handling by setting the server SQL
mode appropriately. For more information about data handling, see
with Constraints",

8.1.2. Designing Applications for Portability

Because all SQL servers implement different parts of standard SQL, it takes work to write portable
database applications. It is very easy to achieve portability for very simple selects and inserts, but
storage engine, MySQL uses extremely fast table locking that permits multiple
MyISAM
specifier for or UPDATE.
INSERT
Section 5.1.7, "Server SQL
Optimization Overview
Modes", and
640
Chapter 14, Storage Engines.
Section 1.8.6, "How MySQL Deals
Section 13.2.5, "INSERT Syntax".