MySQL準備語句

MySQL準備語句(Prepared Statements), 使用增強的二進制用戶端/伺服器協定在用戶端和伺服器之間高效的發送資料，可以通過支援這種行協定的程式設計庫來通路準備語句。

     建立準備語句時，用戶端庫會像伺服器發送一個實際查詢的原型，然後伺服器對該原型進行解析和處理，将部分優化過的原型儲存起來，并且給用戶端傳回一個狀态句柄(State Handle) 用戶端可以通過定義狀态句柄重複的執行查詢。

     準備語句會比多次執行查詢效率高很多，具體原因如下：

     1、伺服器隻需要解析一次查詢，這節約了解析和其他開銷

     2、因為伺服器緩存了一部分執行計劃，是以它隻需要執行某些優化步驟一次。

     3、通過二進制發送參數比通過ASCII碼要快的多，比如，通過二進制發送DATE類型的參數隻需要3位元組，但通過ASCII碼發送需要10個位元組。解決的效 果對于BLOB和TEXT類型最為顯著。因為他們可以成塊的發送。而不是一個個的發送。二進制協定也幫用戶端節約了記憶體，同時減少了網絡開銷和資料從本身 的類型轉換為非二進制協定的開銷。隻有準備語句能使用二進制協定，使用普通的MSYQL_QUERY()函數送出查詢不會使用二進制協定。

     4、整個查詢不會被發送到伺服器。隻有參數才會被發送，減少了網絡流量。

     5、MYSQL直接吧參數儲存在伺服器的緩沖區内，不需要在記憶體中到處拷貝資料。

     6、語句對于安全性也有好處，它不需要在應用程式中對值進行轉移和加引号。這更加友善，并且減少了SQL遭受注入攻擊和其他攻擊的可能(永遠也不能信任使用者的輸入，即使使用準備語句也不能)。   

準備語句的局限：

1、準備語句隻針對一個連接配接，是以另外的連接配接不能使用同樣的句柄，處于同樣的原因，一個先斷開再重新連接配接的用戶端會丢失句柄(連接配接池活持續連接配接會減輕這個問題)

2、準備語句不能使用MYSQL5.0以前的版本緩存

3、使用準備語句并不總是高效，如果隻使用一次準備語句，那麼準備它花費的時間可能比執行一次平常的SQL語句更長，準備語句也需要在伺服器和用戶端之間進行額外的資訊互動。

4、.如果忘記銷毀準備語句，那麼就有可能引起資源洩露，這會消耗相當多的伺服器資源，同樣，因為對存儲語句的數量有一個全局性的限制，是以一個錯誤可能會幹擾其他使用準備語句的連接配接。

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/980284，如需轉載請自行聯系原作者