char(10)表示换行（lf），char(13)表示回车（cr）；windows下需组合char(13)+char(10)才显示换行，linux/macos单用char(10)即可，且不同数据库函数名不同：sql server/mysql用char()，postgresql/oracle用chr()。
CHAR(10) 和 CHAR(13) 在 SQL 中的实际行为差异
SQL 里的 CHAR() 函数确实能生成控制字符，但不同数据库对换行符的解释不一致。多数情况下，CHAR(10) 是换行（LF），CHAR(13) 是回车（CR）。Windows 环境下常需组合使用 CHAR(13) + CHAR(10) 才能渲染出真正“换行”，而 Linux/macOS 下单用 CHAR(10) 就够了。
注意：这些字符在 SELECT 结果中可能被客户端工具（如 SSMS、DBeaver、MySQL Workbench）自动折叠或忽略显示——不是生成失败，而是渲染问题。
- SQL Server 默认支持
CHAR(10)和CHAR(13)，且允许拼接：CHAR(13)+CHAR(10) - PostgreSQL 使用
CHR(10)，不是CHAR()；CHAR()在 PG 中是类型转换函数，不能生成字符 - MySQL 5.7+ 支持
CHAR(10)，但严格模式下若字段为VARCHAR且未开启pad_char_to_full_length，末尾空白（含换行）可能被截断
用 CHAR() 拼接多行文本时的常见陷阱
直接写 SELECT '第一行' + CHAR(10) + '第二行' 看似合理，但在某些场景下会失效——比如目标字段是 CHAR 类型（固定长度），或参与 GROUP BY / ORDER BY 时，换行符可能被隐式忽略或影响排序逻辑。
更隐蔽的问题是：当把含 CHAR(10) 的字符串插入到日志表、导出 CSV 或喂给前端渲染时，没做转义就直接输出，容易导致 HTML 注入或 JSON 解析失败。
- 避免在
WHERE条件里用CHAR(10)做匹配，因为索引通常不包含控制字符，且比较行为依赖 collation - 如果字段定义为
TEXT或varchar(max)（SQL Server）/TEXT（MySQL），存储没问题；但CHAR(50)这类定长类型会用空格补足，破坏换行结构 - 拼接时建议显式转换：例如 SQL Server 中写
CONVERT(varchar(max), 'a') + CHAR(10) + CONVERT(varchar(max), 'b')，防止隐式类型提升失败
制表符 CHAR(9) 的显示与对齐问题
CHAR(9) 是制表符（Tab），但它在大多数 SQL 客户端里不会触发“对齐到下一个 4/8 位边界”的效果——它只是存了个 ASCII 9 字符。真正在终端或编辑器里看到对齐，依赖下游程序（如 vim、cat、Excel）的 Tab 渲染逻辑，数据库本身不处理 Tab 的视觉展开。
这意味着：用 CHAR(9) 分隔字段再导出，不如直接用逗号或自定义分隔符可靠；想靠它实现“表格对齐”纯属误解。
- 导出为 CSV/TXT 时，
CHAR(9)可能被 Excel 识别为列分隔符（如果启用了“Tab 分隔”导入选项），但多数 ETL 工具默认只认逗号 - 在字符串中混用
CHAR(9)和空格，可能导致LEN()/LENGTH()返回值与肉眼所见长度不一致 - Oracle 不支持
CHAR(9)作为函数调用，得用CHR(9)；SQLite 同样用CHAR(9)，但要注意其CHAR()接受多个参数，CHAR(9,10)会返回两个字符
跨数据库生成控制字符的可移植写法
没有一行通用的 CHAR() 调用能在所有数据库中生效。最稳妥的方式是按目标方言写条件分支，或在应用层生成后再传入 SQL——尤其当逻辑复杂、涉及多次拼接或动态长度时。
如果必须在 SQL 内完成，优先查文档确认函数名和参数范围：SQL Server 和 MySQL 用 CHAR(n)，PostgreSQL 和 Oracle 用 CHR(n)，SQLite 用 CHAR(n) 但行为略有不同。
- 不要假设
CHAR(0)可用——多数数据库禁止空字符（CHAR(0)），会报错或静默替换 - MySQL 中
CHAR(10 USING utf8mb4)是合法语法，但仅用于指定字符集，不影响控制字符语义 - 测试时别只看 SELECT 输出，要用
DATALENGTH()（SQL Server）、OCTET_LENGTH()（PostgreSQL）或LENGTH()（MySQL）验证字节是否真实写入
