>假设一个每分钟有 X00,000 个请求的 （PHP） Web 应用程序，以及一个条目数大致相同的 SQL 数据库。
每个请求将触发几个 （<5） 个数据库读取和一个数据库写入（主要是更新）。我主要担心写入引起的性能问题，并寻找解决方案来增加每分钟可能的请求。
你会建议什么解决方案，你将如何实施它，为什么？
我想到的事情包括要写入的缓存，它每隔一段时间与数据库同步一次，或者像 Gearman 这样的队列，或者只是 SQL 的插入延迟。
但是，由于相同的负载应该是恒定的，因此当服务器负载始终保持在>90% 时，插入延迟可能不会有太大帮助，因此我正在寻找与单次写入相比显着减少服务器负载的方法。
谢谢
如果您要更新您也在读取的表，那么是的，这些更新会减慢读取速度，因为它们会使 MySQL 查询缓存和可能的表锁定无效。一个常见示例是产品详细信息表，您可以在其中更新访问计数。
简单的方法不是更新主表，而是使用单独的表来更改值（例如product_views），并更改查询以使用 JOIN 来获取值。使用这种方法，您的主表（和大表）将大部分是静态的，不受查询缓存失效和锁定的影响。
更高级的方法是不使用更新，而是插入。不是在每个网页浏览中更新一行，而是在临时表中插入新值（例如 product_views_temp ） - 所以每个视图将是 1 行。然后安排一个 cron 作业，例如每 5 分钟执行一次查询，例如 SELECT COUNT(*) FROM product_views_temp GROUP BY prod_id 并根据数字更新主表（应该可以在 1 个查询中）。主要好处是这些 INSERT 速度更快，如果需要，无论出于何种原因，您都可以在主表中拥有计数。小缺点是，在访问者看到更新的计数之前几乎没有延迟。
编辑：如果您可以承受丢失这5分钟的计数数据，则可以通过使用MySQL MEMORY存储引擎创建临时表来使其超快。它们对于插入非常快（但对于更新可以稍微慢一点）。当服务器崩溃/关闭时，表本身仍然存在，但其内容丢失。
您还可以将 MEMORY 引擎用于会话数据（如果用户在意外服务器崩溃后需要再次登录并不重要，因为这不会经常发生）。