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