php - 将二进制数据从 PHP 插入 MySQL 时为什么要使用 bin2hex？

Question

我听说在将二进制数据(文件等)插入 MySQL 时，应该使用 bin2hex() 函数并将其作为 HEX 编码值发送，而不是仅仅使用 mysql_real_escape_string 在二进制字符串上并使用它。

// That you should do
$hex = bin2hex($raw_bin);
$sql = "INSERT INTO `table`(`file`) VALUES (X'{$hex}')";

// Rather than
$bin = mysql_real_escape_string($raw_bin);
$sql = "INSERT INTO `table`(`file`) VALUES ('{$bin}')";

据说是出于性能原因。与 MySQL 如何处理大字符串与它如何处理 HEX 编码值有关

但是，我很难确认这一点。我所有的测试都表明完全相反。 bin2hex 方法的速度慢了约 85%，并且使用了约 24% 的内存。
(我在 PHP 5.3、MySQL 5.1、Win7 x64 上测试这个 - 使用非常简单的插入循环。)

例如，此图显示了测试代码运行时 mysqld 进程的私有(private)内存使用情况:

_{(来源:advefir.com)}

有没有人有任何解释或资源可以澄清这一点？

谢谢。

Answer 1

对我来说，这听起来像是一个都市传说。

bin2hex() 将输入中的每个字节映射到输出中的 两个 个字节('a' -> '61 ')，因此您应该注意到执行查询的脚本显着增加了内存 - 它使用的内存至少应与要插入的二进制数据的字节长度一样多。

此外，这意味着在长字符串上运行 bin2hex() 比运行 mysql_real_escape string() 花费的时间多，后者 - 作为在 MySQL's documentation 中解释- 仅转义 6 个字符:NULL、\r、\n、\、、 和“Control-Z”。

那是 PHP 部分，现在是 MySQL:服务器需要执行反向操作才能正确存储数据。反转这两个函数所花的时间几乎与原始操作一样长 - mysql_real_escape_string() 的反转函数需要用未转义的值 (\\) 替换转义值 (\)，而 bin2hex() 的逆向需要用新字节替换每个字节元组。

由于对二进制数据调用 mysql_real_escape_string() 是安全的(根据 MySQL 和 PHP's documentation 或什至只是考虑到该操作除了上面列出的那些之外不进行任何其他转换)，它执行如此昂贵的操作绝对没有意义。