mysqldump 的 --where 参数仅对单表有效且需配合 --tables 显式指定表名，mysql 5.7+ 支持，字符串需手动加引号，不支持 join/子查询/now() 等复杂表达式；替代方案为 select ... into outfile。
mysqldump 不支持 --where 参数直接生效
直接加 --where="status='active'" 会报错或被忽略——mysqldump 的 --where 只对单表有效，且必须配合 --tables 显式指定表名，不能用于数据库级导出。很多人卡在这一步，以为参数写错了，其实是用法前提没满足。
常见错误现象：mysqldump: Unknown argument: --where（版本太低），或导出全表、条件完全没生效（忘了指定表）。
- 必须显式写出库名 + 表名，例如：
mysqldump mydb users --where="role='admin'" - MySQL 5.7+ 才支持
--where；5.6 及更早版本需改用--exec或临时表方案 - WHERE 条件里字符串要手动加引号，
mysqldump不帮你转义，--where="name='O''Connor'"这种带撇号的得自己处理
导出前先确认查询结果是否符合预期
别急着跑 mysqldump，先用 SELECT 验证 WHERE 条件逻辑是否真能捞出你要的数据。特别是涉及 JOIN、子查询、NULL 判断时，mysqldump --where 完全不支持这些，强行写进去只会静默失败或导出空数据。
使用场景：比如你想导出“近30天登录过的用户”，但 --where 只能写基础表达式，没法写 last_login_time > DATE_SUB(NOW(), INTERVAL 30 DAY) —— 这个语句在部分旧版 MySQL 里会被截断或报语法错。
- 安全做法：先执行
SELECT COUNT(*) FROM users WHERE last_login_time > DATE_SUB(NOW(), INTERVAL 30 DAY); - 如果 count 是 0，导出肯定为空；如果 count 很大，还要考虑导出文件体积和锁表现
- 注意时区：
NOW()是服务器时区，和你的业务时间可能不一致，建议用确定的时间字面量测试，比如'2024-04-01'
替代方案：用 SELECT INTO OUTFILE 更可控
当 --where 不够用（比如要导出多表关联结果、需要字段重命名、要 CSV 格式带引号转义），SELECT ... INTO OUTFILE 是更底层也更可靠的选择。它本质是服务端生成文件，路径必须是 MySQL 有写权限的本地路径（不是你本机）。
性能影响明显：该操作会持有表读锁（MyISAM）或 MVCC 快照（InnoDB），但不会阻塞写入；不过大结果集容易撑爆 tmpdir 空间。
- 示例：
SELECT id,name,email FROM users WHERE status='active' INTO OUTFILE '/var/lib/mysql-files/active_users.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n'; -
/var/lib/mysql-files/是默认 secure_file_priv 路径，运行SHOW VARIABLES LIKE 'secure_file_priv';查真实值 - 导出文件属主是 mysqld 进程用户（通常是
mysql），你得用sudo -u mysql cp或rsync拿出来
跨环境导出时字符集和 NULL 处理最容易翻车
导出文件打开乱码？字段值变成 \N？不是编码设错了，就是没声明字段处理规则。MySQL 默认把 NULL 输出为 \N，而多数 CSV 工具不认这个，会当成字面量字符串。
兼容性要点：不同 MySQL 版本对 FIELDS ENCLOSED BY 和 LINES TERMINATED BY 的解析略有差异，5.7 对 Windows 换行（\r\n）支持更稳，8.0 默认强制 utf8mb4。
- 导出前执行
SET NAMES utf8mb4;，再跑SELECT ... INTO OUTFILE - 避免
\N：用IFNULL(email, '')替换 NULL 字段，或用REPLACE后处理文件 - Windows 下用
LINES TERMINATED BY '\r\n'，否则 Excel 打开可能所有内容挤在第一行
secure_file_priv。
