Яке значення відфільтрованого в MySQL пояснюють?

Як описано тут у документах MySQL :

Відфільтрований стовпець вказує орієнтовний відсоток рядків таблиці, які будуть відфільтровані за умовою таблиці. Тобто рядки показують орієнтовну кількість досліджуваних рядків, а рядки × відфільтровані / 100 показують кількість рядків, які будуть об’єднані з попередніми таблицями. Перед MySQL 5.7.3 цей стовпець відображається, якщо ви використовуєте EXPLAIN EXTENDED. Як і в MySQL 5.7.3, розширений вихід увімкнено за замовчуванням, а ключове слово EXTENDED непотрібне.

Я досі не розумію. Яке значення тут «фільтрується»? Яку інформацію ми можемо отримати з цього стовпця?

Наприклад, коли я розпочинаю запити, деякі запити показуватимуть 100, а деякі інші показують 18 або менше 100.

+-------------+-------+--------+---------+---------+------+----------+
| select_type | table | type   | key     | key_len | rows | filtered |
+-------------+-------+--------+---------+---------+------+----------+
| PRIMARY     | a     | range  | search  | 4       |  174 |   18.00  | <--
| PRIMARY     | b     | eq_ref | PRIMARY | 4       |    1 |   100.00 |
| PRIMARY     | c     | ALL    | PRIMARY | 4       |    1 |   100.00 |

Який головний момент ми можемо зробити з цього значення?

Це сказано, колонка фільтрувала лише 18%? Або якщо чим нижчий показник, тим кращий показник / запит?

Я використовую MySQL 5.7

Фільтрувати тут означає застосувати умову до набору рядків, які були вибрані a type-search як потенційні рядки, і зберігати лише рядки, які відповідають умові:

Спочатку MySQL спробує використати індекс, наприклад, rangeскануйте ваш стіл aза допомогою search-key. За підрахунками, за допомогою цього індексу вийде 174 рядки, що є числом у rows. Цей крок ще не називається фільтруванням.

Після цього ці 174 рядки потрібно перевірити на додаткові умови (як правило, у вашій where-класі). MySQL тепер підрахував, що після застосування цього фільтра залишиться лише 32 рядки, тобто 18% з цих 174 рядків. Це 18% - це значення в filtered.

Хоча, очевидно, краще мати 32 рядки замість 174 (якщо, наприклад, вам доведеться пізніше joinїх з іншою таблицею), "ідеальний" індекс дав би вам ці 32 ряди безпосередньо з початкового пошуку, заощадивши час на перегляд і відфільтрувати 82% усіх потенційних рядків.

Таким чином, низьке значення може вказувати на те, що може бути кращий індекс: наприклад, сканування повної таблиці за допомогою rows=1000та filtered=0.1%може стати пошуком індексу, rows=1і filtered=100%якщо ви додасте хороший індекс.

З іншого боку, ви можете дуже добре проігнорувати цю filteredцінність (яка в більшості випадків є дійсно поганою оцінкою) і зосередитись на інших важливіших стовпцях (особливо type, keyта extra) для оптимізації запиту. Наприклад, може бути краще позбутися filesort(наприклад, за допомогою індексу, який задовольняє order by), навіть якщо це призводить до нижчого filteredзначення. А краще typeможе призвести до величезного покращення продуктивності, навіть якщо воно не зміниться або навіть знизиться filtered. У наведеному вище прикладі з filtered=0.1%, type=allвже було б достатньо, щоб вказати, що ви могли б покращити цей запит, додавши індекс, не дивлячись filteredна це взагалі.

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