MySQL 瓶頸及應對措施

注：內容摘抄自《PHP 核心技術與最佳實踐》一書

MySQL 是存在瓶頸的。 當 MySQL 單表數據量達到千萬級別以上時，不管如何對 MySQL 進行優化，查詢如何簡單，MySQL 的性能都會顯著下降。 採起措施：

1）增長 MySQL 配置中的 buffer 和 Cache 的數值，增長服務器 CPU 數量和內存的大小，這樣能很大程度上應對 MySQL 的性能瓶頸。 
    性能優化中，效果最顯著、成本最低的當屬硬件和服務器優化，因此這是應該首先考慮的。 
2）使用第三方引擎或衍生版本。
    如 Percona 在功能和性能上較 MySQL 有着顯著的提高；由 MySQL 創始人開發的免費 MariaDB 在 InnoDB 引擎上的性能也比 MySQL優秀；
    據官網借號，另外一款改進的產品 TokuDB，性能是 MySQL 的 10 倍以上。以上這些衍生版或改進版的 MySQL 主要都是針對 MySQL 的 InnoDB
    引擎。 InnoDB 每次提交事物時，爲了保證數據已經持久化到磁盤（Durable），須要調用一次 fsync 告知文件系統，將可能在緩存中的數據
    刷新到次哦按。而 fsync 操做自己是很是『昂貴』的（消耗較多的 I/O 資源，響應較慢），若是每次事物提交都單獨作 fsync 操做，那麼這裏
    將是系統 TPS 的一個瓶頸，因此就有了 Group Commit 的概念。 MySQL 5.0 後，處於分佈式架構的考慮，爲了保證 InnoDB 內部 Commit 
    和 MySQL 日誌的順序一致，InnoDB 被迫放棄支持 Group Commit。以後，就一直沒有好的解決方案了。直到出現 MariaDB，才比較完美的解決
    了這個問題。
3）遷移到其它數據庫。
    如開源的 Post供熱SQL 和商業的 Oracle。 與 Oracle 和 PostgreSQL 相比， MySQL 屬於線程模式，而且採用了插件引擎的架構。這種實現
    的確有本身的優點：輕巧快速、系統資源消耗小、支持更多併發鏈接，但進程模式能更充分的應用 CPU 資源，在應付複雜業務查詢上更有優點。好比，
    在常規優化的前提下，Oracle 的但別性能瓶頸經驗值在 2 億數據量的級別，遠遠優於 MySQL。 不只如此，在關聯查詢和內置函數等功能上，
    Oracle 都是完勝 MySQL 數據庫的。 再好比，PostgreSQL 數據庫相比 MySQL，擁有更強大的查詢優化器，不會頻繁重建索引，支持物化視圖等
    優點。固然，遷移到其餘數據庫還要看應用的類型，好比是偏向 OLTP（ On-Line Transaction Processing，聯機事物處理）的應用仍是偏向
    OLAP（On-Line Analytical Processing，聯機分析處理）應用。 
4）對數據庫進行分區、分表，減小單表體積。
5）使用NoSQL 等輔助解決方案，如 Memcached、Redis。
6）使用中間件作數據拆分和分佈式部署，這方面的典型案例有阿里巴巴對外開源的數據庫中間件 Cobar。
7）使用數據庫鏈接池技術。 
    在第 3 點，咱們講過，MySQL 是線程模式，能夠支持更多的併發鏈接數。MySQL 能支持遠比 Oracle 和 PostgreSQL 更多的鏈接。因此 Oracle
    和 PostgreSQL 應用中一般用數據庫鏈接池技術來複用鏈接。那麼 MySQL 爲何還須要用這些數據庫應用中常見的數據庫鏈接池技術呢？ 緣由在於
    MySQL 的所機制還不夠完善，同時程序中的一些問題都有可能致使 MySQL 數據庫鏈接阻塞，在併發大的狀況下，就會浪費不少鏈接資源和反覆鏈接
    的消耗。使用數據庫鏈接池，讓鏈接進行排隊和複用，必定程度上能夠緩解高併發下的鏈接壓力。

MySQL 瓶頸是真實存在的，可是很多大型互聯網公司仍然在使用 MySQL，而且能使用的很好，這一方面是由於這些公司的技術實力足以對 MySQL 進行二次開發和改進，另外一方面則得益於其成熟的架構。因此，一個工具能不能用好，人的因素佔很大的比重。