Cela ressemble à une légende urbaine pour moi.
bin2hex() mappe chaque octet de l'entrée sur deux octets dans la sortie ('a' -> '61' ), vous devriez donc remarquer une augmentation significative de la mémoire du script exécutant la requête - il doit utiliser au moins autant de mémoire que la longueur en octets des données binaires à insérer.
De plus, cela implique que l'exécution de bin2hex() sur une longue chaîne prend beaucoup plus long que d'exécuter mysql_real_escape string() , qui - comme expliqué dans la la documentation de MySQL - échappe juste 6 caractères :NULL , \r , \n , \ , , et 'Contrôle-Z'.
C'était pour la partie PHP, maintenant pour MySQL :Le serveur doit faire l'opération inverse pour stocker correctement les données. Inverser l'une ou l'autre des fonctions prend presque aussi longtemps que l'opération d'origine - la fonction inverse de mysql_real_escape_string() doit remplacer les valeurs échappées (\\ ) avec ceux non échappés (\ ), alors que l'inverse de bin2hex() aurait besoin de remplacer chaque tuple d'octet avec un nouvel octet.
Depuis l'appel de mysql_real_escape_string() sur les données binaires est sûr (selon MySQL et documentation PHP ou même en considérant simplement que l'opération ne fait pas d'autres conversions que celles énumérées ci-dessus), cela n'aurait absolument aucun sens d'effectuer une opération aussi coûteuse.
