企业官网建设流程全解析

1. 先搞清楚：ODPS 里为什么没有“排除字段”这种写法

做数仓的人都遇到过这个瞬间：手里一张八百列的宽表，只想看除phone之外的所有列，脑子里第一个念头就是SELECT * EXCEPT (phone) FROM tbl。敲下去，回车，报错。换EXCLUDE，还是报错。换SELECT * - phone，照样报错。这不是你记错了语法，而是ODPS（MaxCompute）的 SELECT 列表里压根就没有“排除列”这个能力。它支持的是标准 SQL 的子集，*就是全展开，要么你老实写字段名，要么用元数据自己拼一串出来。

这件事在大数据开发里出现频率高得离谱。原因很实在：宽表动辄几百列，人肉抄字段名不现实；上游还在天天加字段，你今天抄完，明天就漏；而你要排除的往往就那么一两个，要么是手机号、身份证这类不能外流的敏感列，要么是raw_json、base64_img这种一列顶十列的大字段。“反选字段”本质上是一个元数据驱动的 SQL 生成问题，硬用 SQL 语法去解决，方向就错了。

这篇东西面向三类人：刚接手别人宽表、被字段列表劝退的同学；要做数据共享、得把敏感列摘掉的同学；还有想搞清楚到底该在 SQL 层、脚本层还是治理层解决这个问题的同学。我下面会把方案摊开讲，包括各自的代价、实操脚本、以及我在真实项目里踩过的那些坑。核心结论先放这儿：ODPS 没有列级 EXCEPT 语法，但用information_schema加字符串聚合，或者用 pyodps 跑一遍 schema，三分钟能生成任何你想要的字段清单。

1.1 EXCEPT 在 ODPS 里是集合运算符，不是列裁剪

先把最容易混淆的点说透。在 ODPS 的语法体系里，EXCEPT是一个集合差集运算符，它作用于两个查询结果集之间，要求两边的列数完全一致、类型按位置兼容，然后返回左边有、右边没有的行。写法长这样：

SELECT id, name FROM t1 EXCEPT SELECT id, name FROM t2;

它的语义是“行级别做减法”，跟你想要的“列级别做减法”完全是两码事。所以当你写SELECT * EXCEPT (phone) FROM tbl时，解析器看到EXCEPT关键字，会立刻期待后面跟一个SELECT，结果发现是个括号加字段名，直接语义分析失败。报错信息通常是ODPS-0130071: Semantic analysis exception或者纯语法错误，具体文案跟版本有关，但方向都是“你这儿不该出现这个”。

注意：不同引擎对这件事的支持差异极大。有些方言确实支持SELECT * EXCEPT (col)，生态里还有叫EXCLUDE的写法。不要把别的引擎的习惯带到 ODPS 上，我在评审别人代码时见过好几次这种复制粘贴事故，跑一次就露馅。最稳的自测方法就是随便找张两列的小表跑一条，看引擎认不认，比你翻半小时文档快。

还有个衍生问题：有人会想“那我先SELECT *出来，外面套一层把不要的列丢掉”。这也不行。SQL 的列集合在解析阶段就定死了，SELECT * FROM (SELECT * FROM t) x不会给你任何动态裁剪的空间。*就是全展开，没得商量。

1.2 列裁剪的真实成本，比你想的要贵

既然要排除字段，那说明你至少在意“不要那么多列”。这里必须讲清楚 ODPS 的**列裁剪（column pruning）**机制，因为它直接决定你的账单。

ODPS 底层是列式存储，数据按列组织，执行引擎在优化阶段会分析你 SQL 里实际引用了哪些列，只把这些列的数据从存储层读上来。这意味着：你写SELECT a, b, c FROM wide_table，引擎真的只读这三列；你写SELECT * FROM wide_table，引擎老老实实把八百列全拉出来。两者在 IO 上的差距，跟你表的列宽比例基本成正比。

举个我手头的真实量级：一张日增 400GB 左右的埋点宽表，列数两百多，其中三个大字段（原始 JSON、UA 串、页面参数）合计占了七成体积。业务方每次SELECT * LIMIT 1000做抽样看数据，看着只要一千行，实际扫描量按列宽算下来能到几十 GB。改成显式列出六个需要的列之后，同样的查询扫描量掉到两三个 GB。按扫描量计费的场景下，这就是实打实的钱。

