phpmyadmin导出时“转义反斜杠”对_无效，因_是否被转义取决于sql_mode（如no_backslash_escapes）和查询层预处理（如replace或escape），而非导出设置。
导出时勾选“转义反斜杠”没用？先确认 mysql 版本和 sql 兼容模式
phpmyadmin 导出 sql 时是否转义 _（下划线）本身不是独立选项，它依赖于底层 mysql 的 sql 模式和导出器对通配符的处理逻辑。真正影响 _ 是否被转义的，是导出时是否启用「使用反斜杠转义」以及当前会话的 sql_mode —— 尤其是 no_backslash_escapes 是否开启。
常见错误现象：SELECT * FROM user WHERE name LIKE 'a_b' 在导入后变成匹配任意单字符（即 a_b 被当成通配模式），因为 _ 没被保留为字面量。
- MySQL 5.7+ 默认关闭
NO_BACKSLASH_ESCAPES，此时_可被正常转义；但若服务器启用了该模式，就失去转义能力，phpMyAdmin 导出也不会加反斜杠 - phpMyAdmin 的「导出 → 格式选项 → 使用反斜杠转义」只控制字符串值中的
"等，**不主动对 LIKE 模式里的_做额外处理** - 真正起作用的是：导出前手动在查询中用
ESCAPE显式声明转义符，或确保数据本身已按需双写反斜杠（如存入时就是a\_b）
想让 LIKE 中的 _ 安全导出？必须在查询层处理，不是导出设置能解决的
phpMyAdmin 导出的是结果集或建表语句，它不会扫描字段内容去识别哪些 _ 是通配意图、哪些是字面下划线。如果你的表里存了类似 file_name 这种含下划线的字符串，又希望导出后 INSERT 语句能原样还原，关键不在导出设置，而在 SELECT 查询怎么写。
- 导出前执行：
SELECT id, REPLACE(name, '_', '\_') AS name FROM user，这样导出的值里_已变成_ - 或者更稳妥：用
ESCAPE配合固定转义符，例如SELECT * FROM user WHERE name LIKE 'a!_b' ESCAPE '!'，然后导出时确保该!不出现在数据中 - 避免陷阱：不要依赖 phpMyAdmin 的「格式化 SQL」或「美化」选项，它可能把
\_合并成_，导致导入时失效
导入时出错说 Unknown character set: '' 或 Unexpected character？检查导出文件编码和转义开关一致性
导出时若勾选了「使用反斜杠转义」，但导入的目标 MySQL 开启了 NO_BACKSLASH_ESCAPES，就会把 _ 当作非法转义序列报错；反之，若导出没转义、导入端却期望转义，LIKE 行为就错乱。
- 导出页务必核对：
导出 → 格式选项 → 使用反斜杠转义和SQL 兼容模式（建议选MYSQL40或留空，避免MAXDB等特殊模式干扰） - 导出文件开头若有
SET NAMES utf8mb4;，确认目标库也支持该字符集，否则可能被截断或误读 - 用文本编辑器打开导出的 .sql 文件，搜索
_—— 如果一个都没出现，说明数据源里压根没这个字符，或查询/导出流程跳过了转义环节
真正防 SQL 注入？别靠导出转义，那是运行时的事
导出功能本身不参与 SQL 执行，它只是生成静态文本。所谓「防止 SQL 注入」是误解——注入发生在应用拼接 SQL 字符串时，比如 PHP 里直接 "SELECT * FROM user WHERE name = '$name'"。导出时加不加反斜杠，对运行时安全零影响。
- 需要防注入的地方：PHP 用
mysqli_real_escape_string()或 PDO 的预处理，而不是指望 phpMyAdmin 导出帮你「加固」 - 导出时唯一相关的安全点：避免导出敏感字段（如密码哈希），这靠「选择列」而非转义设置
- 如果导出的 SQL 之后要被人手改写再执行，那就必须统一团队对
ESCAPE的用法，而不是纠结 phpMyAdmin 有没有自动转_
导出时 _ 能不能保留，取决于你查什么、怎么查、导出前有没有预处理，以及目标 MySQL 的 SQL_MODE。没有一键开关，只有分层控制。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
