Dla mnie brzmi to jak miejska legenda.
bin2hex() mapuje każdy bajt w danych wejściowych na dwa bajty na wyjściu ('a' -> '61' ), więc powinieneś zauważyć znaczny wzrost pamięci skryptu wykonującego zapytanie - powinien on używać co najmniej tyle pamięci, ile wynosi długość wstawionych danych binarnych.
Co więcej, oznacza to, że uruchomienie bin2hex() na długim łańcuchu zajmuje dużo dłużej niż uruchomienie mysql_real_escape string() , co - jak wyjaśniono w dokumentacji MySQL - po prostu ucieka 6 znaków:NULL , \r , \n , \ , , i 'Control-Z'.
To było dla części PHP, teraz dla MySQL:serwer musi wykonać odwrotną operację, aby poprawnie przechowywać dane. Odwrócenie jednej z funkcji zajmuje prawie tyle samo czasu, co pierwotna operacja — odwrócenie funkcji mysql_real_escape_string() musi zastąpić wartości ze znakami ucieczki (\\ ) z nieuniknionymi (\ ), podczas gdy odwrotność bin2hex() musiałby zastąpić każdą krotkę bajtową z nowym bajtem.
Od wywołania mysql_real_escape_string() na danych binarnych jest bezpieczny (zgodnie z MySQL i dokumentacją PHP lub nawet biorąc pod uwagę, że operacja nie wykonuje żadnych innych konwersji niż te wymienione powyżej), nie ma sensu wykonywać tak kosztownej operacji.
