mysqldump支持--where导出单表部分数据，但需注意：仅限MySQL 5.7+、必须指定库名和表名、条件用引号包裹且不支持JOIN/子查询/NOW()等，导出前应先用SELECT验证条件有效性。
mysqldump 用 --where 导出满足条件的行，但要注意 SQL 注入和引号转义
直接在命令行里拼接 --where 条件时，MySQL 不会自动处理单引号、空格或特殊字符，容易报错或导出意外数据。比如想导出 status = 'active'，写成 --where="status = 'active'" 在 shell 中可能被提前截断。
实操建议：
- 把整个
--where值用单引号包裹，内部双引号或转义单引号，例如：--where='status = "active"'或--where='created_at >= "2024-01-01"' - 避免在条件中拼接变量；如果必须动态生成（如脚本中），优先用
printf %q转义，而不是简单字符串拼接 -
--where只支持 WHERE 子句语法，不支持 JOIN、子查询、函数嵌套（如DATE(created_at)可能失败，改用created_at >= "2024-01-01 00:00:00"）
导出前务必加 --no-create-info 和 --skip-triggers
生产环境导出部分数据时，默认 mysqldump 会带上建表语句（CREATE TABLE）和触发器定义，这在只导入数据到另一张已有结构的表时不仅多余，还可能因表名冲突或权限问题失败。
常见错误现象：导入时报 ERROR 1050 (42S01): Table 'xxx' already exists 或触发器重复创建失败。
实操建议：
- 显式加上
--no-create-info，禁用建表语句 - 加上
--skip-triggers，跳过触发器导出（除非你明确需要迁移触发逻辑） - 如果目标库表结构可能有差异，再加
--skip-extended-insert，让每行 INSERT 独立，方便排查某条数据失败原因
大表导出要防锁表和超时，优先用 --single-transaction + --skip-lock-tables
默认 mysqldump 会对导出表执行 LOCK TABLES ... READ，在高并发写入的生产库上极易阻塞业务 SQL，尤其配合 --where 时可能锁全表而非匹配行。
使用 --single-transaction 是更安全的选择——它依赖 InnoDB 的 MVCC，在事务快照中读取数据，不加锁。但注意：它仅对 InnoDB 表生效，且要求事务隔离级别为 REPEATABLE READ（默认即如此）。
实操建议：
- 确认目标表是 InnoDB 引擎（
SHOW CREATE TABLE t1查看ENGINE=InnoDB） - 强制加
--single-transaction --skip-lock-tables，二者配合才真正规避锁表 - 若表含大量 BLOB/TEXT 字段或条件匹配行数极多，加
--net_buffer_length=1M防止网络缓冲溢出中断
导出文件编码和字段分隔符不匹配会导致中文乱码或 LOAD DATA 失败
即使数据库字符集是 utf8mb4，mysqldump 默认输出也可能用系统 locale 编码（如 en_US.UTF-8 正常，但某些容器环境是 C locale，导致中文变 ?）。另外，用 LOAD DATA INFILE 导入时，字段/行结束符与 dump 文件不一致会解析错位。
实操建议：
- 显式指定导出字符集：
--default-character-set=utf8mb4，并确保客户端连接也用该集（mysql --default-character-set=utf8mb4导入时也要对应） - 若后续要用
LOAD DATA，加--tab=/path/to/dir生成纯文本（非 SQL），再配--fields-terminated-by=',' --lines-terminated-by='\n'显式声明格式 - 导出后用
file -i dump.sql检查编码，用head -n5 dump.sql | cat -A看不可见字符是否异常
最易被忽略的是 --where 条件里的时间字段比较——MySQL 的 DATETIME 字面量必须带引号且格式严格（"2024-01-01 12:00:00"），少个空格或用错时区就查不到数据；另外，mysqldump 不校验 --where 语法是否合法，错写成 status == 'active' 也不会报错，而是静默导出空结果。
