注：內容摘抄自《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 進行二次開發和改進，另一方面則得益於其成熟的架構。所以，一個工具能不能用好，人的因素占很大的比重。