今天，我在db上运行了一个测试，以探索从选项、自定义表和；瞬态。我运行了1000次测试，下面是运行1000次get操作所需的时间：
请记住，选项表用于大多数系统的选项和瞬态，并且该表经过优化，添加了索引。所以这不是一个公平的比较
get\\u transient（）0.0245秒get\\u option（）0.0068秒从自定义表中简单选择操作0.65秒
这也是一种不公平的比较autoload 选项集将在早期的单个查询中加载到advanced中。所以get_option 正在从WP_Cache, 已检索到该选项。
TLDR：它实际上并没有获取选项，它已经被获取了，它只是从内存中提取它，因为autoload 选项
我还检查了瞬态在测试期间是否未过期。
这不应该对正常系统的瞬态检索产生影响，毕竟在检索之前它不知道是否过期。
所以问题是，get\\u option（）比get\\u transient（）快还是我在测试中弄糟了什么？
这取决于：
在大多数系统中，瞬态是使用选项存储的，这两种选项都涉及get_option 使用调用选项autoload 如果设置为true，则在一次调用开始时都会加载，因此它们会保留在内存中，此后不会发生任何查询。对象缓存会缓存两个自动加载的选项，而瞬态缓存是由于WordPress缓存选项而导致的自定义表延迟吗？
很有可能，但选择的速度很大程度上取决于查询和表设计
此外，选项是否也由不同的缓存插件（如transients）缓存？
对WP_Cache 将其存储在内存中以供其余请求使用。出于性能原因，缓存插件可能会保留这些值。
重复性这些都是通过WP_Cache 因此，当您第二次请求时，不涉及DB。
可变性及其依赖性这一切都假设了一个共同的基础，but what about object caches?
让我们介绍一个MemcacheD实例或Redis实例（如果您有选择的话，我强烈建议您这样做，这对构建良好的站点有巨大的性能好处，特别是如果您将它们用于页面缓存，除非您有类似Varnish的设置）
现在我们有了一个新情况：
现在，数据存储在RAM中，一旦从DB中取出，它就会启动，访问时间大大减少。仍然比变量慢，但比数据库查询快得多许多新数据存储在WP_Cache 这通常不是。例如。WP_Post 对象、post meta等WP_Cache 现在跨请求持久化，MemcacheD etc可以消除过期的瞬态etc，因此现在瞬态和选项具有相同的访问成本。它们已经很接近了，但现在可以忽略不计，更多的是与发出请求时的CPU负载有关。
那么对于性能，我应该使用瞬态还是选项
虽然这是一个值得怀疑的问题，但答案是差异可以忽略不计，并且在误差范围内
因此，停止微优化，它们是相同的存储介质，这不值得你花时间
如果您需要存储站点范围内的内容，请使用选项使用瞬态来临时存储计算成本高昂的内容，这样您就不必等到下一次了。根据性能来选择其中一个是不值得的，没有什么显著的区别。
有更好的方法可以进行优化，从而大大节省成本，例如在post查询中使用分类法而不是元，而不是使用__not 样式参数、在页面上执行更少的操作、安装对象缓存、降低每页的帖子数量、避免远程请求等
那么一个自定义表将
否，选项表已经得到了很好的优化，使用自定义表只需将操作移到WP缓存系统之外，迫使您自己编写
