數據庫索引很像圖書索引。它們被保存在自己的位置，并且包含主數據庫中已經存在的信息。它們是指向數據所在位置的參考方法或映射。索引不會更改數據庫中的任何數據。它們只是指向數據的位置。

沒有完全適用于任何工作負載的索引。而應該始終在系統運行的查詢上下文中查看索引。

索引良好的數據庫不僅運行得更快，而且即使缺少一個索引也會使數據庫慢如蝸牛。使用EXPLAIN(如前所述)查找缺少的索引并添加它們。但是要小心：不要添加你不需要的索引！不必要的索引會降低數據庫的速度
(請查看關于MySQL索引最佳實踐的介紹)。

優化技巧 #3：拒絕使用默認設置

與任何軟件一樣，MySQL有許多可配置的設置，可用于修改行為(以及最終的性能)。與任何軟件一樣，管理員忽略了許多這些可配置的設置，最終在默認模式下使用。

要從MySQL中獲得最佳性能，了解可配置的的MySQL設置是非常重要的，更重要的是將它們設置為最適合您的數據庫環境。

默認情況下，MySQL用于小規模的開發安裝，而不是生產規模。您通常希望配置MySQL以使用所有可用的內存資源，并允許應用程序需要的連接數量。

下面是三個MySQL性能優化設置，您應該始終仔細檢查：

innodb_ buffer_ pool_size:緩沖池用于存放緩存數據和索引。這是使用具有大容量RAM的系統作為數據庫服務器的主要原因。如果只運行InnoDB存儲引擎，通常會將80%的內存分配給緩沖池。如果您正在運行非常復雜的查詢，或者有大量的并發數據庫連接，或大量的表，可能需要將此值降低一個檔次，以便為其他操作分配更多的內存。

在設置InnoDB緩沖池大小時，需要確保不要設置得太大，否則會導致交換。這絕對會影響數據庫性能。一種簡單的檢查方法是查看Percona Monitoring and Management中的系統概述圖中的交換活動：

?

?

如圖所示，有時進行一些交換是可以的。但是，如果看到持續每秒1MB或更多的交換活動，則需要減少緩沖池大小(或其他內存使用)。

如果在第一次訪問時沒有正確地獲得innodb_ Buffer_ pool_ size的值，不用擔心。從MySQL5.7開始，便可以動態更改InnoDB緩沖池的大小，而無需重新啟動數據庫服務器。

innodb_ log_ file_ size：這是單個InnoDB日志文件的大小。默認情況下，InnoDB使用兩個值，這樣您就可以將這個數字加倍，從而獲得InnoDB用于確保事務持久的循環重做日志空間的大小。這也優化了將更改應用到數據庫。設置innodb_ log_ file_ size是一個權衡的問題。分配的重做空間越大，對于寫密集型工作負載而言，性能就越好，但是如果系統斷電或出現其他問題，崩潰恢復的時間就越長。

如何知道MySQL的性能是否受到當前InnoDB日志文件大小的限制？可以通過查看實際使用了多少可用的重做日志空間來判斷。最簡單的方法是查看Percona Monitor and Management InnoDB Metrics儀表板。在下圖中，InnoDB日志文件的大小不夠大，因為使用的空間非常接近可用的重做日志空間(由紅線表示)。日志文件的大小應該至少比保持系統最佳運行所用的空間大20%。

?

?

MAX_ Connections：大型應用程序連接數通常需高于默認值。不同于其它變量，如果沒有正確設置它，就不會有性能問題(本身)。相反，如果連接的數量不足以滿足您的應用程序的需要，那么您的應用程序將無法連接到數據庫(在您的用戶看來，這就像是停機時間)。所以正確處理這個變量很重要。

如果在多個服務器上運行多個組件的復雜應用程序，很難知道需要多少連接。幸運的是，MySQL可以很容易地看到在峰值操作時使用了多少連接。通常，您希望確保應用程序使用的最大連接數與可用的最大連接數之間至少有30%的差距。查看這些數字的一種簡單方法是在Percona監控和管理的MySQL概述儀表板中使用MySQL連接圖。下圖顯示了一個健全的系統，其中有大量的附加連接可用。

?

?

需要記住的一點是，如果數據庫運行緩慢，應用程序通常會創建過多的連接。在這種情況下，您應該處理數據庫的性能問題，而不是簡單地允許更多的連接。更多的連接會使底層的性能問題變得更糟。

(注意：當將max_Connections變量設置為明顯高于默認值時，通常需要考慮增加其他參數，如表緩存的大小和打開的MySQL文件的數量。但是，這不屬于本文討論的范疇。)

優化技巧 #4：將數據庫保存在內存中