Dit klinkt als een stadslegende voor mij.
bin2hex() wijst elke byte in de invoer toe aan twee bytes in de uitvoer ('a' -> '61' ), dus u zou een aanzienlijke geheugentoename moeten opmerken van het script dat de query uitvoert - het zou minstens zoveel geheugen meer moeten gebruiken als de bytelengte van de binaire gegevens die moeten worden ingevoegd.
Bovendien houdt dit in dat het uitvoeren van bin2hex() aan een lange reeks kost veel langer dan het uitvoeren van mysql_real_escape string() , die - zoals uitgelegd in MySQL-documentatie - ontsnapt slechts 6 tekens:NULL , \r , \n , \ , , en 'Control-Z'.
Dat was voor het PHP-gedeelte, nu voor MySQL:de server moet de omgekeerde bewerking uitvoeren om de gegevens correct op te slaan. Het omkeren van een van de functies duurt bijna net zo lang als de oorspronkelijke bewerking - de omgekeerde functie van mysql_real_escape_string() moet escape-waarden vervangen (\\ ) met unescaped degenen (\ ), terwijl het omgekeerde van bin2hex() zou elke byte-tuple moeten vervangen met een nieuwe byte.
Sinds het aanroepen van mysql_real_escape_string() op binaire gegevens veilig is (volgens MySQL's en PHP-documentatie of zelfs als je bedenkt dat de bewerking geen andere conversies uitvoert dan de hierboven genoemde), zou het absoluut geen zin hebben om zo'n kostbare bewerking uit te voeren.