所以“排除某字段”这件事，动机往往不只是“我懒得写”，而是“我不想为这一列付钱”。把这个动机想清楚，你选方案的时候就不会贪图花哨的写法——能明确列出字段的方案，永远优于任何动态展开的方案。

顺带提一句分区裁剪。分区字段是目录级过滤，WHERE dt = '20240101'能把扫描范围锁死在一天。列裁剪和分区裁剪叠加使用，才是控制成本的正确姿势。只做列裁剪不做分区裁剪，等于省了横向浪费、没省纵向浪费。

1.3 哪些场景真的需要“除某字段之外”

我把实际遇到的场景归了归类，大概这么几种，你对号入座一下：

第一种和第二种是刚需，必须做，而且要做成可复现的机制，不能靠人记。第三种第四种是效率问题，脚本化就能解决。第五种其实用SELECT 指定列更直接，因为你要看的列通常很少，正着写比反着写短。

想清楚自己属于哪一类，后面的方案选型才有意义。如果你只是临时看一眼，直接手写几个字段名就完事了，别为了秀技术绕一大圈。工具要用在刀刃上。

2. 方案选型：五种做法摆桌面上比一比

排除字段这件事，从“纯手工”到“全自动”有一条很长的光谱。我把能落地的五种方案列出来，各自的适用边界、维护成本、风险点都讲清楚。这里没有绝对的最优解，只有跟你当前场景最匹配的那个。

2.1 手写字段清单：最笨，但很多场景它就是对

别看不起手写。如果你要排除的字段固定、表结构稳定、查询是一次性的，手写反而是最省事的。DESC tablename;一跑，结果集复制到编辑器里，用列编辑或者正则批量加逗号，两分钟搞定。

手写方案真正的优势不在写，在可读和可评审。你把SELECT user_id, item_id, action_type, ts FROM ...摆在 Code Review 里，任何人一眼能看出取了对不对、有没有漏敏感列。而一段自动生成的 SQL，评审的人根本不知道它动态拼了什么出来。

它有硬伤，而且是两个。第一个是维护成本随列数线性上升，八百列的表你抄一次就想辞职。第二个更隐蔽，叫字段漂移：上游今天加了个ext_info，你的手写清单不会自动包含它，结果下游表里这个字段永远是 NULL，等业务方发现数据不对，已经过去半个月了。这个坑我踩过，排查了一整天才定位到是字段清单没同步。

所以要用手写方案，必须配一条巡检：定期对比你的清单和information_schema里的实际列，差集不为空就告警。手写 + 巡检，本质上是把“自动”这件事挪到了监控侧。

2.2 元数据加字符串聚合：SQL 层解决，主力推荐

这是我最常用的方案。思路很直接：元数据里存着字段清单，那就用 SQL 把清单查出来，拼成一段字符串，再拼成一条新 SQL。

ODPS 提供information_schema，里面有columns这张视图，记录了当前 project 下所有表的所有列，字段包括table_schema、table_name、column_name、ordinal_position、data_type、comment等。你要做的就是按表名过滤、按位置排序、排除掉不想要的列、用字符串聚合函数拼起来。

聚合函数选WM_CONCAT。它的签名是WM_CONCAT(separator, expression)，注意分隔符在前、表达式在后，这个参数顺序坑过不少人，写反了会得到一个把逗号当数据拼进去的诡异结果。

SELECT CONCAT( 'SELECT ', WM_CONCAT(',', COLUMN_NAME), ' FROM my_project.dwd_user_action_di;' ) AS generated_sql FROM information_schema.columns WHERE table_schema = 'my_project' AND table_name = 'dwd_user_action_di' AND column_name <> 'phone' AND column_name <> 'id_card';

跑完把generated_sql这一列复制出来，就是一条完整可执行的查询。整个过程不到十秒，字段再多也不怕。

这套方案的好处是全在 SQL 里，不依赖任何外部工具，DataWorks 的数据开发节点里直接就能跑，跑完还能顺手把结果写进一张配置表，供下游调度读取。缺点有两个：一是WM_CONCAT的拼接顺序没有强保证，分布式执行下多个 mapper 的结果聚合顺序可能跟你预期不一致；二是它只能查当前 project 的元数据，跨 project 要额外处理权限。顺序问题后面单独讲，那是这篇里最容易被忽略的坑。

2.3 脚本自动化：一次写好，长期复用的正解

