Имам заявка, която се генерира в зависимост от разни условия.

SELECT
FROM a
JOIN b on a.b_id = b.b_id
LEFT JOIN c on a.c_id = b.c_id
LEFT JOIN d on b.d_id = d.d_id
ORDER BY b.some_date

Не пействам самата заявка, но това е основата. Проблемът е, че вместо да ползва индекса по some_date, mysql прави temporary и filesort и убива заявката.

SELECT
FROM a
JOIN b USE INDEX (ix_some_date) on a.b_id = b.b_id
LEFT JOIN c on a.c_id = b.c_id
LEFT JOIN d on b.d_id = d.d_id
ORDER BY b.some_date

Работи коректно.

SELECT
FROM a
JOIN b on a.b_id = b.b_id
LEFT JOIN c on a.c_id = b.c_id
LEFT JOIN d on b.d_id = d.d_id
LEFT JOIN e on a.id = e.a_id
LEFT JOIN e on b.id = f.b_id
ORDER BY b.some_date

Добавянето на 4-ти и 5-ти join водят до това, че индекса се ползва правилно. Добавянето на 7-и join води до невъзможност да се изпълнят заявките.

Промяната на order by:
order by g.some_date, b.some_date
води до неупотреба на индексите по 2-те полета за дата, като заявката се забавя поносимо.

Всички таблици имат самостоятелни индекси по ID и ордер полетата, Unique key по уникалностите им.

Основните таблици a и b са 140 000 записа и 1600 записа, другите са таблици са малки - ключ-стойност.

Всички опити да премахна 1 от абсолютно безполезните join-ове водят до незабавно умиране на сървъра :)

Таблиците са MyISAM. MySQL е 5.0

SOS?

Редактирано от dzver на 31.05.09 13:37.

temporary и filesort са задължителни в случая. ORDER BY не може да работи само с индекс когато имаш повече от една таблица.

Въпросът е temporary да не отива на диска в tmpdir

Ползвай FORCE INDEX() когато си сигурен, че някой индекс ще свърши работа не USE INDEX()

Съдържаниет е скрито
Влезте за да го видите

Не е точо така, ако селект-ваш колони от а жоин с б и сортировка по дейт индекаса би трябвало да се ползвва. Ако в секекта имаш колони от а и б тогава темп + файлс сорт са неизбежни. Възможна оптимизация е насочването на тмп дир на май ескуел към отделен бърз хард, добавяне на повече рам и увеличаване на тмп таблес и тмп макс саиз (бяха 2 променливите), или моунт на рам диск и насочване на тмп дир на там, последното ако не си наясно не го прави.
Като цяло ако няма да жоинваш огромни таблици с милиони записи препоръчвам ти да пробваш 2то предложение ако не 1то.
Друг вариант е промяна заявката да ползваш момори таблица селецтваш квото ти трябва ръгаш го в мемори таблица и го селецт-ваш сортирано.
Прочети за thread buffers в документацията и си увеличи сорт и жоийн буферите, в зависимост от паметта на сървара. Имаи предвид че те са за всяка заявка отделно така че обикновенно са между 2-10мб.

Пейст explain на заявката и също какви колони селектваш.
Дефинитиона на таблиците

Оправи си правописа малко.

Като имам предвид опита на dzver с MySQL не бих посмял да го съветвам да чете за thread buffers

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Стига с този правопис бе, да не пиша официални документи че да си преглеждам грешките, които допускам при писане с калвиатура. Не съм машинописка, който не иска да ми чете съветите заради правопис, той може да загуби.

Съдържаниет е скрито
Влезте за да го видите