Чому таблиця `wp_options` не має індексу на` autoload`?


15

На початку кожної сторінки, що обслуговується WordPress, є виклик MySQL для отримання параметрів:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Оскільки в autoloadколонці немає індексу , MySQL повинен шукати ВСІ рядки.

Я також натрапив на коментар до цієї відповіді, сказавши, що не буде приріст результативності, навіть якби був індекс.

У своїй програмі я використав безліч перехідних значень, щоб служити заміною сеансу. Вони чудово працювали, і у мене є власні процедури збору сміття. Я помітив, що в wp_optionsтаблиці є всі мої перехідні значення (ті, що починаються з _transient_) autoload=no. Я очікую, що кількість рядків моєї wp_optionsтаблиці збільшиться зі збільшенням кількості одночасних користувачів.

Я хотів би знати, чому стіл розроблений таким чином. І чи слід створити індекс для мого конкретного випадку?

Відповіді:


11

Індексу немає, оскільки потреба в ньому ніколи не була достатньо сильною.

У квитку №14258 було запропоновано, але оскільки більшість параметрів використовуються autoload=yesза замовчуванням, індекс все одно буде ігноруватися.

Є ще відкритий квиток № 24044 _Додати індекс до wp_options, щоб допомогти / покращити продуктивність_ .

Я думаю, вам слід створити індекс. Він переживе оновлення. Це може не допомогти вашій ефективності, але ви можете додати до цього квитка реальні статистичні дані.


Оновлення листопада 2019 року

Індекс додано до WordPress 5.3. Нарешті. Дивіться згаданий вище квиток № 24044 та примітки розробника до випуску .

Зауважте, що якщо у вас є індекс з тим самим іменем, ви отримаєте попередження під час оновлення.

З набору змін :

Ця зміна не вплине на більшість сайтів, але ті, у кого велика кількість рядків wp_options, лише невелика кількість яких autoloadвстановлено, побачать значне поліпшення продуктивності.
Сайти з великою кількістю рядків wp_options, і багато з них autoloadвстановили, на жаль, побачать покарання за ефективність поверх уже дуже повільних запитів, які вони виконують, але це має бути меншою кількістю випадків.


1
Наскільки я можу зрозуміти, прочитавши # 24044, старі таблиці MyISAM отримали б регресію продуктивності, нові таблиці InnoDB здебільшого отримали б користь. Я перетворюю всі свої застарілі таблиці в InnoDB і встановлюю індекс на autoloadстовпчик.
lkraav

Після стількох років, нарешті, це вирішила команда WordPress. Індекс додано доwp_options.autoload . Джерела: make.wordpress.org/core/2019/10/15/… ... і ... core.trac.wordpress.org/ticket/24044#comment:87 ... Kudos to @DanBUK, який запропонував цю функцію у 2013.
Jee

Дякую, @Jee, я оновив відповідь.
fuxia

5

Я веду 3 блоги WP на великому екземплярі Debian Squeeze і досліджував, чому mysql застряг на цьому хості при 200% використанні процесора та завантаженні системи між 3 та 6. Подивившись на список показів списку процесів у mysql, ми зрозуміли, що У цій проблемі була задіяна таблиця wp_option, тому ми виконали:

alter table wp_options add index autoload_idx(`autoload`);

Після цієї операції навантаження mysql, як показано вгорі, різко впало до 1%, а середнє навантаження екземпляра зараз становить 0,10.

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

Наша таблиця wp_options містить 347 рядків.


2
Дякую, що поділились. Я вважав, що у WordPress був дефект в обробці цієї таблиці параметрів. Він настільки малий, що його не слід запитувати. Це повинно бути select *раз для всіх. Натомість, це запит для кожного варіанту, тому розміщення індексу призведе до великої різниці.
Він сяє

0

Хоча @fuxia приймає відповіді на деякі "заявлені" причини (більшість з яких заявляли працівники Automattic на різних квитках Trac тощо), основна причина WordPress Core, що не включає індекс для параметрів автоматичного завантаження в wp_optionsтаблиці, полягає в тому, що Автоматичний переживає, що це негативно вплине на продуктивність баз даних MySQL, які все ще використовували двигун MyISAM.

Зокрема, вони вказали на сам веб-сайт WordPress.org, будучи дуже старою / складною базою даних, як приклад веб-сайту, ефективність якого зашкодила б такий індекс.

Майже всі інші причини неприєднання індексу за останні 9 років (так, з 2010 року у випадку квитка на Trac № 14258 та з 2013 року у випадку квитка на Trac № 24044 ) були неодноразово підтверджені некоректними десятками членів Співтовариство WordPress, але співробітники Automattic неодноразово ігнорували кілька незалежних тестів на еталони та поверталися до згадок про проблеми MyISAM.

На щастя, наприкінці 2019 року з PHP 7.2 тепер "за замовчуванням" версія, рекомендована WordPress Core, і з двигуном InnoDB тепер за замовчуванням у версіях MySQL після 5,5 , і з постійним тиском з боку різних розробників, включаючи @DanBUK, які залишалися на проблемі роками , Automattic нарешті поступився і вирішив додати індекс автозавантаження на WordPress 5.3+ у листопаді 2019 року.

Ми в LittleBizzy запустили перший відомий плагін, який автоматично додав індекс, якщо його не було, який все ще доступний на GitHub і регулярно завантажується. Зверніть увагу, що вам НІКОЛЬШЕ не потрібно встановлювати такі плагіни у ваш стек WordPress, якщо ви працюєте з WP Core 5.3 + ...

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.