pdo執(zhí)行多行sql語句時的問題

最近我在做PHP程序時遇到了一個問題，舉個例子：

//開始查詢前兩個值
$pre=$pdo->prepare('
SELECT * FROM `abc` WHERE `id`=1;
SELECT * FROM `abc` WHERE `id`=2;
');
$pre->execute();
$id1=$pre->fetch(PDO::FETCH_ASSOC);
$pre->nextRowset();
$id2=$pre->fetch(PDO::FETCH_ASSOC);
//開始查詢后一個值
$pre=$pdo->prepare('
SELECT * FROM `abc` WHERE `id`=3;
');
$pre->execute();
$id3=$pre->fetch(PDO::FETCH_ASSOC);

這樣可以正常返回$id1和$id2的結果。
但如果在第一次查詢時不執(zhí)行$pre->nextRowset();
只查詢$id1的話，像這樣：

//開始查詢前兩個值
$pre=$pdo->prepare('
SELECT * FROM `abc` WHERE `id`=1;
SELECT * FROM `abc` WHERE `id`=2;
');
$pre->execute();
$id1=$pre->fetch(PDO::FETCH_ASSOC);
//這次我不查詢id2
//開始查詢后一個值
$pre=$pdo->prepare('
SELECT * FROM `abc` WHERE `id`=3;
');
$pre->execute();
$id3=$pre->fetch(PDO::FETCH_ASSOC);

會導致$id3的值為空。請問這是什么原理？
$pdo對象必須完整讀取到尾部，否則下次執(zhí)行就會失敗嗎？
謝謝各位！

回答

編輯回答

葬憶

對于參數綁定為何可以避免SQL注入，建議題主可以了解一下，值得注意的是prepare語句只能解析一條SQL，下面摘要說明一下prepare的作用：
首先從mysql服務器執(zhí)行sql的過程開始講起，SQL執(zhí)行過程包括以下階段詞法分析->語法分析->語義分析->執(zhí)行計劃優(yōu)化->執(zhí)行。詞法分析->語法分析這兩個階段我們稱之為硬解析。詞法分析識別sql中每個詞，語法分析解析SQL語句是否符合sql語法，并得到一棵語法樹（Lex）。對于只是參數不同，其他均相同的sql，它們執(zhí)行時間不同但硬解析的時間是相同的。而同一SQL隨著查詢數據的變化，多次查詢執(zhí)行時間可能不同，但硬解析的時間是不變的。對于sql執(zhí)行時間較短，sql硬解析的時間占總執(zhí)行時間的比率越高。而對于淘寶應用的絕大多數事務型SQL，查詢都會走索引，執(zhí)行時間都比較短。因此淘寶應用db sql硬解析占的比重較大。

Prepare的出現就是為了優(yōu)化硬解析的問題。Prepare在服務器端的執(zhí)行過程如下

1） Prepare 接收客戶端帶”?”的sql, 硬解析得到語法樹(stmt->Lex), 緩存在線程所在的preparestatement cache中。此cache是一個HASH MAP. Key為stmt->id. 然后返回客戶端stmt->id等信息。

2） Execute 接收客戶端stmt->id和參數等信息。注意這里客戶端不需要再發(fā)sql過來。服務器根據stmt->id在preparestatement cache中查找得到硬解析后的stmt, 并設置參數，就可以繼續(xù)后面的優(yōu)化和執(zhí)行了。

Prepare在execute階段可以節(jié)省硬解析的時間。如果sql只執(zhí)行一次，且以prepare的方式執(zhí)行，那么sql執(zhí)行需兩次與服務器交互（Prepare和execute）, 而以普通（非prepare）方式，只需要一次交互。這樣使用prepare帶來額外的網絡開銷，可能得不償失。我們再來看同一sql執(zhí)行多次的情況，比如以prepare方式執(zhí)行10次，那么只需要一次硬解析。這時候  額外的網絡開銷就顯得微乎其微了。因此prepare適用于頻繁執(zhí)行的SQL。

Prepare的另一個作用是防止sql注入，不過這個是在客戶端jdbc通過轉義實現的，跟服務器沒有關系。

建議題主看下MySQL官方文檔（https://dev.mysql.com/doc/ref...）。什么？看不懂英文？試試百度翻譯吧：https://fanyi.baidu.com