异构表字段映射本质是文本替换，应使用 awk+sed 处理纯文本 DDL；需抽离 mapping.conf 规则，用正则捕获组处理括号嵌套类型；Windows 计划任务须用绝对路径并切换工作目录；pg_dump 输出需先去双引号或适配引号匹配；高精度 TIMESTAMP 需降级处理并校验。
用 awk + sed 做字段类型映射的批处理脚本
异构表字段映射本质是文本替换问题，不是数据库操作问题。别一上来就写 python 脚本或连 jdbc——多数场景下，源表结构是 sql ddl 文件、csv 描述表或 excel 导出的纯文本，直接用 shell 工具链更轻、更快、更易调试。
常见错误是把映射逻辑硬编码进 SQL 生成器里，结果换一个目标库（比如从 MySQL 切到 Doris），整个脚本重写。正确做法是把映射规则抽成独立配置文件：
-
mapping.conf每行格式：source_type → target_type，例如VARCHAR(255) → STRING - 主脚本用
awk读取 DDL 行，匹配CREATE TABLE后的字段定义段，再用sed -f批量替换类型 - 注意括号嵌套：
VARCHAR(100)和DECIMAL(18,2)不能靠简单字符串替换，要用正则捕获组，例如sed -E 's/VARCHAR\(([0-9]+)\)/STRING/g'
Windows 上用 schtasks 定时跑映射脚本失败的典型原因
很多人在 Windows 上写好 map_fields.bat，手动双击能跑通，但加到计划任务后报错 “系统找不到指定的文件” 或字段全没被替换——根本原因是环境路径和工作目录不一致。
计划任务默认以 System32 为当前目录启动，且不加载用户 PATH 中的 awk/sed。解决方案只有两个：
- 脚本开头强制切到项目目录：
cd /d "D:\etl\schema" - 所有外部命令用绝对路径：
"C:\tools\gawk\awk.exe" -f map.awk input.sql，别依赖PATH - 勾选计划任务的“不管用户是否登录都要运行”，并启用“运行时请勿显示界面”，否则 GUI 弹窗会卡住任务
PostgreSQL pg_dump --schema-only 输出与映射脚本的兼容性坑
pg_dump 默认输出带双引号的标识符，比如 "user_id" VARCHAR(50)，而你的映射脚本如果只匹配 VARCHAR 前面是空白或括号，就会漏掉这些字段。
这不是 bug，是设计使然。PostgreSQL 为保留关键字或大小写敏感名自动加引号，必须在映射前先剥离或适配：
- 用
sed 's/"\([^"]*\)"/\1/g'先去掉所有双引号（前提是确认没有字段名含双引号） - 或者改写匹配正则：把
\s+VARCHAR改成[[:space:]"]+VARCHAR，兼容前面可能有引号或空格的情况 - 注意
pg_dump的--no-tablespaces和--no-owner必须加上，否则输出里混入TABLESPACE xyz这类干扰行，导致awk解析错位
当目标库是 Hive/StarRocks 时，TIMESTAMP 映射要特别小心
Hive 的 TIMESTAMP 不支持纳秒精度，StarRocks 的 DATETIME 默认只到秒；而源库（如 MySQL 8.0+）DDL 可能带 TIMESTAMP(6)。直接映射成 TIMESTAMP 会导致建表失败或数据截断。
这不是类型名对不上，而是精度语义冲突。必须在映射层做降级处理：
- 统一映射为无精度声明的
TIMESTAMP（Hive 接受），或显式转成STRING（StarRocks 更稳妥） - 避免用
sed粗暴替换所有TIMESTAMP—— 要区分字段定义里的TIMESTAMP和注释里的-- created TIMESTAMP - 建议加一行校验：
grep -E 'TIMESTAMP\([0-9]+\)' ddl.sql && echo "WARN: found high-precision TIMESTAMP"，人工介入确认
最麻烦的从来不是写映射规则，而是不同数据库对同一名词的实际约束不一致。比如 TEXT 在 MySQL 是大对象，在 Doris 里压根不支持——这种地方只能靠配置文件里加注释，而不是指望脚本能智能判断。
