数据从业者新手踩坑指南

本文来源于数据从业者全栈知识库，更多体系化内容请访问知识库。

这不是一份教你”怎么做对”的文档。这是一份教你”别怎么做错”的血泪史。区别在于——前者你看完可能觉得”哦，知道了”，后者你看完会觉得”妈，说的就是我”。

每个数据人都踩过坑。区别只在于：有人在坑里待了三天，有人待了三年。

这份指南收录了数据从业者在技术、分析、建模、职场各个环节最容易犯的错误。不保证你看完一个坑都不踩——但至少，你踩坑之前能想起来”好像有人提醒过我”。

踩坑的本质是什么？ 是你的认知模型和现实之间有一条裂缝。坑越深，说明裂缝越宽。所以每个坑都是认知升级的台阶——前提是你得从坑里爬出来，而不是在里面安家。

一、技术踩坑：SQL

坑1：NULL 不等于 NULL，NULL 也不不等于 NULL

-- 错误：以为能找出 phone 为空的用户
SELECT * FROM users WHERE phone = NULL;  -- 返回 0 行

-- 正确：
SELECT * FROM users WHERE phone IS NULL;
SELECT * FROM users WHERE phone IS NOT NULL;

SQL 使用三值逻辑（True / False / Unknown）。任何值与 NULL 做比较，结果都是 Unknown，而 WHERE 子句只保留 True 的行。NULL = NULL 是 Unknown，不是 True。

延伸陷阱：NOT IN 遇到 NULL 会让你抓狂——如果子查询里有一个 NULL，整个 NOT IN 可能返回空集。改用 NOT EXISTS 更安全。

坑2：COUNT(*) 和 COUNT(col) 不是一回事

COUNT(*) 统计所有行（含 NULL）；COUNT(col) 只统计该列非 NULL 的行。想统计总订单数，结果用了 COUNT(payment_method)，发现比实际少了——因为货到付款没填支付方式，payment_method 是 NULL。

坑3：JOIN 让数据凭空”变多”了

JOIN 的本质是笛卡尔积后按条件过滤。如果右表的 JOIN key 不唯一，左表的每一行都会和右表匹配的每一行组合，数据”变多”不是 bug。

JOIN 前先问自己：两张表的关联关系是什么？ 1:1、1:N、N:N？如果是 N:N，先做聚合再 JOIN。

坑4：忘加分区条件，扫了全表，账单来了

-- 危险！3年数据全扫
SELECT user_id, SUM(amount) FROM dwd_orders
WHERE order_status = 'paid'
GROUP BY user_id;

-- 正确：分区条件永远放第一位
SELECT user_id, SUM(amount) FROM dwd_orders
WHERE dt = '2025-01-04'
  AND order_status = 'paid'
GROUP BY user_id;

大数据表通常按日期分区存储。没有分区条件就是全表扫描——在几十 TB 的表上这意味着几小时的等待和可观的计算费用。养成习惯：写 SQL 的第一步，先写 WHERE dt = ?。

坑5：GROUP BY 的”隐式规则”让结果悄悄出错

MySQL 宽松模式下，SELECT 里放一个没在 GROUP BY 里的非聚合列不会报错，但那个值是随机取的。严格模式的数据库会报错，宽松模式的数据库会给你一个随机值——后者更危险，因为你不知道结果是错的。

规则很简单：GROUP BY 之后，SELECT 里的列要么在 GROUP BY 里，要么是聚合函数（SUM/COUNT/MAX/MIN/AVG）。

二、技术踩坑：Python

坑6：用 Pandas 读了一个 10GB 的文件，内存爆了

Pandas 在内存中展开数据，通常占用原始数据 5-10 倍的内存。10GB 的 CSV 在内存里可能膨胀到 60-80GB。

更多文章