SQL*Plus需SET HEADING OFF、FEEDBACK OFF、VERIFY OFF、PAGESIZE 0、LINESIZE足够大；MySQL用--batch（-B）加--raw；PostgreSQL用-t（--tuples-only）配-P fieldsep和null选项。
SQL*Plus 里怎么关掉列头和反馈行，只留纯数据
默认 sql*plus 输出带列名、分隔线、统计行（比如 “123 rows selected.”），导出到脚本或管道时会干扰解析。要纯数据，得关三样：heading（列头）、feedback（查询结果行数提示）、verify（变量替换提示）。另外 pagesize 设为 0 可避免分页符，linesize 要足够宽防换行截断。
-
SET HEADING OFF：关闭列名输出 -
SET FEEDBACK OFF：关掉 “X rows selected.” 这类提示 -
SET VERIFY OFF：防止&var替换时打印旧值/新值 -
SET PAGESIZE 0：消除分页空行（注意不是SET PAGES 0，后者无效） -
SET LINESIZE 32767：避免长字段被折成多行（尤其含 JSON 或 XML 时）
MySQL 命令行怎么导出无格式 CSV 或制表符分隔数据
MySQL 客户端默认带边框和对齐，用 --batch（简写 -B）是关键开关，它让输出变成 tab 分隔、无框线、无对齐。再配合 --raw 可禁用转义（比如把 \n 当字面量而非换行），而 --silent 会进一步压制警告——但别乱开，它也会吞掉错误信息。
-
mysql -u user -p -B -e "SELECT id,name FROM users;" db_name→ tab 分隔，无头无框 - 加
--raw后，字段里的换行符、制表符不再被转义为\n/\t，适合导原始文本 - 如果要 CSV，
--batch输出仍是 tab 分隔；真要逗号分隔，得用SELECT ... INTO OUTFILE或外部工具转换 -
--silent会让连接失败也不报错，调试时慎用
PostgreSQL psql 怎么切到纯元组输出模式
psql 的 -t（--tuples-only）是核心开关，它干掉列名、分隔线、行数统计，只留数据行。但它不处理 NULL 显示（默认是空字符串），也不控制 NULL 字符串化方式——这时候得配 -P format=unaligned 和 -P fieldsep='|' 等。
-
psql -t -c "SELECT id, email FROM accounts;" mydb→ 每行纯数据，tab 分隔 - 想换分隔符：加
-P fieldsep=','，但注意这不等于标准 CSV（不加引号、不转义） - NULL 默认输出为空，若需显示
\N（类似 MySQL 的\N），加-P null='\N' - 别依赖
-A（--no-align）单独使用——它只关对齐，不关列头；必须和-t配合才真正“纯”
导出时字段含换行或特殊字符，为什么还是乱？
关掉格式只是第一步。真正导致解析失败的，往往是字段内容本身：换行、制表符、双引号、逗号。各工具对这些的默认处理不同，且大多不自动加引号或转义。
-
SQL*Plus完全不处理字段内换行，SET LONGCHUNKSIZE和SET LONG只影响CLOB截断长度，不解决分隔问题 - MySQL
--batch把换行存成真实 \n，接收方必须按行读取并识别字段边界——意味着你不能用简单split('\n')再split('\t') - PostgreSQL
-t同样输出原生换行；如需安全 CSV，得用COPY (SELECT ...) TO STDOUT WITH (FORMAT CSV, HEADER true)，但这只能在服务端执行，不能走 psql 客户端命令 - 最稳的路：不在 SQL 层拼 CSV，而是用程序读取原始结果后，用对应语言的 CSV 库（如 Python
csv.writer）生成——它会自动加引号、转义、处理嵌入换行
字段内容不可控时，“无格式”不等于“可直接解析”，分隔符和内容冲突永远是最容易被跳过的点。
