使用set\\u transient（）函数是否会导致MySQL问题？

No, 虽然如果您经常使用它，以至于MySQL服务器的磁盘空间不足，那么是的，它可能会导致问题。然而，通过检查磁盘空间，您就会知道情况是这样的，如果您能够做到这一点，那么我会认为您对瞬态的使用有很大的问题。

不过，任何表格都是如此，这不是一个瞬态问题，而是存储了太多东西，显然出了问题。就像一个大驱动器被一个日志填满，或者一个程序进入一个无限循环。

当我到达最后一个option\\u id时会发生什么？

You will not reach the last option ID.

我从未见过一个站点遇到这种情况，要突破BIGINT 20，您需要2到64个选项，或者18446744073709552000个选项。这是18446744073709百万期权，或18446744073万亿期权，或18446744四万亿期权。

在这成为问题之前，您的服务器将很长时间内耗尽内存和磁盘空间。So this isn\'t worth worrying about. 请记住，如果您需要很多瞬态，并且有数百个甚至数千个瞬态，这表明代码中存在缩放问题。

即使我们说每天将有40万个条目添加到选项表中，而且我们有一台具有无限存储CPU和RAM的机器，但要达到上限至少还需要126万亿年。宇宙的热死亡可能会比这更早发生。

WordPress是否有一些安全触发器来重置option\\u id或有其他规则？

No, it isn\'t necessary, 或者是一个安全问题，我怀疑任何一个WP网站都不会接近使用价值的一半。这是MySQL/MariaDB必须处理的事情。

还是我不用担心？

Correct! 选项ID字段完全是一个骗人的东西。这不值得你花时间和精力。别担心。

作为一个插件作者，我必须考虑很多事情。One of my plugins uses a temporarily PHP session 以数组类型保存通过其API接收的JSON数据。

这是一个问题。On most WP hosts PHP sessions just do not work. PHP会话与绝大多数基于插件和基于服务器的缓存机制不兼容。PHP会话也与WordPress如何使用Cookie管理自己的会话背道而驰。此外，PHP会话必须存储在内存中，而且由于它们的工作方式，它很难随着流量的增加而扩展。

这也是不安全的，用户可以干预PHP会话来切换它们。你调查其他选择是正确的。