Update einer Chatfunktion

[1unitedpower]

Ich fasse Kontextwechsel allgemeiner auf, nämlich: … wenn Daten in anderen Code eingefügt werden müssen. Wenn Programmdaten in einer MySQL-Datenbank gespeichert werden sollen, müssen die Daten irgendwann ja in gültige MySQL-Querys verpackt werden.

Genau das passiert bei (echten) Prepared Statements nicht. Das würde dem Sinn von "prepared" entgegenlaufen, wenn das Statement nicht vorbereitet bleiben könnte, sondern immer wieder nebst den darin einzufügenden Daten neu geparst werden müsste. Nicht-String-Daten wie Zahlen müssten dabei immer erst als Literal ausformuliert werden, nur um dann wieder zurückgeparst zu werden.

Wenn du mit "echten" Prepared Statements solche meinst, die über das Binärprotokoll abgewickelt werden, ist es das selbe nur in grün. Auch beim Binärprotokoll muss dafür gesorgt, dass Nutzdaten nicht irrtümlich als Steuerdaten fehlinterpretiert werden. Für die Performance wird man aber wohl nicht auf Maskierung, sondern auf Längenangaben gesetzt haben. Für native Prepared Statements der menschenlesbaren SQL gilt was ich in meiner letzten Antwort geschrieben habe.