今天，我对数据库进行了测试，以探讨从选项，自定义表和瞬态访问键之间的速度差异。我运行了1000次测试，以下是运行1000次get操作所花费的时间：
get_transient() 0.0245秒get_option() 0.0068秒我还检查了此测试过程中瞬态未过期。所以问题是，get_option()比get_transient()我测试中的速度快还是弄乱了？自定义表格是否由于WordPress默认缓存的选项而延迟？另外，选项是否也由瞬态等不同的缓存插件缓存？
Answers:
今天，我对数据库进行了测试，以探讨从选项，自定义表和瞬态访问键之间的速度差异。我运行了1000次测试，以下是运行1000次get操作所花费的时间：
请记住，选项表在大多数系统上都用于选项和瞬态，并且该表已经过优化，并添加了索引。所以这不是一个公平的比较
get_transient（）0.0245秒get_option（）0.0068秒来自自定义表的简单选择操作0.65秒
这也是一个不公平的比较，带有autoload选项集的选项将在早期的单个查询中提前加载。所以get_option从WP_Cache，该选项已被检索。
TLDR：它实际上不是在获取选项，它已经被获取，只是由于该autoload选项而将其从内存中拉出
我还检查了此测试过程中瞬态未过期。
这毕竟不会影响正常系统的瞬时检索，毕竟它直到被检索之前才知道它是否过期。
所以问题是，get_option（）比get_transient（）更快还是我在测试中弄乱了某些东西？
这取决于：
get_option调用autoload设置为true的选项会在开始时全部加载到单个调用中，因此它们会保留在内存中，此后不会发生任何查询自定义表格是否由于WordPress默认缓存的选项而延迟？
很有可能，但是选择需要花多长时间取决于查询和表设计
另外，选项是否也由瞬态等不同的缓存插件缓存？
是，WP_Cache已使用，它将在其余请求中将其存储在内存中。出于性能原因，缓存插件可能会保留这些值。
这些都是通过缓存的，WP_Cache因此在您第二次请求时，不涉及数据库。
所有这些都假设有共同的基础，但是对象缓存又如何呢？
让我们介绍一个MemcacheD实例或Redis实例（如果可以选择的话，我强烈建议您这样做，对于精心构建的网站，尤其是如果将它们用于页面缓存，除非使用类似Varnish的东西，否则，它们可以极大地提高性能）
现在我们有了一个新情况：
WP_Cache通常不会存储很多新数据。例如WP_Post对象，发布元等WP_Cache 现在在请求之间仍然存在因此，现在瞬态和选项具有相同的访问成本。它们已经关闭，但是现在可以忽略不计了，它们与发出请求时的CPU负载有更多关系。
虽然这是一个值得思考的问题，但答案是，差异可以忽略不计并且在误差范围内
因此，停止微优化，因为它们是相同的存储介质，所以这不值得您花时间
您不值得花时间根据性能选择一个，而没有有意义的区别。
有很多要做的优化工作，可以大大节省开支，例如在后查询中使用分类法而不是元数据，不使用__not样式参数，在页面上执行更少的操作，安装对象缓存，每页上的帖子更少，避免远程请求等等
不，选项表已经过优化，使用自定义表会将操作简单地移到WP Caching系统之外，从而迫使您编写自己的表
如果没有找到对象缓存，则get_transient调用get_option两次，一次或终止时间间隔，并调用该值，因此不会更快。
get_option性能本身将影响该选项是否为“自动加载”（默认）。所有自动加载的选项都在一个请求中检索到DB，并存储在内存缓存中，因此，get_option即使调用不同的选项，对您调用多少次的影响也应该很小。
当您直接访问数据库时，您将绕过所有缓存和其他性能改进，并且除非您自己实现一些智能逻辑，否则预期它会变慢。
话虽这么说，我不确定您的测试是否是一个很好的测试，但是无论如何，整个讨论毫无意义，好像您真的在乎性能一样，您将使用对象缓存系统（和相关的插件），这将使数据访问时间更加接近到零...。当然，如果您决定使用自己的数据库表，则应将访问API与对象缓存机制集成在一起。