mysql 查看函数fsync_强烈推荐|消除大流量导致MySQL瓶颈的18件事

• 这篇文章翻译了3篇blog：

https://www.percona.com/blog/2020/04/03/18-things-you-can-do-to-remove-mysql-      bottlenecks-caused-by-high-traffic-part-one/ https://www.percona.com/blog/2020/04/06/18-things-you-can-do-to-remove-mysql-bottlenecks-caused-by-high-traffic-part-two/ https://www.percona.com/blog/2020/04/07/18-things-you-can-do-to-remove-mysql-bottlenecks-caused-by-high-traffic-part-three/

• 毫无征兆的，但是系统的负载增加了100%，300%，500%，并且您的数据库必须承载这些请求。这是当今许多在线系统必须处理的情况。本文专注于处理意外的大流量事件。

• 你可以事先主动做很多事情，在“为应对黑色星期五的大流量，您数据库应该准备什么”一文中介绍了这些内容。

• 首先，让我们看看流量高峰时会对数据库产生什么影响---您的应用工程团队可能会遇到哪些问题？

• 查询响应事件变长

• 错误率变高(连接到数据库并执行查询)

• 数据库已宕机(不可用)

• 由于复制延时或者批处理任务无法完成，导致数据不准确(过期)

• 解决流量高峰的当前目标是尽快消除这些问题，这对大多数团队来说意味着专注于“容易实现的目标”----可以在几小时或几天内部署的解决方案，并且不需要进行大规模的应用程序或者架构的更改。

• 好消息是，对大多数应用程序，您可以通过一些简单的操作获得数据库性能的几倍提升：

1.对您的云数据库的规格进行扩容

---

复杂性：低

潜在影响：高

• 如果您的数据库运行在云环境(或者一些虚拟化环境中)，使用更高的实例规格通常是最简单的方法(也就是俗称的“钞能力调优”)。这是解决方案中最贵的方法之一，但这是您在继续进行其他性能优化操作之前时可以采取的短期维护操作。

• 注意：数据库不会线性扩展，所以不要产生错误的安全感---如果您的云数据库供应商有10倍大的可用实例，不要期望它能承载10倍的流量。根据负载可能会少很多。

2.部署更多的从节点

复杂性：中等 潜在影响：高

• 如果您的负载是读多写少，那么部署更多的从节点可能是提高性能的好方法。不知道您的负载是什么类型？重温“您的负载是读多写少还是读少写多”可以帮助您找到答案。

• 部署从节点是不够的；您需要确保您的应用程序能够将流量路由到它们。一些应用程序在应用层实现此功能很容易。对其他应用来说，部署ProxySQL并使用它的读写分离的功能可能是更好的选择。

• 在很多场景下，您甚至可以使得整个应用程序只使用从节点：如报表类应用程序或者使用MySQL全文检索类的应用程序。

• 请注意，MySQL复制是异步的， 这意味着从节点会有数据延时的情况(有时延时很高)，因此，查询要路由到最新数据的从节点，并确保监控复制延时和复制是否中断。

3.部署ProxySQL进行连接管理和缓存

复杂性：中等 潜在影响：高

• ProxySQL是管理MySQL 流量的一个很有用的工具，特别是在流量高峰期。ProxySQL 有连接池功能，这样应用程序不会耗尽连接，也不会因为有太多的并发连接导致MySQL超载。

• 如果您在使用Percona版MySQL或者MariaDB，您还可以启用线程池功能，它可以使得MySQL直接处理100000以上的连接。

• 在流量高峰时，ProxySQL另一个更有帮助的功能是ProxySQL 查询缓存，它允许您将查询结果缓存一段时间。

• 在一些场景下您不需要最新的数据结果时，将这些流量路由到从节点，并缓存相同的查询，可以带来一些性能提升。

4.停掉重任务的应用程序功能

复杂性：中等 潜在影响：中等

• 管理和开发团队常常讨厌这样的想法，但是这是一个很好的方法。并不是所有的应用程序功能都会有相同的作用或者调用频率相同，很少用到的程序功能通常负载是占据最高的，因为没有花费很多时间来优化它们。在您经历流量高峰或找时间优化它们时，禁用它们(或者短时间禁用)通常是一个很好的做法。

5.检查资源瓶颈

复杂性：低 潜在影响：高

• 数据库硬件层面的瓶颈可能有一个或者多个——CPU，内存，磁盘或者网络。如果您使用PMM监控，您可以在MySQL Instance Summary Dashboard的Node Summary章节看到这一内容。