我正在考慮切換到所有我的PHP項目的mysqli。我的代碼編寫的方式（我運行非常簡單的網站，並構建了我自己的基本框架，我使用它們）我不應該有太多修改函數和類的問題。切換到mysqli一個好主意？
但是，我只聽說過有關準備好的語句的積極的事情，關於可用的PHP函數的一些抱怨，最值得注意的是缺乏使用mysql_fetch_array的簡單替換。
這聽起來有點太好了，所以我想知道是否有人可以強調使用準備語句的一些問題，如速度和資源使用情況。
如果您習慣於將變量附加到查詢字符串中，那麼對已準備語句的編程需要一些習慣。 MySQL使用位置參數（您的查詢將包含替換變量所屬的問號）。最好的辦法是把它放到你現有的數據庫抽象中。如果該抽象是正確編寫的，那麼不應該在包裝器外部調用mysql_fetch_array。
這個問題的解決方案只是預先收集所有的行，但當然，假設您不檢索1000行，只是要求第一個。無論mysqli如何，這都是你應該做出的改變。
最後，某些語句不容易被參數取代，例如使用in('x', 'y', 'z')語法的參數可變數量的查詢。它可以完成，但你可能想要豐富你的數據庫抽象，以允許它創建查詢並執行它們。
然而，在性能和安全性方面，權衡是絕對值得的。 PHP端的附加處理通常超過了MySQL端查詢的緩存執行計劃，而且您不受許多最常見的SQL注入漏洞的影響。
希望幫助， 喬
預處理語句是那麼好，一旦你習慣了他們這是痛苦再次使用轉義功能。期。
但是，我曾經使用過的所有數據庫庫（包括oci8和sqlsrv ...）都引入了一個怪癖或另一個。所以我基本上封裝我用一組簡單的提供在道路的特色定製類的使用任何圖書館我喜歡：
WHERE foo = :foo$params = array('foo' => 33)$res = $Db->query($sql, $params);foreach($res as $row)採用這樣的策略使得確切的語法或函數設置不那麼重要。無論如何，儘管這可以在幾乎所有的庫中實現，但它提供了本地參數綁定（例如，您不必猜測數據類型），這會有所幫助。而且，像交易這樣的一些高級功能不能簡單地用普通的mysql函數完成。
PDO可能是一個不錯的選擇，但其大部分驅動程序基本上被放棄，所以當你享受它的陷阱時，你實際上放鬆了擁有一個DB不可知的抽象層的好處。
恕我直言，你提出的這個事實表明你應該給mysqli一個機會。
謝謝，我花了一些時間研究mysqli並創建了一個類（它不會直接插入我的代碼中，我正在使用它進行實驗，但我可以調整它）。 SQL注入幾乎是我想要使用它的唯一原因。但我擔心潛在的表現點擊。我讀過一些關於使用準備好的語句與原來的做法等相比緩存不相同的東西 – Rob 2010-03-24 18:27:55