MySQL PDO förberedd snabbare än fråga? Det är vad detta enkla test visar

Det finns en liten sak att nämna. Som standard, PDO bara emulera förberedda satser.
Och i emuleringsläge kör den samma gamla fråga utan att faktiskt förbereda en enda sats :)

Så först och främst,

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, FALSE);

att slå på verkliga förberedda uttalanden.

Det finns en annan liten sak att nämna.
Tråkigt nog finns det väldigt få riktiga kunskap i världen. Och särskilt i världen av Q&A-sajter. Människor tenderar att upprepa den information de läst och funnit rimlig. Utan att köra några tester för att bevisa eller ens utan att lägga händerna på. Så "ofta noterat" bör inte betraktas som en pålitlig källa alls.

Tillbaka till saken:även om det borde finnas ett straff, borde det vara obetydligt för det mesta. Om det är det - måste du ställa in ditt system.

Hur som helst, i emuleringsläget fick du det både "snabbt" och säkert.

Uppdatera
Nå, efter att ha kört dina tester på mina data, måste jag säga att det är något fel med din databas om du har tre gångers skillnad på en stor datamängd.

För en blixtfråga

select title from Board where id = 1

resultaten är

emulation   on      off
query      0.07    0.130
prepare    0.075   0.145

medan för den ganska betungande frågan

select title from Board where id > 1

resultaten är

emulation   on      off
query      0.96    0.96
prepare    0.96    1.00

Så, som vi kan se, på ett stort dataset blir skillnaden omärkbar.

För blixtfrågan finns det en viss skillnad, men eftersom det bara tar 0 0003:e fraktionen av sekunden (för en enda fråga) - jag skulle säga att det är ett perfekt exempel på ordet "likgiltighet".

För lika resultat mellan query()/prepare() - jag har bara en idé - PDO använder prepare/execute för alla frågor, även de utan bindningar.

Nu till kodningsproblemet.

Ja, konstiga GBK-problem påverkar PDO för versioner före 5.3.3. Dessa versioner hade inget sätt att ställa in rätt kodning och var oundvikligt sårbara (i emuleringsläge). Men eftersom 5.3.3 PDO stöder inställning av kodning i DSN, och nu är allt bra med det.
För mysqli måste man använda mysqli_set_charset() för just detta syfte med samma (ogenomträngliga) resultat.

I min egen klass som är baserad på mysqli använder jag min egen platshållarimplementering och använder inga förberedda påståenden alls. Inte av prestandaskäl utan för bättre tillförlitlighet.