Esto suena como una leyenda urbana para mí.
bin2hex() asigna cada byte en la entrada a dos bytes en la salida ('a' -> '61' ), por lo que debería notar un aumento significativo de la memoria del script que realiza la consulta; debería usar al menos tanta memoria como la longitud de bytes de los datos binarios que se insertarán.
Además, esto implica que ejecutar bin2hex() en una cadena larga toma mucho más tiempo que ejecutar mysql_real_escape string() , que - como se explica en documentación de MySQL - solo escapa 6 caracteres:NULL , \r , \n , \ , , y 'Control-Z'.
Eso fue para la parte de PHP, ahora para MySQL:el servidor necesita hacer la operación inversa para almacenar los datos correctamente. Invertir cualquiera de las funciones lleva casi tanto tiempo como la operación original:la función inversa de mysql_real_escape_string() necesita reemplazar los valores escapados (\\ ) con unos sin escape (\ ), mientras que el reverso de bin2hex() necesitaría reemplazar todas y cada una de las tuplas de bytes con un nuevo byte.
Desde llamar a mysql_real_escape_string() en datos binarios es seguro (según la documentación de MySQL y PHP o incluso considerando que la operación no realiza otras conversiones además de las enumeradas anteriormente), no tendría absolutamente ningún sentido realizar una operación tan costosa.
