Привет!
IB 5.6
Есть таблица
CREATE TABLE MONTH_INCOME (
DATE_CODE DATE_CODE NOT NULL,
EMP_CODE INTEGER NOT NULL,
SHIFR SHIFR NOT NULL,
MANUAL_ENTERED BOOL,
SUMMA SUMMA NOT NULL);
/* Primary keys definition */
ALTER TABLE MONTH_INCOME ADD CONSTRAINT PK_MONTH_INCOME PRIMARY KEY (EMP_CODE, SHIFR, DATE_CODE);
/* Indices definition */
CREATE INDEX MONTH_INCOME_IDX1 ON MONTH_INCOME (DATE_CODE, SHIFR, EMP_CODE);
SELECT SUM(SUMMA)
FROM MONTH_INCOME
WHERE DATE_CODE BETWEEN 200801 AND 200809 AND
SHIFR = 3165 AND EMP_CODE = 11111
использует
PLAN (MONTH_INCOME INDEX (RDB$PRIMARY51,MONTH_INCOME_IDX1))-это 6 сек!!!
при принудительном плане
PLAN (MONTH_INCOME INDEX (RDB$PRIMARY51))-15 милисекунд
Как бы опимизировать работу интербейса с индексами?
Потому как при общих выборках нужен именно индекс MONTH_INCOME_IDX1-без него другие запросы тормозят
Проблема с индексами
Re: Проблема с индексами
Тяжёлый случай.AlexTrump писал(а):IB 5.6
Если нельзя убрать второй индекс, то только план руками написать. Конечно, во исключение самопроизвольного переименования PK придётся завести такой же именованный индекс.AlexTrump писал(а):Как бы опимизировать работу интербейса с индексами?
Можно ещё WHERE DATE_CODE+0 BETWEEN 200801 AND 200809 попробовать, если по остальным полям записей немного отбирается, и религия не позволяет план писать руками.
Например?AlexTrump писал(а):Потому как при общих выборках нужен именно индекс MONTH_INCOME_IDX1-без него другие запросы тормозят
Re: Проблема с индексами
Хм,чудо
WHERE DATE_CODE+0 BETWEEN 200801 AND 200809 сработало...
Может объясните механизм этого действия?
Что 5.6-да,тяжелый случай...
Но на 6+ переход не сразу получится-в базе используются зарезервированные для 6+ ключевые слова-базу то я могу привести к нормальному виду,но это надо и клиента править. Стоит ли овичнка выделки?
Намного ли самые последние версии будут производительнее чем 5.6?
WHERE DATE_CODE+0 BETWEEN 200801 AND 200809 сработало...
Может объясните механизм этого действия?
Что 5.6-да,тяжелый случай...
Но на 6+ переход не сразу получится-в базе используются зарезервированные для 6+ ключевые слова-базу то я могу привести к нормальному виду,но это надо и клиента править. Стоит ли овичнка выделки?
Намного ли самые последние версии будут производительнее чем 5.6?
Re: Проблема с индексами
Индекс может использоваться только для сравнения на "=", ">=", "<="AlexTrump писал(а): WHERE DATE_CODE+0 BETWEEN 200801 AND 200809 сработало...
Может объясните механизм этого действия?
Если поле участвует в выражении, то индекс по нему не применяется.
Индекс же может использоваться частично если идёт сравнение с первыми столбцами.
Следовательно будет использоваться только ПК и то частично.