Throughout the chapters, this book has tried to illustrate how a host of complex and interrelated design, development, and configuration decisions ultimately determine MySQL's performance in your environment. These judgments are made by a wide variety of individuals, including database designers, developers, and administrators, and span the entire life cycle of your MySQL based solution.
Changes in one category can potentially ripple through the complete MySQL environment, often causing unanticipated side effects. This is one key reason that performance tuning is an art, rather than a science. The balance of the book looks at multifaceted case studies that embody this reality.
As with all of the other examples, the goal is to keep these case studies as uncluttered and simple as possible. This means that the illustrations are far cleaner than in the real world. Nevertheless, we always strive to communicate the underlying lessons in each case study.
One area in which the case studies do closely mimic the real world is in the solutions section. In reality, database designers, developers, and administrators typically face many choices when designing, developing, deploying, and tuning their MySQL-based solution. It's not easy knowing which path to follow. To help illuminate this problem, several of the examples include multiple potential actions. In fact, some of these actions conflict with each other: Your only choice is to make the best-educated selection possible, and then carefully monitor your results.
In terms of how to proceed through the section, note that every case study can stand alone; there are minimal interrelationships among them. However, you'll find several associated problems within each case study, just as real-world performance difficulties seem to come in groups.
To get the most from these case studies, look at each one separately, and try to come up with a holistic solution. See if your performance fixes match those suggested by the book.
