.\" auto-generated by docbook2man-spec $Revision: 1.1 $ .TH "PREPARE" "7" "2003-11-02" "SQL - Language Statements" "SQL Commands" .SH NAME PREPARE \- 創建一個準備好的查詢 .SH SYNOPSIS .sp .nf PREPARE \fIplan_name\fR [ (\fIdatatype\fR [, ...] ) ] AS \fIstatement\fR .sp .fi .SH "DESCRIPTION 描述" .PP \fBPREPARE\fR 創建一個已準備好的查詢。 一個已準備好的查詢是服務器端的對象,可以用於優化性能。 在執行 PREPARE 語句的時候,指定的查詢被分析,重寫以及規劃。 當隨後發出 EXECUTE 語句的時候, 已準備好的查詢就只需要執行了。因此,分析,重寫,以及規劃階段都只執行一次,而不是每次查詢執行的時候都要執行一次。 .PP 準備好的查詢可以接受參數:在它執行的時候替換到查詢中的數值。 要給一個準備好的查詢聲明參數,我們需要在 PREPARE 語句裏包含一個數據類型的列表。在查詢本身裏,你可以按照位置來引用這些參數, 比如 $1,$2,等。 在執行查詢的時候,在 EXECUTE 語句裏爲這些參數聲明實際的數值。 參考 EXECUTE [\fBexecute\fR(7)] 獲取更多信息。 .PP 準備好的查詢是在本地存儲的(在當前後端裏),並且只是在當前數據庫會話的過程中存在。 如果客戶端退出,那麼準備好的查詢就會被遺忘,因此我們必須在被重新使用之前重新創建。 這也意味着一個準備好的查詢不能被多個同時的數據庫客戶端使用; 但是,每個客戶端可以創建它們自己的已準備好的查詢來使用。 .PP 如果一個會話準備用於執行大量類似的查詢,那麼已準備好的查詢可以獲得最大限度的性能優勢。 如果查詢非常複雜,需要複雜的規劃或者重寫,那麼性能差距將非常明顯。 比如,如果查詢設計許多表的連接,或者有多種規則要求應用。如果查詢的規劃和重寫相對簡單, 而執行起來開銷相當大,那麼已準備好的查詢的性能優勢就不那麼明顯。 .SH "PARAMETERS 參數" .TP \fB\fIplan_name\fB\fR 給予這個特定的已準備好查詢的任意名字。它必須在一個會話中是唯一的, 並且用於執行或者刪除一個前面準備好的查詢。 .TP \fB\fIdatatype\fB\fR 已準備好查詢的某個參數的數據類型。要在已準備好查詢內部引用這個參數,使用 $1,$2,等。 .TP \fB\fIstatement\fB\fR 任何 \fBSELECT\fR, \fBINSERT\fR, \fBUPDATE\fR, 或 \fBDELETE\fR 語句。 .SH "NOTES 注意" .PP 在一些情況下,PostgreSQL 爲一個已準備好的查詢生成的查詢規劃可能還不如按照普通方法提交併執行的查詢生成的規劃好。 這是因爲該查詢在被規劃的時候(也是優化器視圖判斷最優查詢規劃的時候), 在查詢中聲明的任何參數的實際數值都還不可見。 PostgreSQL 在表中收集數據分佈的統計, 而且可以利用查詢中的常量來猜測執行查詢的可能結果。 因爲這些數據在準備哪種帶參數的查詢的規劃的時候還不可得, 所以,選出來得規劃可能是次好的。 要檢查 PostgreSQL 爲已準備好的查詢選取的查詢計劃, 使用 \fBEXPLAIN EXECUTE\fR 。 .PP 有關查詢規劃和 PostgreSQL 爲查詢優化的目的收集的統計的更多信息, 參閱 ANALYZE [\fBanalyze\fR(7)] 文檔。 .SH "COMPATIBILITY 兼容性" .PP SQL 標準包含一個 PREPARE 語句, 但是它只用於嵌入的 SQL 客戶端。PostgreSQL 實現的 PREPARE 語句的語法也略有不同。 .SH "譯者" .B Postgresql 中文網站 .B 何偉平 .SH "跋" .br 本頁面中文版由中文 man 手冊頁計劃提供。 .br 中文 man 手冊頁計劃:\fBhttps://github.com/man-pages-zh/manpages-zh\fR