Чи збираються перехідні сміття?

Це питання змусило мене думати, що транзиторні RSS-канали у wp_options не видаляються автоматично?

Передбачається, що перехідні періоди закінчуються та видаляються. Однак єдиний спосіб, коли я бачу, що це обробляється - це коли термін тимчасового терміну закінчується і запитується, тоді він видаляється під час запиту.

Що робити, якщо термін минулого закінчився, але після цього його ніколи не просять? З опису в Codex я подумав, що мається на увазі якесь збирання сміття. Зараз я не настільки впевнений і не можу знайти жодного коду, який виконує таке.

Тож він просто назавжди застряже в базі даних?

Вони зараз є

Починаючи з 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);
    }
}

Переміщення деяких коментарів із обговорення у відповідь із переформулюванням та переформатуванням.

В основному, це зводиться до того, що якщо у вас є надзвичайно екстремальний випадок, їх насправді не потрібно "збирати сміттям". Якщо ви ніколи їх не отримуєте, то не має значення, вони там чи ні.

Дивіться, перехідні процеси за замовчуванням зберігаються в таблиці параметрів. У базовій установці в таблиці параметрів буде, можливо, 100 записів. Кожен перехідний додає ще два записи, але навіть якщо у вас їх тисячі, вони не впливають на швидкість сайту, оскільки вони не завантажуються автоматично.

При запуску WordPress завантажує параметри в пам'ять, але він завантажує лише параметри, у яких увімкнено прапор автозавантаження. Тимчасові не отримують цього, і тому не завантажуються в пам'ять. Тільки тимчасові, які фактично використовуються пізніше, понесуть витрати.

З точки зору бази даних, таблиця параметрів містить індекси як Id параметра, так і імені параметра. Перехідні файли завжди завантажуються на основі імені (ключа), і тому пошуки для них завжди прості, вибираються на одному унікальному значенні ключа. Таким чином, пошук є O (log (n)) і надшвидкий. З Big-O журналу (n) вам доведеться потрапляти в мільйони і мільйони рядків, перш ніж це стане помітним. Відверто кажучи, накладні витрати в налаштуванні та вилученні запиту, а також фактична передача даних, значно довші. Сам запит працює порівняно з нульовим часом порівняно. Тому просто наявність зайвих невикористаних рядків не впливає ні на що, крім використання додаткового місця на диску.

Індексація в базах даних - одна з тих глибоко читаних ідей, які не мають сенсу людям, які насправді не розуміють, що відбувається за лаштунками. Бази даних розроблені для швидкого пошуку даних з нуля і можуть обробляти подібні речі без проблем. Це досить вдале прочитання: http://en.wikipedia.org/wiki/Index_(database )

Тепер очищення найбільш очевидним способом (виклик SQL DELETE на них) насправді не видаляє їх із бази даних. Він просто видаляє їх з індексу і позначає рядок як "видалено". Знову ж таки, саме так працюють бази даних. Щоб фактично очистити простір на диску, вам слід продовжити і робити ОПТИМІЗАЦІЮ ТАБЛИЦІ після цього, і це не швидка операція. На це потрібен час. Напевно, більше часу, ніж варто. Це, мабуть, недостатньо, щоб загалом заощадити час процесора.

Якщо у вас є певний випадок, який спричиняє постійне введення нових перехідних процесів, які не використовуються, тоді вам потрібно знайти основну проблему. Що вставляє ці перехідні? Чи використовують клавішу, що змінюється або мутує? Якщо так, то плагін або код, що викликає це, слід виправити, в основному, не робити цього. Це буде корисніше, тому що, ймовірно, код, який не створює їх належним чином, також не отримує їх, і, таким чином, виконує більше роботи, ніж це доводиться робити.

З іншого боку, може бути випадок, коли створюються перехідні періоди для чогось подібного до кожної посади. Це дійсно може бути цілком прийнятним. Я роблю це сам у SFC, щоб зберігати вхідні коментарі з Facebook. Кожна публікація пов'язана з потенційним перехідним періодом, що означає два додаткових рядки на посаду. Якщо у вас є 10 000 повідомлень, у таблиці параметрів (зрештою) у вас буде 20k рядків. Це не погано чи повільно, оскільки, знову ж таки, різниця між 100 рядками та 20 000 рядками є дуже малою, що стосується баз даних насправді. Це все індексовано. Це швидко, як чорт. Суб-мілісекунди.

Коли ви почнете збиратися в мільйони рядків, то я б хвилювався. Коли розмір таблиці параметрів збільшується вище сотень мегабайт, то я буду досить стурбований, щоб детальніше ознайомитися. Але взагалі це не проблема, окрім крайніх випадків. Це, звичайно, не проблема для чогось меншого, ніж щось на зразок великого сайту новин із сотнями тисяч публікацій. І для будь-якого сайту, достатньо великого, щоб це могло бути проблемою, ви повинні використовувати зовнішній кеш об'єктів, і в цьому випадку перехідні процеси автоматично зберігаються там, а не в базі даних.

Отто - я більше не могла погодитися з вами. Проблема полягає в тому, що врешті-решт із усіма цими перехідними періодами розмір столу стає смішним. Не потрібно мільйони рядків, щоб збити. Зараз я маю справу з таблицею варіантів, яка має понад 130 тис. Рядків і регулярно висить. Оскільки поле значення є великим текстовим типом, навіть пошук лише рядків "автозавантаження" стає кошмаром продуктивності. Ці поля значень зберігаються окремо від решти даних рядків. Незважаючи на те, що це логічно є частиною тієї ж таблиці, приєднання має відбуватися для того, щоб витягнути потрібні рядки. Приєднання, яке зараз триває назавжди, оскільки потрібні вам дані розповсюджуються по всьому місцю на диску. Профілювання (використання реактивного профілю для mysql) підтвердило це.

Додавання автоматичного завантаження в кластерний ключ може допомогти вирішити цю проблему. Кластеризація на автоматичному завантаженні Desc, ID ASC, наприклад, дозволить усім рядкам автоматичного завантаження спочатку з'єднатись на диску. Навіть все-таки я думаю, що ти дивишся на величезну напругу з точки зору БД.

Особисто я вважаю, що дизайн цієї системи пробуксований. Таблиця параметрів, здається, перетворилася на загальний підсумок для багатьох речей. Це добре, якщо поле значення є досить малим, щоб його можна було включити на ту ж сторінку, що й решта даних рядка, і його можна ефективно індексувати. На жаль, це не так. Хто б це не спроектував, потрібно повернутися до класу DB101.