如果你的需求是“每天都要跑”，那 SQL 里生成 SQL 就不够了，得上脚本。用 pyodps 拿到表的 schema 对象，字段是有序的list，过滤一下就完事：

from odps import ODPS o = ODPS( access_id='your_ak', secret_access_key='your_sk', project='my_project', endpoint='http://service.cn-hangzhou.maxcompute.aliyun.com/api', ) def gen_select(table_name, exclude=None, project=None): exclude = {c.lower() for c in (exclude or [])} t = o.get_table(table_name, project=project) cols = [c.name for c in t.table_schema.columns if c.name.lower() not in exclude] full = f"{t.project}.{t.name}" return "SELECT\n " + ",\n ".join(cols) + f"\nFROM {full}" print(gen_select('dwd_user_action_di', exclude=['phone', 'id_card']))

这段代码的价值在于顺序确定。table_schema.columns是建表时定义的顺序，不会乱。这一点在做INSERT OVERWRITE的时候至关重要，后面会展开。

脚本还天然支持参数化、支持批量、支持写进 CI。比如你可以做一个表结构变更的自动检查：每天跑一遍，把生成的字段清单跟昨天存的做 diff，有变化就发通知。这才是长期跑下去应该有的形态。

2.4 视图与列级权限：治理层才是真答案

前面三种都是“查询时怎么绕”。但很多时候，你真正想解决的问题不是“我要写一条排除字段的 SQL”，而是“这一列不能被某些人看到”。这两件事在治理层的解法完全不同。

ODPS 支持列级权限授予，把表的指定列授权给指定对象，对方查SELECT *会直接报无权限，查授权范围内的列则正常。配套的还有视图：建一个只含安全列的视图，对外只暴露这个视图。

CREATE VIEW my_project.v_user_action_safe AS SELECT user_id, item_id, action_type, ts, dt FROM my_project.dwd_user_action_di; GRANT SELECT ON TABLE my_project.v_user_action_safe TO USER someone;

视图方案的软肋是它不会自动跟随上游表结构变化。上游加了新列，视图还是老的字段集合，除非你重建。所以它适合“稳定对外输出”的场景，不适合“天天变结构的探索”。

我的建议是分层：对外共享用视图加列权限，内部探索用脚本生成，临时看一眼手写。别指望一个方案通吃。

2.5 野路子：转成 JSON 再删键，仅供了解

最后说一个理论上能跑、实际千万别上生产的路子，主要是让你知道“为什么不该这么干”。

思路是把整行转成map或 JSON，在字符串层面把某个键删掉，再转回来：

SELECT FROM_JSON( REGEXP_REPLACE( TO_JSON(NAMED_STRUCT('a', a, 'b', b, 'phone', phone)), ',"phone":"[^"]*"', '' ), 'map<string,string>' ) FROM my_project.tbl;

看着挺聪明，问题一大堆：类型信息全丢了，数字变字符串、嵌套结构被拍平、正则一旦匹配到值里恰好出现的,"phone":"就会误删、字段顺序不可控、性能比直接列字段差一个数量级。这条路唯一的用处是在面试里展示你知道NAMED_STRUCT和TO_JSON怎么用，实际项目里出现一次我就得让人改一次。

3. 动手实现：从拿元数据到生成可执行 SQL

方案定完，进入实操。这一节我会把每一步的细节、参数、易错点都摊开，你可以直接照着抄。

3.1 快速看字段：DESC 的正确打开方式

最轻量的方式还是DESC。执行DESC my_project.dwd_user_action_di;会返回一张结果表，每行是字段名、类型、注释。客户端里能直接看，也能复制。

这里有个常识但经常被忽略：DESC的结果不能被当作子查询用。它不是一张真实的表，你不能写SELECT * FROM (DESC tbl)。想要“在 SQL 里查字段”，必须走information_schema。

另外DESC EXTENDED会返回更多信息，包括存储量、生命周期、是否分区等，排查“这表到底多大”的时候有用。如果客户端支持，SELECT * FROM tbl LIMIT 0也能拿到列名和类型，但要注意有些客户端在 LIMIT 0 时压根不发请求，直接返回空结构，别被误导。

3.2 用 information_schema 精确拿清单

正式方案从这里开始。第一步是确认你的 project 能不能查information_schema。它需要租户级别开启（多数新开的 project 默认可用），并且查询时需要List权限。没权限的话会报ODPS-0420095: Access Denied，找管理员加就行。

