datatable读CSV虽快但默认不推断类型，需显式指定columns或detect_types=True；聚合结果为Frame需.to_numpy()[0,0]解包；join前须检查并统一key类型；大对象需del+gc.collect()释放内存。
datatable 读 CSV 比 pandas 快，但默认不推断类型
直接用 dt.fread() 读大文件时，列类型常是 obj64 而非预期的 int32 或 str32，后续计算会慢、内存翻倍。这不是 bug，是 datatable 为保速度默认跳过类型推测。
- 加参数
columns显式指定类型，比如columns={"age": dt.int32, "name": dt.str32} - 用
detect_types=True让它扫前 10k 行猜一次（仅限小样本可靠，大数据慎用） - 读完立刻用
[:, dt.f[:].to_type(...)]批量转类型，比逐列[:, dt.f.age.to_type(dt.int32)]快得多
用 [:, dt.sum(dt.f.x)] 聚合时结果是单行 datatable，不是标量
很多人想取个 sum 值直接参与 if 判断或 print，结果卡住——因为 dt.sum() 返回的是 1×1 的 datatable.Frame，不是 Python 数字。
- 必须链式调用
.to_list()[0][0]或更稳妥地用.to_numpy()[0, 0]拿出原始值 - 若只查一个值且确定非空，
frame[0, "col"][0, 0]更快，但注意索引越界会报IndexError - 别用
frame["col"].sum()，这是 pandas 风格写法，在 datatable 中不支持，会报AttributeError: 'Frame' object has no attribute 'sum'
join 失败常见于 key 列含 null 或类型不一致
两个 Frame 做 dt.join() 后行数变 0 或暴涨，大概率是 join key 有 None 或一边是 int32、另一边是 int64。
- 先检查 key 列：用
frame[:, dt.count(dt.isna(dt.f.key))]看空值数量 - 强制统一类型再 join：
left[:, {"key": dt.f.key.to_type(dt.int64)}].join(right) - left join 时，右表没匹配的行会填
None，但左表 key 是str32、右表是str64也会静默失败，务必用dt.types对比两边类型
内存没释放？别忘了 del frame + gc.collect()
datatable 不像 pandas 那样依赖引用计数自动回收大 Frame，尤其在 Jupyter 里反复读写同一变量名，旧对象可能滞留内存。
立即学习“Python免费学习笔记（深入）”；
-
del frame是必须动作，不能只靠重赋值 - 紧跟着跑
import gc; gc.collect()，否则内存占用不会立刻下降 - 用
frame.nrows和frame.ncols替代len(frame)和len(frame.names)，前者是 O(1)，后者在某些版本触发全量扫描
类型对齐、显式释放、结果解包——这三个点漏掉任何一个，都可能让 datatable 的性能优势打折扣，甚至比 pandas 还慢。
