是否收集了瞬态垃圾？

#1 楼

现在是

从WordPress 3.7开始，数据库升级时会删除过期的瞬变，请参阅＃20316


旧答案

如果有人否则无法向我展示，看来瞬变毕竟不是垃圾收集。更糟糕的是，与选项不同，它们不能保证存储在数据库中。因此，没有可靠的方法来获取所有瞬态的列表以检查它们是否到期。

如果数据库用于存储，则一些临时代码可以进行垃圾回收：

add_action( 'wp_scheduled_delete', 'delete_expired_db_transients' );

function delete_expired_db_transients() {

    global $wpdb, $_wp_using_ext_object_cache;

    if( $_wp_using_ext_object_cache )
        return;

    $time = isset ( $_SERVER['REQUEST_TIME'] ) ? (int)$_SERVER['REQUEST_TIME'] : time() ;
    $expired = $wpdb->get_col( "SELECT option_name FROM {$wpdb->options} WHERE option_name LIKE '_transient_timeout%' AND option_value < {$time};" );

    foreach( $expired as $transient ) {

        $key = str_replace('_transient_timeout_', '', $transient);
        delete_transient($key);
    }
}

#2 楼

通过重新措辞和重新设置格式，将讨论中的一些评论转变为答案。.

基本上，归结为，除非您有极端的案例，否则它们不会确实需要“收集垃圾”。如果您从未获取过它们，那么它们是否存在都没关系。

请注意，瞬态默认情况下存储在选项表中。在基本安装中，选项表中可能包含100个条目。每个瞬态都会添加两个条目，但是即使您有数千个条目，它们也不会影响网站速度，因为它们不会自动加载。

在启动时，WordPress会将选项加载到内存中，但是仅加载启用了自动加载标记的选项。瞬态不了解这一点，因此也不会加载到内存中。只有稍后实际使用的瞬态会产生成本。

从数据库的角度来看，选项表在选项ID和选项名称上都有索引。瞬态总是根据名称（键）加载的，因此对它们的查找始终是对单个唯一键值的简单选择。因此，查找为O（log（n）），并且超快。使用log（n）的Big-O，您必须先进入成千上万的行，然后它才变得引人注目。坦白地说，查询的设置和拆卸以及实际数据传输的开销要长得多。通过比较，查询本身的运行时间基本上为零。因此，简单地拥有多余的未使用行对使用额外的磁盘空间不会有任何影响。

在数据库中建立索引是那些对那些没有知识的人没有意义的深层想法之一真正了解幕后发生的事情。数据库旨在从头开始快速进行数据检索，并且可以毫无问题地处理此类问题。这是一本不错的书：http://en.wikipedia.org/wiki/Index_（数据库）

现在，以最明显的方式进行清理（在它们上调用SQL DELETE）实际上并没有从数据库中删除它们。它只是将它们从索引中删除，并将该行标记为“已删除”。同样，这就是数据库的工作方式。要实际清除磁盘空间，您必须继续然后在之后执行OPTIMIZE TABLE，这不是一项快速的操作。这需要时间。可能花了更多时间。总的来说，这可能不足以节省CPU时间。

如果您遇到某种情况导致连续插入未使用的新瞬态，那么您需要找到根本的问题。是什么插入这些瞬变？他们使用的是变更键还是变异键？如果是这样，那么导致此问题的插件或代码基本上应该固定为不这样做。这样做会更有帮助，因为未正确创建它们的代码也可能没有检索到它们，因此完成了比其所要做的更多的工作。

另一方面，在某些情况下，可能会为每个帖子都创建瞬态。这确实可以完全接受。我自己在SFC中进行此操作，以存储来自Facebook的传入评论。每个帖子都有一个与之关联的潜在瞬变，这意味着每个帖子有两个额外的行。如果您有1万条帖子，那么选项表中（最终）将有2万行。这并不坏，也不会很慢，因为同样，就数据库真正关心的而言，100行和20,000行之间的差异很小。全部索引。快得快。次毫秒。

当您开始进入数百万行时，我会担心。当上述几百兆的选项表大小的增加，那么我会关注不够仔细看看。但是总的来说，除了极端情况，这不是问题。对于比拥有数十万个帖子的大型新闻网站这样的小问题来说，这绝对不是问题。对于任何足以解决问题的站点，您都应该使用某种外部对象缓存，在这种情况下，瞬态会自动存储在此处而不是存储在数据库中。

#3 楼

奥托-我再也不同意你的看法。
问题是，最终，在所有这些瞬变中，表的大小变得荒谬。不需要花费数百万行就可以解决。我当前正在处理具有超过13万行的选项表，该表经常挂起。因为value字段是大文本类型，所以即使仅查找“自动加载”行也成为性能的噩梦。这些值字段与其余的行数据分开存储。
即使从逻辑上讲它是同一张表的一部分，也必须进行联接才能提取所需的行。现在，由于需要的数据分布在磁盘上的所有位置，因此永久连接需要很长时间。分析（对于MySQL使用jet profiler）已经证明了这一点。

将自动加载添加到群集密钥可能有助于解决此问题。例如，基于自动加载描述（ID ASC）的群集，将允许所有自动加载行首先在磁盘上聚集在一起。甚至我仍然认为您从数据库的角度来看正承受着巨大的压力。

我个人认为该系统的设计很糟糕。选项表似乎已经变成了很多事情的通用工具。如果value字段足够小，可以与该行数据的其余部分包含在同一页上，并且可以有效地对其进行索引，则可以。不幸的是，事实并非如此。设计此方法的人需要回到DB101类。