query方法比布尔索引快，因其底层用numexpr加速，避免创建中间布尔数组，尤其在千万行级DataFrame上优势明显；它将字符串表达式编译为C级运算，而df[df.A>10]需先生成全量bool数组再过滤，更耗内存和CPU。
query方法为什么比布尔索引快
因为 query 在底层用 numexpr 加速，能避免创建中间布尔数组，尤其在大 DataFrame（千万行级）上差异明显。它把字符串表达式编译成 C 级别运算，而 df[df.A > 10] 会先生成全量 bool 数组再过滤，内存和 CPU 都更吃紧。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 数据量超 100 万行时，优先用
query替代链式布尔索引 - 表达式里尽量用列名直接比较，别嵌套函数调用（如
query("x.str.len() > 5")会退化为慢路径） - 变量注入必须用
@前缀，写成query("age > @min_age")，漏掉@会报NameError: name 'min_age' is not defined
字符串中单引号、双引号和变量混用怎么不出错
常见错误是引号嵌套混乱，比如 query('name == "Alice"') 看似没问题，但一旦要插变量或含单引号的值（如 O'Connor），就容易崩。根本原因是 Python 字符串解析 + Pandas 表达式解析两层转义。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 统一用双引号包整个
query字符串，内部字段值用单引号，如df.query("city == 'Shanghai' and status != 'pending'") - 含单引号的值必须转义：写成
"name == 'O''Connor'"（注意是两个单引号，不是双引号） - 变量一律用
@var_name，且变量本身不能是表达式（@(x+1)不合法），只能是纯变量或字面量
query不支持哪些操作——别硬刚的边界
query 不是完整 SQL 引擎，它只支持表达式求值，不支持聚合、分组、窗口函数、子查询这些。试图写 query("count(*) > 10") 或 query("value in df2.id") 都会直接报错。
常见错误现象：
-
KeyError: 'count'—— 误把聚合函数当列名用 -
UndefinedVariableError—— 想引用另一个 DataFrame 的列，但没用@或没预定义 - 空结果却无报错 —— 实际是表达式语法合法但逻辑恒假（如用
=而非==）
替代方案：
- 需要 in 判断？先用
isin生成布尔数组，再传给query（如mask = df2.id.isin(df1.id); df1[mask]） - 需要按多列去重后过滤？别在
query里做，先drop_duplicates再query
性能陷阱：query在链式调用里被反复解析
每次调用 query 都要解析字符串、编译表达式。如果写成 df.query("a>1").query("b，等于重复解析三次，还多出两次中间 DataFrame 复制开销。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 合并条件：写成
df.query("a > 1 and b - 避免在循环里反复调用
query，尤其是参数动态变化时，考虑改用numexpr.evaluate手动缓存编译结果 - 对同一 DataFrame 做多次不同过滤？先用
query拿到索引（df.query("...", engine='python').index），再用.loc复用
最易被忽略的是：query 默认引擎是 'numexpr'，但在某些表达式（含自定义函数、部分字符串方法）下会自动 fallback 到 'python'，性能掉回原点。可以用 engine='numexpr' 强制，但要自己确保语法兼容。
