Isso soa como uma lenda urbana para mim.

bin2hex() mapeia cada byte na entrada para dois bytes na saída ('a' -> '61' ), então você deve notar um aumento significativo de memória do script que executa a consulta - ele deve usar pelo menos tanta memória quanto o comprimento do byte dos dados binários a serem inseridos.

Além disso, isso implica que executar bin2hex() em uma longa string leva muito mais do que executar mysql_real_escape string() , que - conforme explicado na documentação do MySQL - apenas escapa 6 caracteres:NULL , \r , \n , \ , , e 'Control-Z'.

Isso foi para a parte do PHP, agora para o MySQL:O servidor precisa fazer a operação inversa para armazenar os dados corretamente. Reverter qualquer uma das funções leva quase tanto tempo quanto a operação original - a função reversa de mysql_real_escape_string() precisa substituir valores de escape (\\ ) com os sem escape (\ ), enquanto o inverso de bin2hex() precisaria substituir cada tupla de byte com um novo byte.

Desde que chamou mysql_real_escape_string() em dados binários é seguro (de acordo com MySQL e documentação do PHP ou mesmo considerando apenas que a operação não faz outras conversões além das listadas acima), não faria absolutamente nenhum sentido realizar uma operação tão custosa.