先跑一条最简单的验证：

SELECT ORDINAL_POSITION, COLUMN_NAME, DATA_TYPE, COMMENT FROM information_schema.columns WHERE table_schema = 'my_project' AND table_name = 'dwd_user_action_di' ORDER BY ORDINAL_POSITION;

几点说明。table_schema在这里填的是 project 名，不是数据库名，别搞混。ORDINAL_POSITION是列在表里的位置序号，从 1 开始，这是你排序的唯一可靠依据。注释字段在排查“这个字段到底是干嘛的”时特别好用，建议建表时养成写注释的习惯。

注意：information_schema.columns本身可能很宽，别习惯性SELECT *去查它，明确列出你要的几个字段就好。这张视图的数据量跟你 project 下的表数量成正比，在大 project 里全量扫一遍也不便宜。

还有一个容易忽略的问题：元数据有延迟。你刚ALTER TABLE ADD COLUMNS加完字段，立刻去查information_schema，很可能查不到，等几分钟再试。同理，刚创建的表也可能查不到。这不是权限问题，是元数据同步机制决定的，别在那儿反复怀疑自己写错了 SQL。

3.3 在 SQL 里把字段拼成字符串

拿到清单之后就是聚合。前面提过WM_CONCAT，这里把完整可用的版本写清楚，包括排序的处理：

SELECT CONCAT( 'SELECT ', WM_CONCAT(',', COLUMN_NAME), ' FROM my_project.dwd_user_action_di;' ) AS generated_sql FROM ( SELECT COLUMN_NAME FROM information_schema.columns WHERE table_schema = 'my_project' AND table_name = 'dwd_user_action_di' AND column_name NOT IN ('phone', 'id_card', 'raw_json') ORDER BY ORDINAL_POSITION ) t;

关于顺序，我得说句实话：子查询里的ORDER BY在分布式执行下不能百分百保证传递到聚合函数。多数情况下WM_CONCAT会按扫描顺序拼，但你不能拿这个当契约。所以我的做法是：生成的 SQL 只用来做临时排查和探索，不直接进生产调度。生产环境一律用脚本生成，脚本拿到的 schema 顺序是确定的。

如果你确实需要在 SQL 里保证顺序，还有一条路：用COLLECT_LIST拿到数组，再用ARRAY_JOIN拼：

SELECT CONCAT_WS(',', COLLECT_LIST(COLUMN_NAME)) FROM ( SELECT COLUMN_NAME FROM information_schema.columns WHERE table_schema = 'my_project' AND table_name = 'dwd_user_action_di' AND column_name <> 'phone' ORDER BY ORDINAL_POSITION ) t;

同样存在顺序不保证的问题，但至少写法上更清晰。真要死磕顺序，还是在客户端拿结果集自己拼最稳。

还有一种半自动的玩法：把information_schema的查询结果落到一张配置表里，每天调度跑一次。之后你需要生成任何 SQL，都从这张配置表读字段，用WM_CONCAT拼。这样元数据延迟的影响被吸收在调度层，业务侧拿到的永远是最新的。这套做法在中大型项目里我强烈推荐。

3.4 一个可复用的 Python 生成器

脚本版我写成半 CLI 的形态，方便直接拿去用：

import argparse from odps import ODPS def build_select(table, excludes, project=None): t = o.get_table(table, project=project) cols = [c.name for c in t.table_schema.columns] parts = t.table_schema.partitions keep = [c for c in cols if c.lower() not in excludes] missing = excludes - {c.lower() for c in cols} if missing: print(f"[warn] 以下字段在表中不存在，已忽略: {sorted(missing)}") full = f"{t.project}.{t.name}" sql = "SELECT\n " + ",\n ".join(f"`{c}`" for c in keep) + f"\nFROM {full}" if parts: cond = " AND ".join(f"{p.name} = '${{{p.name}}}'" for p in parts) sql += f"\nWHERE {cond}" return sql if __name__ == "__main__": ap = argparse.ArgumentParser() ap.add_argument("table") ap.add_argument("--exclude", default="") ap.add_argument("--project", default=None) args = ap.parse_args() excludes = {s.strip().lower() for s in args.exclude.split(",") if s.strip()} print(build_select(args.table, excludes, args.project))

