MySQL里单引号转义这事，引号说简单也简单，转义说坑也多。引号最直接的转义一条：字符串里的单引号，写成两个单引号就行。引号

比如你要存一个名字叫 O'Reilly，转义SQL 不能直接写 'O'Reilly'，引号数据库解析到 O 后面那个单引号就认为字符串结束了，转义剩下 Reilly' 直接语法错误。引号正确写法是转义 'O''Reilly'。两个连续单引号在 MySQL 里代表一个字面量单引号，引号这是转义 SQL 标准做法，MySQL 也认。引号

反斜杠也行。转义'O\'Reilly' 同样能跑。引号但这里有个分水岭：MySQL 的 NO_BACKSLASH_ESCAPES 模式。这个 SQL mode 一开，反斜杠就变成普通字符了，\' 不再转义，你写 'O\'Reilly' 反而会报错。很多云数据库默认开启这个模式，比如某些版本的阿里云 RDS。所以用两个单引号比用反斜杠稳，跨模式跨版本都不容易翻车。

我见过一个真实的翻车现场。某次数据迁移，开发同学在代码里拼 SQL，用 String.replace("'", "\\'") 处理用户输入。测试环境没问题，因为测试库没开 NO_BACKSLASH_ESCAPES。上线到生产库，那个库开了，结果所有带单引号的数据全部插入失败，报语法错误。排查了半天才定位到 SQL mode 差异。教训就是：别依赖反斜杠转义，老老实实用双写单引号。

再说一个容易忽略的点：LIKE 语句里的单引号。有人写 WHERE name LIKE '%O'Reilly%'，这照样挂。转义规则不区分场景，字符串里出现单引号就得处理。WHERE name LIKE '%O''Reilly%' 才对。

还有 mysql_real_escape_string() 这个 C API 函数，以及 PHP 的 mysqli_real_escape_string()。它们会同时转义单引号、双引号、反斜杠、NULL 字符等。但注意，这些函数依赖当前连接的字符集。如果连接字符集设成 GBK，而没调 set names，宽字节注入是真实存在的漏洞。单引号转义本身没问题，但字符集配错，转义就形同虚设。

最省心的做法其实是预处理语句。PREPARE stmt FROM 'SELECT * FROM users WHERE name = ?'，然后 SET @a = 'O''Reilly' 或者直接 EXECUTE stmt USING @a。参数和 SQL 结构分离，单引号根本不需要你手动转义。Java 的 PreparedStatement、Python 的 cursor.execute(sql, params) 都是这个思路。手动拼 SQL 字符串，转义做得再对，也总有边界情况漏掉。

总结一下实际写代码时的选择顺序：能用预处理语句就用预处理语句。不能用的场景，比如动态表名、动态列名，单引号用双写处理。反斜杠转义当备选，但要确认目标库的 SQL mode。最后，永远不要相信用户输入里的单引号会被自动处理好——它不会。