四种库收进一个SQL编辑器（下）：跨库取数、方言对齐与四库巡检的落地拆解

四种库、四套账号、四个客户端：MySQL 出订单、PostgreSQL 出维度表、ClickHouse 出埋点、SQLite 存本地元数据，取一次完整报表要在四个窗口之间来回切，快捷键不同、结果网格不同、导出格式也不同，切到最后人已经分不清哪份数据是几点跑出来的。

常见的补法是给每个库各写一套脚本、各挂一个定时任务，能跑，但方言差异、凭据分散、故障定位这三件事永远治不好，换一台机器就要重来一遍。上篇聊了选型思路和基础连接，这次直接进深水区。

本文分享一套把四种库收进同一个编辑器的完整打法：数据源配置模板 + dbconsole 批量取数 + 方言对齐表 + 对账与巡检脚本，四段都能直接落地。

一、连接层：四库驱动与参数一次钉死：

开箱第一件事不是写 SQL，而是把四套连接参数钉死：

• 先确认端口与驱动：四库的默认端口、驱动大版本、字符集一次性核对完，不然后面每条慢查询都要回头怀疑连接层。
• 再统一别名命名 ：数据源按「库类_用途」命名（如 mysql_erp），脚本里只引用别名，IP 变了只改配置不改脚本。

数据库	端口 / 路径	编辑器里最容易踩的点
MySQL 8.0	3306	驱动选 8.x，连接串带 serverTimezone，否则时间差 8 小时
PostgreSQL 16	5432	库名和 schema 是两层，默认 public 很容易写错
ClickHouse	8123（HTTP）	建议走 HTTP 驱动，大结果集先设 max_result_rows
SQLite	本地文件	只读打开省心，要写得先放开 journal_mode

把四库数据源写成一份可版本管理的配置，换机器时直接导入：

# ds-config.yaml ------ 四库数据源声明，导入编辑器即可复用
sources:
  mysql_erp:    { type: mysql,      host: 10.0.3.11, port: 3306, db: erp,     user: ro_etl }
  pg_warehouse: { type: postgres,   host: 10.0.3.12, port: 5432, db: dwh,     user: ro_etl }
  ch_events:    { type: clickhouse, url: "http://10.0.3.13:8123", db: events, user: ro_etl }
  sqlite_meta:  { type: sqlite,     file: /data/meta.db, readonly: true }

一份配置 → 四个连接 → 同一套账号命名，换机器不再重配

**核心结论：**连接层九成的怪问题来自驱动版本和时区参数，先钉死再谈查询。

二、跨库取数：一条链路把四库结果拼成一份报表：

真正的痛点是四张表分属四个库，报表却只要一份：

• 各自为战的老办法：每换一个库就换客户端、换快捷键，导出的 CSV 散落在四个目录，命名还各不相同。
• 编辑器的解法 ：同一窗口开四个控制台，再用编辑器自带的 dbconsole 命令行把同一份调度交给不同数据源。

写 SQL → 指定数据源 → CLI 批量执行 → 结果落 CSV → 汇总进一张表

下面这段 bash 做的事是：在 Linux/macOS 上循环四个数据源，逐个执行对应 SQL 并输出统一格式的 CSV。

#!/usr/bin/env bash
# 取数主脚本：四个数据源共用一套调度，输出统一到 out/ 目录
mkdir -p out
for ds in mysql_erp pg_warehouse ch_events sqlite_meta; do
  dbconsole -datasource "$ds" -script "sql/${ds}.sql" -format csv -output "out/${ds}.csv"
