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 进行二次开发和改进，另外一方面则得益于其成熟的架构。因此，一个工具能不能用好，人的因素占很大的比重。