Некоторые другие моменты (мои основаны на SQL-сервере, так как каждый бд-база данных имеет свои собственные реализации, которые они могут или не могут иметь место для всех баз данных):
Избегайте коррелированных подзапросов в части выбора оператора, они по сути являются курсорами.
Создайте таблицы с использованием правильных типов данных, чтобы избежать необходимости применять к ним функции для вывода данных. Гораздо сложнее вычислить дату, когда вы сохраняете свои данные, например, как varchar.
Если вы обнаружите, что вы часто делаете объединения, в которых есть функции, то вам нужно подумать о редизайне ваших таблиц.
Если ваши условия WHERE или JOIN включают операторы OR (которые работают медленнее), вы можете получить лучшую скорость, используя оператор UNION.
UNION ALL работает быстрее, чем UNION, если (и только если) два параметра взаимоисключающие и в любом случае возвращают одинаковые результаты.
NOT EXISTS обычно быстрее, чем NOT IN или использует левое соединение с предложением WHERE ID = null
В запросе UPDATE добавьте условие WHERE, чтобы убедиться, что вы не обновляете значения, которые уже равны. Разница между обновлением 10 000 000 записей и 4 может быть весьма значительной!
Подумайте о предварительном расчете некоторых значений, если вы будете часто их запрашивать или для больших отчетов. Сумма значений в заказе должна быть сделана только тогда, когда заказ выполнен или скорректирован, а не при суммировании результатов 10 000 000 миллионов заказов в отчете. Предварительные расчеты следует выполнять в триггерах, чтобы они всегда были актуальными и лежали в основе изменений данных. И это не обязательно должны быть просто числа, у нас есть вычисляемое поле, объединяющее имена, которые мы используем в отчетах.
Остерегайтесь скалярных UDF, они могут быть медленнее, чем помещать код в строку.
Временная таблица, как правило, быстрее для больших наборов данных и табличных переменных быстрее для маленьких. Кроме того, вы можете индексировать временные таблицы.
Форматирование обычно выполняется быстрее в пользовательском интерфейсе, чем в SQL.
Не возвращайте больше данных, чем вам действительно нужно.
Это кажется очевидным, но вы не поверите, как часто я в конечном итоге исправляю это. Не присоединяйтесь к таблицам, которые вы не используете для фильтрации записей или фактического вызова одного из полей в части выбора оператора. Ненужные объединения могут быть очень дорогими.
Очень плохая идея создавать представления, которые вызывают другие представления, которые вызывают другие представления. Вы можете обнаружить, что присоединяетесь к одной и той же таблице 6 раз, когда вам нужно только один раз, и создаете 100 000,00 записей в базовом представлении, чтобы получить 6, которые находятся в вашем конечном результате.
При проектировании базы данных подумайте о том, чтобы сообщать не только о пользовательском интерфейсе для ввода данных. Данные бесполезны, если они не используются, поэтому подумайте о том, как они будут использоваться после того, как они будут в базе данных, и как эти данные будут поддерживаться или проверяться. Это часто меняет дизайн. (Это одна из причин, почему плохая идея позволить ORM проектировать ваши таблицы, он думает только об одном сценарии использования данных.) Наиболее сложные запросы, влияющие на большинство данных, связаны с отчетностью, поэтому разработка изменений помогает составлять отчеты. может значительно ускорить (и упростить) запросы.
Реализации функций для конкретной базы данных могут быть быстрее, чем при использовании стандартного SQL (это один из способов, с помощью которого они продают свой продукт), поэтому познакомьтесь с функциями вашей базы данных и выясните, какие из них быстрее.
И поскольку это нельзя сказать слишком часто, используйте индексы правильно, не слишком много или слишком мало. И сделайте ваши предложения WHERE саргабельными (умеющими использовать индексы).