Основываясь на обмене комментариями, я полагаю, что вы должны одновременно рассматривать как транзакцию вставки, так и параллельные запросы. Вы хотите разместить их нагрузку, не теряя целостности транзакций. Доступные методы оптимизации включают в себя:
Добавление индексов доступа всякий раз, когда вы замечаете медленные конструкции (например, вложенные циклы) над большими наборами данных в планах выполнения часто просматриваемых или медленно выполняющихся запросов.
Добавление индексов покрытия. Эти индексы содержат дополнительные столбцы в дополнение к столбцам поиска, и они позволяют определенному запросу вообще избегать поездки в таблицу. Это особенно эффективно, когда таблица широкая, а индекс покрытия узкий, но ее также можно использовать, чтобы избежать проблем блокировки между UPDATE и SELECT для разных столбцов одних и тех же строк.
Денормализация. Например, переключение некоторых запросов для доступа к индексированным представлениям в отличие от физических таблиц или вторичных таблиц, снабженных триггерами при обновлении первичных таблиц. Это дорогостоящие и обоюдоострые методы, и их следует рассматривать только для устранения проверенных узких мест.
Вносите только те изменения, когда измеренное ускорение очень велико, поскольку ни один из этих методов не предоставляется бесплатно с точки зрения производительности. Никогда не оптимизируйте, не проводя измерения производительности на каждом этапе.
Это следующее тривиально, но давайте упомянем это для полноты - обновляйте статистику (ANALYZE, UPDATE STATISTICS, ... согласно вашему движку базы данных), как во время анализа планов выполнения, так и в производственное использование.