几个设计点值得说一下。第一，字段名统一加反引号，规避保留字问题，这个后面细讲。第二，对不存在的字段打 warn 而不是直接报错，因为你的排除清单往往是跨表复用的，A 表有phone、B 表没有，不应该因此中断。第三，分区字段单独处理，生成WHERE子句的骨架，调度替换变量。第四，t.project和t.name拼全名，跨 project 也不会错。

实测下来，这个脚本处理两千列的表也是毫秒级，因为 schema 是元数据，不走计算。

3.5 生成完必须校验的三件事

生成的 SQL 别急着跑，先校验。我固定查三样。

第一，列数对不对。表总列数减去排除数，必须等于生成 SQL 里的字段数。简单算术，但就是有人不做，结果跑出来少一列还以为是数据问题。

第二，字段顺序对不对。这一条在做INSERT OVERWRITE TABLE t2 SELECT ...的时候是致命的。不带列名的 INSERT 是按位置匹配的，你的目标表第一列是user_id，生成的 SQL 第一列排成了item_id，数据就这么错位写进去了，而且不报错。等你发现，下游已经用了半个月脏数据。我的习惯是：生成 SQL 之后，把目标表结构也DESC一遍，两边列名做一次严格的位置比对。

第三，跑一次LIMIT 100。最小成本验证语法、字段名、类型转换都没问题。有些字段名带特殊字符，前面看不出来，一跑就炸。

提示：如果目标表是你自己建的，强烈建议 INSERT 时把目标列名也写上。虽然啰嗦，但它把“按位置匹配”变成了“按名字匹配”，字段顺序错了也不至于写脏数据。这个习惯救过我至少两次。

4. 踩坑实录与常见问题速查

这一节是我这些年在这个话题上真正吃亏的地方，比语法本身有价值得多。

4.1 保留字与特殊字符：反引号是保命符

字段名叫desc、order、user、comment、timestamp、date、location、year、month、day这类，在 ODPS 里直接裸写会解析失败。解法是加反引号：

SELECT `desc`, `order`, user_id FROM my_project.tbl;

麻烦在于，你用information_schema生成 SQL 时，脚本不知道哪个是保留字，生成出来的裸字段名一跑就报错。所以我前面脚本里统一加了反引号，这个成本极低，收益极高。所有自动生成的 SQL，字段名一律加反引号，不要做智能判断，判断不准。

还有个更隐蔽的：字段名里含点号。比如a.b，解析器会认为你在访问嵌套结构a的b字段。这种情况下光加反引号也不一定够，得看引擎版本。真遇到这种命名，我的建议是重建表改掉，别在查询层硬扛。命名规范这件事，早期省事，后期还债。

大小写的问题也提一句。ODPS 的列名默认不区分大小写，建表时写UserID会被转成小写存储，information_schema里返回的也是小写。如果原表是用带引号的写法建的（某些场景下会保留大小写），生成 SQL 时要注意匹配。日常情况用不着操心，但如果你从别的引擎迁移过来，这里可能有惊喜。

4.2 分区字段：既在表里，又不在表里

分区字段的处理是个经典陷阱。dt这种分区列，在SELECT *里是会被带出来的，在information_schema.columns里也往往有记录，位置排在最后。但它的物理存储跟普通列不一样，它是目录名，不是文件里的列。

实际影响有两点。一，如果你用脚本拿table_schema.columns，分区列可能不在里面（不同版本行为不一），得额外从table_schema.partitions取。二，生成 SQL 之后，分区字段应该出现在WHERE里做过滤，而不是在SELECT列表里被当作普通列处理——虽然写进去也不报错，但语义上很怪，而且会影响分区裁剪的判定。

我的处理方式是：生成的 SELECT 列表里保留分区列（下游经常需要），同时在 WHERE 里加上分区条件，两个都写。这样不论下游怎么消费都不会缺。

4.3 嵌套类型与复杂字段

ODPS 支持STRUCT、ARRAY、MAP这些复杂类型。这类字段在“排除”的时候有个坑：你以为是排除一个字段，实际上排除了一个字段树。

比如ext是个STRUCT<os:STRING, ip:STRING, ver:STRING>，你把它排除掉，等于同时丢了三个子字段。如果下游只需要ext.os，那你其实不用排除整个ext，写成ext.os就行，列裁剪会只读这一个子字段，成本更低。

SELECT user_id, ext.os, ext.ver FROM my_project.tbl;

