Това ми звучи като градска легенда.
bin2hex() преобразува всеки байт във входа в два байтове в изхода ('a' -> '61' ), така че трябва да забележите значително увеличение на паметта на скрипта, изпълняващ заявката – той трябва да използва поне толкова памет повече, колкото дължината на байта на двоичните данни, които трябва да бъдат вмъкнати.
Освен това, това означава, че се изпълнява bin2hex() на дълъг низ отнема много по-дълго от изпълнението на mysql_real_escape string() , което - както е обяснено в документацията на MySQL - просто екранира 6 знака:NULL , \r , \n , \ , , и 'Control-Z'.
Това беше за PHP частта, сега за MySQL:Сървърът трябва да извърши обратната операция, за да съхрани правилно данните. Обръщането на която и да е от функциите отнема почти толкова време, колкото оригиналната операция - обратната функция на mysql_real_escape_string() трябва да замени екранираните стойности (\\ ) с неекранирани (\ ), докато обратното на bin2hex() ще трябва да замени всеки и всеки байтов кортеж с нов байт.
След извикването на mysql_real_escape_string() на двоични данни е безопасно (според MySQL и документацията на PHP или дори като се има предвид, че операцията не извършва други преобразувания освен изброените по-горе), би имало абсолютно никакъв смисъл да се извършва такава скъпа операция.
