Руководство по созданию эффективных запросов

д
ва
 
сПосоБа
 
оПтимизаЦии
 
модификаЦии
 
данных
Выполнение любой команды DML состоит из двух частей: выбора записей, 
которые нужно изменить, и самого изменения данных. В случае с 
INSERT
пер-
вая часть может быть опущена при вставке констант. Однако если исполь-
зуется конструкция 
INSERT-SELECT
, сначала должны быть найдены записи, 
необходимые для вставки.

---

158

Оптимизация модификации данных
По этой причине оптимизация команды DML состоит из двух частей: оп-
тимизации выборки и оптимизации модификации данных.
Если проблема заключается в выборке, то следует оптимизировать именно 
часть 
SELECT
, что подробно описано в предыдущих главах. Данная глава по-
священа второй части – оптимизации записи данных.
В подавляющем большинстве случаев даже системы OLTP выполняют зна-
чительно меньше команд DML, чем команд 
SELECT
. Это основная причина 
того, что люди редко говорят об оптимизации DML. Однако длительно ра-
ботающие команды DML могут вызвать проблемы не только потому, что 
обновленные данные не будут своевременно доступны в системе, но также 
из-за возможности появления 
блокирующих
замкóв
(locks), которые замедля-
ют выполнение других команд.
к
ак
 
раБотает
 DML?
Чтобы обсуждать оптимизации, применимые к командам SQL для модифи-
кации данных, потребуется еще немного теории.
Низкоуровневый ввод-вывод
В конечном итоге любая операция SQL, какой бы сложной она ни была, сво-
дится к паре низкоуровневых операций: чтению и записи отдельных блоков 
базы данных. Причина проста: данные, содержащиеся в базе, могут быть 
обработаны только при извлечении блоков в оперативную память, и все из-
менения сначала выполняются в памяти, а уже затем записываются на диск.
Фундаментальное различие между операциями чтения и записи состоит 
в том, что чтение с диска должно быть завершено до того, как данные можно 
будет обработать; таким образом, команду 
SELECT
нельзя завершить до того, 
как все необходимые блоки будут загружены в память. Напротив, измене-
ния данных внутри блока завершаются до начала записи; таким образом, 
операцию SQL можно завершить без задержек. Нет необходимости ждать, 
пока измененные данные действительно будут записаны на диск. Это может 
показаться нелогичным: обычно представляется, что обновление требует 
больше ресурсов, чем чтение.
Конечно, для записи действительно требуется гораздо больше ресурсов, 
чем для чтения: база данных должна изменять индексы и регистрировать 
обновления в журнале предзаписи (WAL, write-ahead log). Тем не менее это 
происходит в оперативной памяти, если речь идет об отдельных командах 
DML. Журнальные записи принудительно сбрасываются на диск только при 
фиксации.
Выходит, любая команда 
INSERT
, 
UPDATE
или 
DELETE
выполняется намного 
быстрее, чем 
SELECT
. Это здорово, но зачем тогда нужна оптимизация?
Есть две основные причины. Во-первых, запись на диск все равно необхо-
дима и, следовательно, потребляет некоторое количество аппаратных ресур-

---

Как работает DML 

159
сов, в основном пропускную способность ввода-вывода. Затраты на операции 
запи си амортизируются и не обязательно отражаются на какой-либо отдель-
ной операции, но все же замедляют обработку и могут даже повлиять на произ-
водительность запросов. Дополнительную рабочую нагрузку создают фоновые 
и обслуживающие процедуры (например, запись измененных блоков на диск).
Обычно при обслуживании выполняется реструктуризация данных, напри-
мер при операции 
VACUUM
в PostgreSQL. Некоторые задачи реструктуризации 
блокируют доступ к изменяемому объекту на все время реструктуризации.
Во-вторых, модификации могут мешать другим модификациям и даже 
поиску. Пока данные не изменяются, порядок обработки не имеет значе-
ния. Данные могут быть доступны одновременно из разных команд 
SELECT
. 
Но модификации не могут выполняться одновременно, и в этом случае все 
решает порядок выполнения операций. Чтобы обеспечить корректность дан-
ных, некоторые операции приходится откладывать или даже отклонять. За 
корректность отвечает подсистема управления одновременным доступом 
(подсистема обработки транзакций). Обработка транзакций не является те-
мой данной книги; однако при обсуждении модификаций нельзя избежать 
соображений, связанных с транзакционным поведением СУБД.