MySQL文檔翻譯（八）附英文原文---性能優化概覽

優化概述

數據庫性能表現依賴於數據庫級別的幾個因素，好比表，查詢和配置設置。這些軟件在硬件級別經過CPU和IO操做構築結果，你須要儘量的使用最少的資源達到最大的效果。當你專一於數據庫的性能表現時，你應該學習數據庫的高級規則和指南，而後以實際執行時間來度量數據庫性能。你想成爲專家的話，你應該進一步學習在MySQL內部都發生了什麼，而且開始以CPU週期和IO操做來度量數據庫的性能了。

大多數用戶都千方百計的經過現有的軟件和硬件配置來或者數據庫的最好性能，再高級點的用戶則嘗試找機會去改進MySQL軟件自己，或者開發它們本身的存儲引擎和硬件設施以此來擴展MySQL系統。

*）在數據庫級別優化

*）在硬件級別優化

*）平衡移植和性能

1、在數據庫級別優化

讓數據庫運行更快的最重要的因素就在它的基本設計之中：

1）表結構是否設計合理？特別是表子段被設計成正確的數據類型，還有每一個表是否都有合適的類型的子段？好比，應用程序常常處理頻繁的更新，可是卻要更新多張子段不多的表。再如應用程序要解析大量的數據，可是這些數據一般只分布在不多的表中，但表的字段卻不少。

2）索引設置是否得當，它有沒有起到應有的效果？

3）你是否爲每一個表都設置了合適的存儲引擎，而且充分利用了這個存儲引擎的優點和特色？特別是，選擇事務型存儲引擎例如InnoDB或者非事務型存儲引擎MyISAM可能對性能和可擴展性很是重要。

注意：

InnoDB是你建立新表時的默認引擎。實際上，改進型的InnoDB的表現特性意味着InnoDB表一般要比與之相似的MyISAM表性能要好，尤爲是那種業務量大的數據庫。

4）你是否爲每一個表都使用了合適的行格式？這個選擇一樣依賴於你爲數據表選擇的存儲引擎。特別是，壓縮表以使數據用的磁盤空間更少這樣就能夠用更少的I/O去讀寫數據。壓縮功能對於任何類型的InnoDB表和MyISAM表都是可用的。

5）應用是否使用了合適的鎖機制？例如，經過容許共享訪問來實現數據庫的併發訪問，同時在須要執行排它操做時請求一個獨立訪問。再次印證，對於存儲引擎的選擇意義重大。InnoDB存儲引擎處理大多數加鎖問題而不須要你的參與，實現了更好的併發而且減小了你的代碼爲了提升性能而進行的大量的試驗和嘗試。

6）是否全部的內存區域都應用了正確的緩存大小。通俗的講，是否足夠大以應對頻繁的數據訪問，但又不大到超過物理內存並引發排序。最主要的內存區域配置是InnoDB緩存池，MyISAM的健緩存，還有MySQL的查詢緩存。

2、在硬件層面優化

當數據庫負載愈來愈大的時候，任何數據庫應用最終都會被硬件所限制。做爲一個DBA應該評估一下是否可能經過優化應用或者從新配置服務器去規避這些瓶頸，或者擴展更多的硬件。系統瓶頸一般來源於如下幾個緣由：

1）硬盤尋址。想找到硬盤上的數據是要花時間的。現代硬盤，這種尋址通常少於10毫秒，所以咱們能夠以每秒100次尋址來統計。這種耗時在新硬盤上提升緩慢而且對於單表來講比較難優化。優化尋址時間能夠經過把數據放到不一樣硬盤上來進行。

2）硬盤讀寫。當硬盤在正確的位置時，咱們須要讀寫數據。現代硬盤，一快硬盤讀取速率至少在10-20兆每秒。這塊很好優化，由於你能夠同時從不一樣的硬盤去讀取數據。

3）CPU週期。當數據在主存種，咱們必須處理它以獲得咱們想要的結果。讀取大表相比較於大量的內存而言是一般限制的因素。可是小錶速度一般不是問題。

4）內存帶寬。當CPU超過它能配置在CPU緩存裏的數據時，主存帶寬就成爲了一個瓶頸。這並非大多數系統所面臨的常見瓶頸，但它應該引發咱們的注意。

3、平衡移植和性能

在一個可移植的MySQL項目中使用性能目的類型的SQL擴展，你能夠用Mysql特有的關鍵詞 /*！ */來做爲註釋標識。其餘的SQL服務器忽略這個關鍵詞。

-------------------------------------英文原文---------------------------------------
Optimization Overview

Database performance depends on several factors at the database level, such as tables, queries, and configuration settings. These software constructs result in CPU and I/O operations at the hardware level, which you must minimize and make as efficient as possible. As you work on database performance, you start by learning the high-level rules and guidelines for the software side, and measuring performance using wall-clock time. As you become an expert, you learn more about what happens internally, and start measuring things such as CPU cycles and I/O operations.

Typical users aim to get the best database performance out of their existing software and hardware configurations. Advanced users look for opportunities to improve the MySQL software itself, or develop their own storage engines and hardware appliances to expand the MySQL ecosystem.

Optimizing at the Database Level

Optimizing at the Hardware Level

Balancing Portability and Performance

Optimizing at the Database Level

The most important factor in making a database application fast is its basic design:

Are the tables structured properly? In particular, do the columns have the right data types, and does each table have the appropriate columns for the type of work? For example, applications that perform frequent updates often have many tables with few columns, while applications that analyze large amounts of data often have few tables with many columns.

Are the right indexes in place to make queries efficient?

Are you using the appropriate storage engine for each table, and taking advantage of the strengths and features of each storage engine you use? In particular, the choice of a transactional storage engine such as InnoDB or a nontransactional one such as MyISAM can be very important for performance and scalability.

Note
InnoDB is the default storage engine for new tables. In practice, the advanced InnoDB performance features mean that InnoDB tables often outperform the simpler MyISAM tables, especially for a busy database.

Does each table use an appropriate row format? This choice also depends on the storage engine used for the table. In particular, compressed tables use less disk space and so require less disk I/O to read and write the data. Compression is available for all kinds of workloads with InnoDB tables, and for read-only MyISAM tables.

Does the application use an appropriate locking strategy? For example, by allowing shared access when possible so that database operations can run concurrently, and requesting exclusive access when appropriate so that critical operations get top priority. Again, the choice of storage engine is significant. The InnoDB storage engine handles most locking issues without involvement from you, allowing for better concurrency in the database and reducing the amount of experimentation and tuning for your code.

Are all memory areas used for caching sized correctly? That is, large enough to hold frequently accessed data, but not so large that they overload physical memory and cause paging. The main memory areas to configure are the InnoDB buffer pool, the MyISAM key cache, and the MySQL query cache.

Optimizing at the Hardware Level

Any database application eventually hits hardware limits as the database becomes more and more busy. A DBA must evaluate whether it is possible to tune the application or reconfigure the server to avoid these bottlenecks, or whether more hardware resources are required. System bottlenecks typically 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 or write 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 the data is in main memory, we must process it to get our result. Having large 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.

Balancing Portability and Performance

To use performance-oriented SQL extensions in a portable MySQL program, you can wrap MySQL-specific keywords in a statement within /*! */ comment delimiters. Other SQL servers ignore the commented keywords. For information about writing comments, see Section 9.6, 「Comment Syntax」.