Когато добавянето на индекс забавя нещата

Таблицата с дневните стойности има един ключ: броячът и датата заедно. Пет места в кода ѝ задават различен въпрос — не „този брояч във времето“, а „всички броячи на тези дати“. Галерията на началната страница, класацията, картата на сайта, 90-дневна диаграма и статусните показатели. Без индекс върху колоната с датата всяко от тях чете всичките 114 113 реда.

Добавянето на този индекс прави галерията десет пъти по-бърза. Той не беше добавен. Ето измерването, което реши въпроса.

Една заявка стана много по-бърза

Галерията иска броячите, които са били активни днес. Без индекс върху датата тя обхожда цялата таблица; с индекс търси една-единствена дата и чете 443 реда. 61,5 милисекунди станаха 6,1. Това не е незначителен резултат и ако беше единственото измерено нещо, индексът сега щеше да е в базата данни.

Две заявки станаха по-бавни

Картата на сайта иска четиринадесет дни и стана с 19% по-бавна. Статусните показатели искат година и станаха с 10% по-бавни. И в двата случая планировчикът на заявки премина от първичния ключ към новия индекс и направи по-лош избор.

Това е частта, която си струва да се разбере, защото не е грешка в планировчика. Четенето на диапазон през вторичен индекс означава да се намерят съответните редове в индекса и после всеки от тях да се извлече от таблицата. За тесен отрязък това е изгодно. За четиринадесет дни от тринадесет месеца това все още са много редове, извличани един по един, и прякото обхождане на таблицата — четене във физическия ѝ ред, което дисковете и кешовете харесват — го бие. Планировчикът не знае това. Той вижда диапазон и индекс и го използва.

Няма начин да се каже „използвай този индекс само за галерията“. Индексът е достъпен за всяка заявка, която засяга колоната, и планировчикът ще го използва навсякъде, където оценките му казват, че трябва. Добавянето на индекс е промяна за всяка заявка към тази таблица, а не само за онази, за която е предназначен.

Общо: нищо

За всичките пет 555 милисекунди станаха 524. Подобрение 1,1×, което на малък сървър, обслужващ тези страници така или иначе от кеш, не си струва промяна в схемата.

90-дневната диаграма изглежда подобрена с 9%. Това не се брои и си струва да се каже защо. Всяка заявка беше измерена три пъти: без индекса, с него и после отново без него. Ако второто изпълнение без индекса не попадне близо до първото, разликата се дължи на машината, а не на промяната. При 90-дневната диаграма двете изпълнения без индекса се различаваха с 13,8% — повече от заявения ефект. Така този ред не измерва нищо и се отчита като нищо.

Как беше измерено това и защо е важно

Не върху работещата таблица. Скриптът я копира, работи върху копието и накрая изтрива копието. Добавянето на индекс към производствена таблица, за да се види какво ще стане, работи само веднъж на изненада.

Заявките са истинските, взети от кода, включително съединяването с таблицата с броячи. По-ранна версия на този тест използваше опростен заместител и даде много по-вълнуващ отговор: двадесет пъти по-бързо. Опростената заявка не беше такава, каквато нещо наистина изпълнява.

Какво щеше да бъде числото

Ако това беше измерено по обичайния начин — вземаш заявката, която изглежда бавна, и засичаш времето преди и след — отговорът щеше да бъде „десет пъти по-бързо, пускай“. Индексът щеше да бъде добавен, галерията щеше да се ускори, картата на сайта и статусната страница щяха да се забавят и никой нямаше да свърже двете неща, защото никой не следеше тях.

Това е общата форма. Промяна в споделена инфраструктура не може да бъде оценена по случая, който я е породил. Въпросът не е „помага ли това на нещото, което гледам“, а „какво друго засяга това и какво става с него“.

Има вариант, който може да проработи: индекс с двете колони, с датата на първо място, така че галерията да получава отговор само от индекса, без да се връща към таблицата. Той може и да не изкушава планировчика при по-широките диапазони. Това не е измерено, затова не е препоръка — а следващото нещо, което да се изпробва върху копието.