MySQL中WHERE子句不能用于LOAD DATA INFILE语句进行行级过滤，必须通过“临时表+INSERT...SELECT...WHERE”两步实现条件加载。
WHERE 子句不能直接用在 INSERT 或 LOAD DATA INFILE 语句里做行级过滤，这是 MySQL 的硬性限制 —— 想“只导入满足条件的数据”，必须换思路。
WHERE 子句只能用于 SELECT / UPDATE / DELETE，不支持 LOAD DATA
很多人尝试写类似这样的语句：
LOAD DATA INFILE '/tmp/data.csv' INTO TABLE orders WHERE status = 'pending';
这会直接报错 ERROR 1064 (42000)：MySQL 语法不支持在 LOAD DATA 后加 WHERE。原因很实在：LOAD 是“批量灌数据”的底层操作，WHERE 是“查数据时做判断”的逻辑层，二者执行阶段和引擎路径完全不同。
-
SELECT、UPDATE、DELETE走的是查询优化器路径，WHERE 在执行计划中可下推、可索引加速 -
LOAD DATA走的是存储引擎直写路径，跳过 SQL 解析的大部分环节，性能优先，不支持条件过滤 - 想实现“有条件地加载”，得靠两步走：先全量导入临时表，再用
INSERT ... SELECT ... WHERE筛选落库
替代方案：用临时表 + INSERT ... SELECT ... WHERE 实现条件加载
这是生产环境最常用、最可控的做法。核心是把“过滤”从加载阶段移到插入阶段。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 先建一个结构一致的临时表：
CREATE TEMPORARY TABLE orders_staging LIKE orders; - 用
LOAD DATA全量导入到临时表：LOAD DATA INFILE '/tmp/data.csv' INTO TABLE orders_staging; - 再用带
WHERE的INSERT ... SELECT精准迁移：INSERT INTO orders SELECT * FROM orders_staging WHERE status = 'pending' AND created_at >= '2025-01-01';
- 最后清空或丢弃临时表（临时表会话结束自动销毁）
优势明显：WHERE 条件可任意组合（AND/OR/IN/BETWEEN 都行），还能配合索引加速；缺点是多一次 I/O 和内存拷贝，但对百万级以下数据几乎无感。
字符串、NULL、大小写这些细节，一不留神就查不到数据
WHERE 表达式看着简单，实际踩坑最多的是类型和语义陷阱：
- 字符串值必须用单引号：
WHERE name = 'Alice'，写成WHERE name = Alice会被当列名或变量报错 -
NULL不能用=判断：WHERE price = NULL永远返回空结果，必须写WHERE price IS NULL - 默认字符串比较不区分大小写（
'abc' = 'ABC'为 true），要严格匹配加BINARY：WHERE BINARY username = 'Admin' -
LIKE中的%和_是通配符，真想查字面量下划线？得转义：WHERE comment LIKE '%\_error%' ESCAPE '\' - 多个条件混用
AND和OR时，优先级容易出错 ——WHERE a=1 OR b=2 AND c=3实际等价于a=1 OR (b=2 AND c=3)，不确定就加括号
性能关键：WHERE 能不能走索引，取决于你写的姿势
WHERE 写得再准，如果让索引失效，查十万行也像查百万行一样慢。
- ✅ 推荐：
WHERE user_id = 123（等值查主键/索引列）、WHERE create_time BETWEEN '2025-01-01' AND '2025-12-31'（范围查有索引的时间字段） - ❌ 避免：
WHERE YEAR(create_time) = 2025（函数作用于索引列 → 全表扫描）、WHERE remark LIKE '%bug%'（前导 % → 无法用 B+Tree 索引） - 查之前先
EXPLAIN一下：EXPLAIN SELECT * FROM logs WHERE level = 'ERROR' AND created_at > '2025-12-01';
看type是不是ref或range，key是否显示用了哪个索引
真正难的从来不是写对 WHERE，而是写出让优化器愿意用索引的 WHERE —— 它不看你逻辑多漂亮，只认字段是否裸露、顺序是否匹配、函数有没有套壳。
