зеркало из
				https://github.com/iharh/notes.git
				synced 2025-10-31 05:36:08 +02:00 
			
		
		
		
	
		
			
				
	
	
		
			59 строки
		
	
	
		
			5.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			59 строки
		
	
	
		
			5.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 2021
 | |
| https://habr.com/ru/companies/postgrespro/articles/574702/
 | |
| 
 | |
| **********************************************************************************************************
 | |
| Подготовленные запросы (PREPARE statement) в PostgreSQL.
 | |
| 
 | |
| Вчера мы с вами поговорили (https://t.me/pg_guru/728) об этапах прохождения запроса и видах протоколов запросов в PostgreSQL. И упомянули о так называемых подготовленных запросах. В сегодняшнем посте более подробно поговорим об этой технологии.
 | |
| 
 | |
| Подготовленные запросы относятся к расширенному протоколу запросов и позволяют нам подготовить запрос заранее для выполнения, указав все необходимые параметры. Это может быть полезно, если у вас есть часто выполняющиеся одинаковые по сути запросы, отличающиеся только передаваемыми в них параметрами. С помощью подготовленных запросов мы можем проскочить этапы выполнения запроса, такие как разбор и трансформация, увеличив тем самым производительность.
 | |
| 
 | |
| Синтаксис подготовленного запроса будет таким:
 | |
| 
 | |
| PREPARE имя_запроса [ ( типы_данных [, ...] ) ] AS текст_запроса параметры_запроса;
 | |
| 
 | |
| Имя_запроса - произвольное имя подготовленного запроса. Пригодиться нам для последующего выполнения запроса;
 | |
| 
 | |
| Типы_данных - перечисляем типы данных, фигурирующих в запросе поочерёдно. Если не указать тип данных для параметра, то этот параметр будет выведен из контекста запроса, если это возможно;
 | |
| 
 | |
| Текст_запроса - собственно, текст самого запроса. Здесь может быть любой SQL-оператор: SELECT, INSERT, UPDATE, DELETE, MERGE или VALUES;
 | |
| 
 | |
| Параметры_запроса - перечисляем параметры нашего запроса в виде $1, $2 и т.д. Очередность параметров должна соответствовать очерёдности типов данных.
 | |
| 
 | |
| Пример:
 | |
| 
 | |
| PREPARE workers (INT, TEXT, DATE) AS
 | |
| INSERT INTO workers_info VALUES($1, $2, $3);
 | |
| 
 | |
| В ответ получим сообщение:
 | |
| 
 | |
| PREPARE
 | |
| 
 | |
| Что говорит об успешной подготовке запроса.
 | |
| 
 | |
| Теперь нам нужно выполнить подготовленный запрос. Для этого используется команда EXECUTE. Синтаксис будет таким:
 | |
| 
 | |
| EXECUTE имя_подготовленного_запроса (значение_первого_параметра, значение_второго_параметра, ...);
 | |
| 
 | |
| Продолжая наш пример, выполнение подготовленного запроса может выглядеть так:
 | |
| 
 | |
| EXECUTE workers (3, 'Ivan', '1982-01-01');
 | |
| 
 | |
| Чтобы удалить подготовленный запрос, используется команда DEALLOCATE. Синтаксис будет таким:
 | |
| 
 | |
| DEALLOCATE имя_подготовленного_запроса;
 | |
| 
 | |
| В нашем случае будет так:
 | |
| 
 | |
| DEALLOCATE workers;
 | |
| 
 | |
| Мы так же можем узнать какой план выбирает PostgreSQL для нашего подготовленного запроса:
 | |
| 
 | |
| EXPLAIN EXECUTE имя_подготовленного_запроса (значения_параметров);
 | |
| 
 | |
| Если PostgreSQL применит общий план запросов, то вместо значений параметров вы увидите символ $n в плане выполнения запросов, если это будет индивидуальный план, то вы увидите значения фактических параметров.
 | |
| 
 | |
| Подготовленные запросы существуют только в рамках одной сессии. Если сессия завершилась, то PostgreSQL забудет про такой запрос и в следующий раз его придется подготовить заново.
 | |
| 
 | |
| Подготовленные запросы дают максимальный выигрыш в производительности тогда, когда в одном сеансе выполняется много однотипных запросов, особенно если в запросах используются сложные операции объединения таблиц или еще какие-то. Подготовленные запросы позволяют PostgreSQL избежать лишней подготовки и трансформации запроса, что повышает производительность системы.
 | 
