导出CSV时中文乱码、数值失真、NULL处理不一致及计算字段偏差，根本原因在于客户端字符集不匹配、类型隐式转换、空值默认行为差异以及时区/精度上下文丢失；须统一utf8mb4连接、显式格式化字段、替换NULL、固定时区与精度并验证结果。
导出 CSV 时中文乱码：MySQL 客户端字符集不一致
导出视图结果为 CSV 后出现中文显示为问号或方块，根本原因通常是客户端连接使用的字符集和表/视图实际存储的字符集不匹配。比如表用 utf8mb4，但 mysql 命令行工具默认以 latin1 连接，导出时就发生隐式转码丢失。
实操建议：
- 导出前显式指定连接字符集：
mysql --default-character-set=utf8mb4 -u user -p db_name - 在会话中执行
SET NAMES utf8mb4;再查视图，确保character_set_client、character_set_results、character_set_connection全部为utf8mb4 - 用
SELECT @@character_set_client, @@character_set_results, @@character_set_connection;实时验证 - 若用
mysqldump导出视图结果（配合--tab或重定向），必须加--default-character-set=utf8mb4，否则字段值在写入文件前已被截断
日期/数字字段导出为科学计数法或截断：类型隐式转换导致格式失真
视图中 DATE、DECIMAL(10,2) 等字段导出到 CSV 后变成 2024-05-12 00:00:00 或 1.2345e+6，不是数据库里原始格式，而是客户端或导出工具按自身规则做了类型转换。
实操建议：
- 避免直接
SELECT *导出，对关键字段显式格式化：DATE_FORMAT(created_at, '%Y-%m-%d')、CAST(amount AS CHAR)、CONCAT('', price)强制转字符串保留精度 - 使用
INTO OUTFILE时，MySQL 默认不处理格式，但需注意：该语句要求有FILE权限且只能写入服务端路径，不适合本地导出；如需本地 CSV，优先走客户端导出 + 格式化 - 若用 Python 的
pandas.read_sql()，记得传dtype参数锁定列类型，例如{'price': str}防止自动转为 float 后导出失真
NULL 值导出为空字符串或 N：字段空值表示不统一影响下游解析
不同导出方式对 NULL 的处理差异极大：命令行重定向可能输出空字段，INTO OUTFILE 默认输出 N，Excel 打开 CSV 又可能把 N 当普通文本。这会导致下游 ETL 脚本误判空值类型。
实操建议：
- 统一用
IFNULL(col, '')或COALESCE(col, '')显式替换，避免依赖导出工具默认行为 - 若必须保留
NULL语义，导出时加FIELDS ENCLOSED BY '"' ESCAPED BY '\'并确认下游能识别"\N"（注意转义层级） - 用
mysql -B -e "SELECT ..."时，-B（批处理模式）会用 tab 分隔且 NULL 输出为NULL字符串，非 CSV；如需 CSV，应搭配--csv参数（MySQL 5.7.17+），它会正确处理 NULL 为""并转义引号
视图含计算字段或函数：导出时精度/时区/上下文丢失
视图里用了 NOW()、CONVERT_TZ()、ROUND(price * 1.08, 2) 等动态计算字段，导出结果可能和预期不符——比如时区没设对导致时间偏移，或浮点中间计算引发舍入误差。
实操建议：
-
NOW()类函数导出的是执行时刻值，无法回溯；如需固定快照时间，改用变量：SET @snap = NOW(); SELECT ..., @snap AS snap_time FROM view_name; - 涉及时区转换，务必在查询前执行
SET time_zone = '+08:00';，不能只依赖系统或会话默认值 - 数值计算字段优先用
DECIMAL显式声明精度，避免FLOAT累积误差；例如ROUND(CAST(price * 1.08 AS DECIMAL(12,2)), 2) - 导出前先
SELECT验证几行结果，尤其关注边界值（如99.995是否被 Round 成100.00），别等导入后才发现偏差
导出看似只是“把数据写出来”，但视图背后的数据类型、字符集、计算上下文、空值约定，全都会在导出瞬间暴露成具体格式问题。最容易被忽略的是：你以为导出的是“值”，其实导出的是“当前连接上下文 + 查询执行时刻 + 工具默认策略”的混合产物。
