首先：不要使用mysql_escape_string了，它已被弃用，请使用mysql_real_escape_string或者addslashes代替它。

那么mysql_real_escape_string和addslashes的区别呢？
第一：

与addslashes对比，mysql_real_escape_string同时还对\r、\n和\x1a进行转义。看来，这些字符必须正确地告诉MySQL，否则会得到错误的查询结果。

这是不使用addslashes进行转义的原因之一。

第二：

addslashes不知道任何有关MySQL连接的字符集。如果你给所使用的MySQL连接传递一个包含字节编码之外的其他编码的字符串，它会很愉快地把所有值为字符‘、“、\和\x00的字节进行转义。如果你正在使用不同于8位和UTF-8的其它字符，这些字节的值不一定全部都是表示字符‘、“、\和\x00。可能造成的结果是，MySQL接收这些字符后出现错误。

如果要修正这个bug，可尝试使用iconv函数，将变量转为UTF-16，然后再使用addslashes进行转义。

这是不使用addslashes进行转义的另一个原因。

下面是具体的示例：

addslashes V.S. mysql_real_escape_string

在GBK里，0xbf27不是一个合法的多字符字符，但0xbf5c却是。在单字节环境里，0xbf27被视为0xbf后面跟着0×27(‘)，同时0xbf5c被视为0xbf后面跟着0x5c(\)。

一个用反斜杠转义的单引号，是无法有效阻止针对MySQL的SQL注入攻击的。如果你使用addslashes，那么，我（攻击者，下同）是很幸运的。我只要注入一些类似0xbf27，然后addslashes将它修改为0xbf5c27，一个合法的多字节字符后面接着一个单引号。换句话说，我可以无视你的转义，成功地注入一个单引号。这是因为0xbf5c被当作单字节字符，而非双字节。

想要避免这种漏洞，使用mysql_real_escape_string、准备语句（Prepared Statements，即“参数化查询”）或者任意一款主流的数据库抽象类库。