done
wc -l out/*.csv

同一条命令换个 -datasource 就换库，四库取数可以塞进同一个定时任务

**核心结论：**取数链路统一的标志，是「哪个库」从人脑搬进了参数里。

三、方言对齐：一套模板在四种库都跑得通：

四库 SQL 各写各的必然失控，先得把差异摊在一张表上：

能力	MySQL	PostgreSQL	ClickHouse	SQLite
取前 N 行	LIMIT n	LIMIT n	LIMIT n	LIMIT n
字符串拼接	CONCAT()	`		`
当前时间	NOW()	NOW()	now()	datetime('now')
自增主键	AUTO_INCREMENT	SERIAL	需用 ID 生成函数	INTEGER PRIMARY KEY
NULL 排序	最小	最大	最小	最小

• 模板占位法 ：SQL 主体只写一遍，用 {``{ts}}、{``{limit}} 这类占位符，执行前按方言表替换。
• 最小公共集 ：SELECT/WHERE/GROUP BY 能表达的绝不引入专有能力，专有函数单独放扩展段落。
• PG 的 NULL 最大：这一条最容易在跨库排序时翻车，对齐时务必单独测一版再上线。

**核心结论：**目标不是让四种库说同一种 SQL，而是让公共那部分说同一种。

四、数据搬运：四库之间的导出、装载与对账：

跨库同步最容易「跑通了但数不对」，链路必须自带校验：

抽取（口径固定） → 落 CSV/Parquet → 按目标库方言装载 → 行数与主键集合对账 → 有差异即重跑

• 抽取口径前置统一：四库各写一段 SQL，字段名直接对齐目标表，别指望装载阶段再改名。
• 对账脚本常驻：装载前后各跑一次，差异主键非空就回滚，别让脏数据过夜。

下面这段 Python 做的事是：对比两份 CSV 的行数与主键集合，零第三方依赖，Python 3.10+ 直接可跑。

# check.py ------ 装载前后对账：先比主键集合，再看行数差
import csv, sys

def load(path):
    with open(path, newline="", encoding="utf-8") as f:
        rows = list(csv.DictReader(f))
    return rows, {r["id"] for r in rows}

src_rows, src_ids = load(sys.argv[1])
dst_rows, dst_ids = load(sys.argv[2])
print(f"src={len(src_rows)} dst={len(dst_rows)}")
print("缺主键:", sorted(src_ids - dst_ids)[:5], "多主键:", sorted(dst_ids - src_ids)[:5])

先比主键集合再看行数，行数相等也可能整批错位

五、权限与安全：四库合流时的边界怎么划：

一个客户端盯四个库，等于把四份权限装进同一个抽屉：

• 只读账号先行 ：日常查询统一走 ro_etl 这类只读账号，写权限单独立一条数据源，名字里直接带 rw 以免误点。
• 凭据不落明文：编辑器主密码与系统钥匙串都要打开，配置文件里只留数据源别名，真正的口令交给凭据管理器。
• 审计能对上人：四库建号时统一加同一前缀，出问题时按前缀就能回溯到具体这台编辑器和这个人。

问题：写权限混在日常连接里，一次误 UPDATE 就污染四个库

治理：写操作单独数据源 + 语句白名单 + 仅在变更窗口启用

**核心结论：**多库合流的前提是权限先分层，便利永远排在边界之后。

六、日常巡检：把四库健康度压进一条命令：

两个多月下来最省时间的，是把巡检做成固定动作：

现象	先查什么	常见根因
ClickHouse 查询超时	max_execution_time、分区裁剪	大表没带分区键
PostgreSQL 报 too many connections	pg_stat_activity	连接池没复用
MySQL 时间差 8 小时	连接串 serverTimezone	驱动与系统时区不一致
SQLite 报 database is locked	journal_mode、并发数	多进程同写一个文件

下面这段 bash 做的事是：定时探测四个数据源的连通性与响应耗时，挂进 crontab 即可无人值守。

#!/usr/bin/env bash
# pingdb.sh ------ 四库连通性巡探，5 分钟一次即可覆盖绝大多数连接类故障
for ds in mysql_erp pg_warehouse ch_events sqlite_meta; do
  t=$( { time dbconsole -datasource "$ds" -script sql/ping.sql -format csv > /dev/null; } 2>&1 | grep real )
  echo "$ds  $t"
done

连通性 + 耗时 + 结果行数，三个指标能定位八成连接类故障

结语

把四种库收进一个编辑器，价值不在少装几个软件，而在于取数、搬运、巡检共用同一条链路：配置一份、调度一套、对账一个脚本，四库之间的差异被压缩成一张方言表和几个占位符，人只需要盯口径和校验。

两个月下来最深的感受是异构库治理没有银弹，真正起作用的是把「换个库」从一次手工操作降级成一个参数，让工具承担重复，让人承担判断。

当「换库」只是换一个参数时，异构库才算真正被驯服。