SergeiSF wrote:
> То есть FKs — для поддержания целостности данных, на reads не влияют, но > тормозят CUD,имеет смысл их не использовать, а ручками (скриптом) > ровнять и чистить раз в день/месяц/год
Думаю, однозначного ответа на этот вопрос быть не может.
Зависит от предпочтений программиста и особенностей приложения.
Я так (т.е. БД без FK) никогда не делаю.
> Индексы же — тож тормозят CUD, но резко ускоряют reads/joins/etc. > вроде так.
Нет. Они ускоряют и CUD тоже.
Индексы могут ускорять read,
могут ускорять CUD, и всегда немного (на O(logN) ) замедляют
CUD.
SergeiSF wrote:
> MZ>Тоже не всегда. Только когда надо. НО тут это никак не отличается > MZ>от случая, когда JOIN-ы просто , без FK.
> MasterZiv, а когда надо то?
Для JOIN-ов нужны индексы, когда они ускоряют JOIN.
В частности, если одна из таблиц маленькая, то по ней
индексы на поля JOIN-ов в общем-то безполезны.
Также нужно отметить, что в JOIN-е всегда выступают две
таблицы, для алгоритма NLJ (nested loop join) они называются
внешняя и внутренняя (не путать с внешней и внутренней в OUTER
JOINs). Так вот индекс нужен только по внутренней таблице.
Но JOIN-ы могут выполняться не только по NLJ, там могут быть
уже другие требования.
Из практики, FK как то влияют на > производительность queries?
На чтение они никак не влияют.
На запросы на запись они, естественно, влияют,
и могут достаточно сильно влиять.
При вставке доч. таблицы проверяется наличие записей в род.
таблице. Соотв, нужен индекс по род. таблице,
но он обычно — PK род. таблицы.
При удалении записей род. таблицы проверяется наличие
записей в доч. таблице, если она большая, хорошо бы иметь
индекс. При каскадном удалении удаляются записи доч. таблицы,
тоже хорошо бы иметь индекс, если таблица большая.
Однако если эти операции КРАЙНЕ РЕДКИ, то ЛУЧШЕ индексы
всё-таки НЕ ДЕЛАТЬ. Лучше СУБД один раз в месяц попыхтит
10 минут, чем каждую секунду будет подтормаживать.
Добрый день!
Столкнулся с необходимостью ускорить толпу sprocs с толпой joins в них.
В БД практически нет индексов. Думаю начать с них.
Какие основные рекомендации создания индексов? (БД в основном RO, writes only 4-5 times a day)
Какие примеры посмотреть, какие статьи почитать?
Здравствуйте, SergeiSF, Вы писали:
SSF>Добрый день! SSF>Столкнулся с необходимостью ускорить толпу sprocs с толпой joins в них.
Ну минимум индексы: первичные ключи, внешние ключи, ограничения уникальности.
SSF>В БД практически нет индексов. Думаю начать с них. SSF>Какие основные рекомендации создания индексов? (БД в основном RO, writes only 4-5 times a day) SSF>Какие примеры посмотреть, какие статьи почитать?
Первичные ключи и так индексы создают сами, то же про Unique constraint.
А вот на вненшие ключи (на поля дочерних таблиц, пронесённые из
родительской таблицы) создавать индексы вовсе не обязательно.
Когда-то — надо , когда -то -- нет, зависит от приложения.
Здравствуйте, MasterZiv, Вы писали:
MZ>_d_m_ wrote:
>> Ну минимум индексы: первичные ключи, внешние ключи, ограничения >> уникальности.
MZ>Первичные ключи и так индексы создают сами, то же про Unique constraint.
В курсе.
MZ>А вот на вненшие ключи (на поля дочерних таблиц, пронесённые из MZ>родительской таблицы) создавать индексы вовсе не обязательно. MZ>Когда-то — надо , когда -то -- нет, зависит от приложения.
Здравствуйте, SergeiSF, Вы писали:
SSF>Столкнулся с необходимостью ускорить толпу sprocs с толпой joins в них. SSF>В БД практически нет индексов. Думаю начать с них. SSF>Какие основные рекомендации создания индексов? (БД в основном RO, writes only 4-5 times a day) SSF>Какие примеры посмотреть, какие статьи почитать?
Посмотрите планы выполнения тормозящих запросов. Если где увидите table scan или index scan, то подумайте, не поможет ли там индекс.
Если самостоятельного опыта мало можно попробовать воспользоваться Database Engine Tuning Advisor. Штука не сильно умная, но в простых случаях помочь может.
Кстати, имейте в виду, что кроме индексов повышать производительность можно и другими способами, часто не менее эффективными: убирать ненужные запросы, выпрямлять нужные, кэшировать промежуточные результаты, менять структуру таблиц...
В общем, это, скорее, творческая задача.
vmpire, спасибо за подробный ответ
V>Здравствуйте, SergeiSF, Вы писали: V>Посмотрите планы выполнения тормозящих запросов. Если где увидите table scan или index scan, то подумайте, не поможет ли там индекс.
Да, этим и занимаюсь. На что ещё обращать внимание кроме table scan или index scan? Какие ещё есть подозрительные элементы? Какие есть еще признаки(кроме интуиции) что запрос еще можно как-то оптимизировать?
V>Если самостоятельного опыта мало можно попробовать воспользоваться Database Engine Tuning Advisor. Штука не сильно умная, но в простых случаях помочь может.
Попробую этого зверя.. Есть какие либо удобные инструменты сторонних разработчиков?
V>В общем, это, скорее, творческая задача.
Как всегда
Здравствуйте, MasterZiv, Вы писали: >> Ну там же речь про джойны? Как-бы надо. MZ>Тоже не всегда. Только когда надо. НО тут это никак не отличается MZ>от случая, когда JOIN-ы просто , без FK.
MasterZiv, а когда надо то? Из практики, FK как то влияют на производительность queries?
Или они только для поддержки целостности данных?
Здравствуйте, MasterZiv, Вы писали: >> MasterZiv, а когда надо то? MZ>Для JOIN-ов нужны индексы, когда они ускоряют JOIN.
... MZ>уже другие требования. MZ>Из практики, FK как то влияют на >> производительность queries? MZ>На чтение они никак не влияют. MZ>На запросы на запись они, естественно, влияют, MZ>и могут достаточно сильно влиять.
... MZ>Однако если эти операции КРАЙНЕ РЕДКИ, то ЛУЧШЕ индексы MZ>всё-таки НЕ ДЕЛАТЬ. Лучше СУБД один раз в месяц попыхтит MZ>10 минут, чем каждую секунду будет подтормаживать.
Спасибо за детальный ответ — чётко и понятно
То есть FKs — для поддержания целостности данных, на reads не влияют, но тормозят CUD,имеет смысл их не использовать, а ручками (скриптом) ровнять и чистить раз в день/месяц/год
Индексы же — тож тормозят CUD, но резко ускоряют reads/joins/etc.
вроде так.
P.S. Спасибо участникам топика — исходная задача решена, добавлено сколько-то индексов и БД стала летать как и далжна. след оптимизация когда объём данных вырастет в раз так 10. + к индексам были почищены пара таблиц и исправлены баги в queries, которые увеличивали количество inserts во много много раз
Здравствуйте, SergeiSF, Вы писали:
V>>Посмотрите планы выполнения тормозящих запросов. Если где увидите table scan или index scan, то подумайте, не поможет ли там индекс. SSF>Да, этим и занимаюсь. На что ещё обращать внимание кроме table scan или index scan? Какие ещё есть подозрительные элементы? Какие есть еще признаки(кроме интуиции) что запрос еще можно как-то оптимизировать?
Ещё можно посмотреть, не выполняется ли одна и та же операция много раз, не повторяется ли один и тот же запрос, нет ли в запросе нескольких joinов с одной таблицей по одному и тому же условию, нельзя ли переписать или исключить запросы с distinct или union, не вытаскивается ли ненужных данных, нет ли неиспользуемых индексов (для этого даже репорт готовый есть), нет ли в запросе конструкций, которые не дают задействовать индексы (выражения по индексированному полю, outer joinы), нет ли, наконец, курсоров и триггеров, не вызываются ли в запросе скалярные функции, нет ли связанных подзапросов...
В общем, посмотреть можно на многое
