Бих написал заявката така:
SELECT c.time
, SUM(c.counter)
, MAX(p.clustername) AS clustername
FROM cell c
JOIN swap_plan p
ON p.siteid = c.siteid
AND p.clustername = 'Cluster A'
WHERE c.time >= 'day1'
AND c.time <= 'day2'
GROUP
BY c.time
Бих се уверил, че имам индекс в cell с time като водеща колона.
MySQL може да използва същия индекс, за да удовлетвори предиката на диапазона (в клаузата WHERE) и да удовлетвори GROUP BY без операция „Използване на сортиране на файлове“.
... ON cell (time)
В зависимост от размерите на колоните, индексът на покриване може да даде оптимална производителност. Покриващ индекс включва всички колони от таблицата, които са посочени в заявката, така че заявката може да бъде удовлетворена изцяло от индексни страници, без да се търси страници в основната таблица.
... ON cell (time, siteid, counter)
За индекса на swap_plan , ще имам индекс с site_id като водеща колона, включително clustername колона, едно от следните:
... ON swap_plan (clustername, site_id)
или
... ON swap_plan (site_id, clustername)
Изглежда вероятно ще има УНИКАЛНО ограничение за комбинацията от тези две колони, т.е. стойностите на site_id ще бъде различен за даден clustername . (Ако това не е така, и същият (site_id,clustername) кортежът се появява няколко пъти, има потенциал за агрегирана обща сума от counter да се надуе.
Ще търся EXPLAIN изход за показване на справка за търсене на swap_plan таблица от стойността на c.siteid и const (буквално „Клъстер А“) стойност за име на клъстер.
С таблици с размери 31 и 368 реда няма да видим значителна разлика в производителността (изминало време) между оптимален план за изпълнение и ужасен план за изпълнение.
Когато някоя от таблиците се мащабира до милиони редове, тогава разликите ще станат очевидни. Изборът на план за изпълнение на оптимизаторите се влияе от статистическите данни (размер, брой редове, мощност на колони) на всяка таблица, така че планът за изпълнение може да се промени с увеличаване на размерите на таблицата.