这个技巧在处理超宽嵌套结构时特别有用。一个STRUCT里塞了五十个子字段很常见，全都不要的时候才排除整棵。判断标准很简单：你要的是这个容器，还是容器里的某个东西。

4.4 权限、跨 project 与元数据延迟

information_schema只能查你有权限的对象。跨 project 查询时，table_schema填对方的 project 名，你需要对该 project 有相应的读权限，否则查到的是空结果——注意是空结果，不是报错，这个特别坑，容易让人以为表不存在。

元数据延迟前面提过，这里给个经验值：DDL 操作后通常几分钟内可见，极端情况下十几分钟。如果你的调度依赖“加完字段立刻生成 SQL”，中间一定要留缓冲，或者干脆改成每天定时刷新配置表。

还有一类是外部表、映射表。这类表的 schema 来自外部系统，information_schema里可能有记录，但字段类型映射未必准确。遇到行为诡异的情况，先DESC看一眼实际结构，别迷信元数据视图。

4.5 常见问题速查表

5. 性能与治理：把“排除字段”做成长期习惯

5.1 列裁剪生效的前提条件

前面说了列裁剪能省钱，但它不是无条件生效的。想让它真正起作用，有几个前提。

写SELECT *一定不裁剪，这是最直白的。用视图也不行，视图本质是展开成底层查询，如果视图定义里是SELECT *，照样全读。函数包裹字段不影响裁剪，SUBSTR(name, 1, 10)依然只读name这一列。但如果你在 WHERE 里对分区字段做了函数运算，比如WHERE DATE_FORMAT(dt, 'yyyyMM') = '202401'，分区裁剪可能失效，变成全表扫。这条在超大表上能差出两个数量级。

我的经验是：任何进入生产调度的 SQL，都不允许出现SELECT *，除非是明确的“全字段导出”需求并且已经评估过成本。这条规则靠 Code Review 卡，比事后看账单有用。

5.2 大字段的物理拆分

如果你的表里有那几个“一列顶十列”的大字段，最彻底的解法不是查询时排除，而是建表时就拆出去。

做法是主表只放高频、小体积的字段，大字段单独建一张扩展表，用主键关联。查询时按需 JOIN，不需要就不 JOIN。这样主表的扫描成本天然就低，也不用每次写 SQL 都记得排除。

代价是多一次关联，以及要维护两张表的一致性。值不值得，看你大字段的占比。我的经验阈值是：单列平均长度超过 1KB，且被查询引用的频率低于 30%，就该考虑拆。

5.3 字段漂移巡检：手写方案的生命线

如果你团队里还有人在用手写字段清单（多数团队都有），那就必须配巡检。思路很简单：每天跑一次脚本，把“已登记的手写清单”和“information_schema里的实际列”做差集，有新增列就告警。

def check_drift(table, registered_cols, project=None): t = o.get_table(table, project=project) actual = {c.name for c in t.table_schema.columns} added = actual - registered_cols removed = registered_cols - actual if added: print(f"[新增未登记] {table}: {sorted(added)}") if removed: print(f"[已删除未清理] {table}: {sorted(removed)}")

输出直接推到团队的告警渠道。这套东西写一次，能避免后面无数次“数据怎么是 NULL”的排查。

5.4 权限与视图的组合拳

最后说治理。如果排除字段的目的是“不让某些人看到”，那在查询层做排除是治标不治本的，因为别人照样可以写SELECT phone FROM tbl。

正解是列级授权加视图。把安全列做成视图对外发布，敏感列单独授权给明确需要的少数人。视图的维护成本在于上游加字段不会自动同步，所以要配一个定期重建的调度，或者干脆接受“视图字段集合是快照”这个事实，业务需要新字段时提需求。

这两条路我都走过。前者自动但复杂，后者手动但清晰。小团队用后者，大团队用前者。

我个人在这个话题上最大的体会是：“排除某字段”看着是个语法问题，实际上是个元数据管理问题。你越早把字段清单当成一种可以查询、可以比对、可以版本化的数据，后面所有的麻烦都会小很多。反过来，如果一直靠人肉抄、靠记忆维护，那么每一次表结构变更都是一次事故的种子，只是早晚的问题。

最后分享一个我每天都在用的小习惯：生成任何一段字段清单之后，先LIMIT 100跑一遍，看列名对不对，再看前几行数据像不像。三十秒的事，能挡掉八成低级错误。