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 databas 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.
數據庫性能主要取決於數據庫層面上的幾個因素，例如表結構，查詢語句，配置設置；儘可能使最小化內存佔用，同時又儘可能的有效率的軟件設計，是在硬件層面上的因素，如CPU,I/O操作等；當你開始處理數據庫性能的時候，你通過學習高級規則，和高級指南（語法和實例），用壁掛時間測試性能；當你成爲專家時，你需要去了解更多內部是如何運作的，開始用CPU週期和I/O操作來測量一些東西。
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.
具有代表性的使用着會在現有的軟件和硬件的基礎上去獲得最好的數據庫性能，牛逼的用戶會從mysql本身，或者開發他們自己的存儲引擎或者硬件設備來擴展mysql生態系統。
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 and the MyISAM key cache.
一個好的數據庫應用最重要的因素是它基本的設計；
（1）表結構是否合理？特別是這個列的數據類型是否正確，每一個表是否有滿足業務需要的合適的一些列（字段）？例如，一個需要頻繁更新數據的應用程序數據庫通常會有很多個擁有較少的列的表；一個需要分析大量數據的應用程序數據庫，通常會有比較少的擁有很多個列的表。
（2）是否具有能夠加快查詢效率的索引？每一個表是否都使用了合適的存儲引擎，和是否利用好你使用的這些存儲引擎的優勢，特徵？例如，選擇支持事務的存儲引擎InnoDB，一個非事務性的存儲引擎MyISAM,選擇合適的存儲引擎對於性能和可擴展性非常重要；（InnoDB是缺省的數據庫表存儲引擎，在實踐中，InnoDB性能特徵被放大，增強，意味着尤其是在一個繁忙的數據庫中InnoDB 的表通常要由於簡單的MyISAM的表）
（3）每一個表是否使用了合適的行格式？這主要取決於爲這些表適用的存儲引擎，特別地，壓縮表使用更少的磁盤空間，減少了讀寫數據的磁盤IO操作，壓縮表適用於所有使用InnoDB表的工作負載，荷用於只讀的MyISAM表的工作負載。
（4）是否使用了合適的鎖策略？通過當使用共享鎖滿足我們可能需要的併發操作，當在合適的時候去獨佔資源的時候，使用排他鎖，使的關鍵操作獲得最高優先權；再一次強調選擇合適的存儲引擎至關重要；InnoDB存儲引擎能夠在大部分情況下不影響你的操作處理好鎖的問題，具有更好的併發性能，並能減少大量的代碼實驗和調優；
（5）所有的內存區域都用於緩存的大小是否正確？只需要足夠大 能夠HOLD住頻繁訪問數據就可以啦，不能夠太大，這樣會導致物理內存超載，引起分頁；要配置的主要內存區域是Innodb 緩衝池和MyISAM鍵緩存
Optimizing at the Hardware Level（硬件層面上的優化）
• 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.
bandwidth becomes a bottleneck. This is an uncommon bottleneck for most systems, but one to be
aware of.
隨着數據庫變得越來越繁忙，任何數據庫應用程序最終都會遇到硬件限制。DBA必須評估是否有可能調優應用程序或重新配置服務器以避免這些瓶頸，或者是否需要更多的硬件資源。系統瓶頸通常有這些來源：
（1）磁盤搜索。磁盤需要時間來找到一段數據。對於現代磁盤，平均時間通常小於10毫秒，所以理論上我們每秒可以做100次搜索。這一次使用新磁盤進行緩慢改進，對於單個表的優化來說是非常困難的。優化查找時間的方法是將數據分佈到多個磁盤上。
（2）磁盤讀和寫。當磁盤處於正確的位置時，我們需要讀取或寫入數據。有了現代磁盤，一個磁盤傳輸至少具有10-20mb/s的吞吐量。這比搜索更容易進行優化，因爲您可以從多個磁盤並行讀取。
（3）CPU週期。當數據在主存中時，我們必須處理它以獲得結果。與內存數量相比，擁有大表是最常見的限制因素。但是對於小表，速度通常不是問題。
（4）內存帶寬。當CPU需要的數據超過了CPU緩存時，主內存帶寬就成爲了瓶頸。對於大多數系統來說，這是一個不常見的瓶頸，但是值得注意的瓶頸。
Balancing Portability and Performance（平衡可移植性和性能）
keywords in a statement within /*! */ comment delimiters. Other SQL servers ignore the commented keywords.
要在一個可移植的MySQL程序中使用性能導向的SQL擴展，你可以在SQL語句中使用/！* /註釋分隔符隱藏特殊關鍵字。其他SQL服務器也會忽略了註釋的關鍵字。
下面所有文章都是自己的理解加上翻譯而來， 有很多位置理解不到位，希望有同道幫忙指正！非常感謝。
下一篇：https://blog.csdn.net/qwerdf10010/article/details/80491722