您无权修改有问题的脚本，因此修复此问题需要数据库管理员的工作，而不是编程工作。您的任务称为调整 MySQL 数据库。
（我猜你已经向你的供应商寻求帮助，他们拒绝了。）
脚本运行时，Ron top 或 htop。 CPU 是否固定在 100%？ RAM 是否耗尽？
1) 忍受它，并在您的网站没有很多访问者的一天中运行更新脚本。相当简单，但不是真正的解决方案。
2) 作为实验，将 RAM 添加到您的 VPS 实例。它可以让 MySQL 做所有在 RAM 中的事情，它目前放在硬盘上的临时表中。如果有帮助，这可能是一种解决您的问题的方法，只需少量工作和较高的服务器租用费。
3) 添加一些索引以加快脚本中的查询速度，从而更快地完成每个查询。问题是，哪些索引会有所帮助？ （只是随机添加索引通常没有多大帮助。）
首先，找出哪些查询速度较慢。在脚本运行时重复执行命令 SHOW FULL PROCESSLIST。该结果中的 Info 列显示所有正在运行的查询。将它们复制到文本文件中以保留它们。 （或者你可以使用MySQL的慢查询日志，关于这个你可以在线阅读。）
其次，分析最严重的违规查询，看看是否有明显的索引要添加。告诉您如何做到这一点通常超出了 Stack Overflow 答案的范围。您可能会询问有关特定查询的另一个问题。在你做之前，请
reead this note about asking good SQL questions，关注查询性能部分。
3) 您的脚本可能正在从表中选择许多行，或者使用 SELECT 来汇总许多行，这些表在用户访问您的网站时也需要更新。在这种情况下，您的访问者可能正在等待这些 SELECT 完成。如果您可以更改脚本，则可以将此语句放在长时间运行的 SELECTS 之前。
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
这允许它之后的 SELECT 语句执行“脏读”，其中它可能会获得更新行的早期版本。 See here。
或者，如果您知道如何将一条语句插入到您的隐藏脚本中，请在打开数据库会话之后立即添加这条语句。
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
但是，如果无法访问源代码，您只有一种方法可以查看这是否是问题所在。也就是说，在脚本运行之前，从特权帐户访问 MySQL 服务器，并给出这些 SQL 命令。
SHOW VARIABLES LIKE 'tx_isolation';
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITED;
然后看看性能问题是否有所改善。在脚本完成后将其设置回来，可能像这样（取决于上面检索到的 tx_isolation 值）
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITED;
警告如果依赖于事务一致性，对隔离级别的永久性全局更改可能会破坏您的应用程序。这只是一个实验。
4) 骚扰脚本作者以解决此问题。