MySQL存储过程无法直接导出CSV或Excel文件，仅支持受限的SELECT...INTO OUTFILE，需服务器权限、固定路径且客户端不可访问；真正可行方案是存储过程封装查询逻辑，由Python等外部工具调用并格式化输出。
MySQL存储过程里没法直接导出文件
想用 CREATE PROCEDURE 写个存储过程，自动把查询结果存成 CSV 或 Excel？行不通。MySQL 存储过程本身不支持 SELECT ... INTO OUTFILE 以外的导出方式，而 INTO OUTFILE 还受限于服务器权限、路径写死、只能写到数据库服务器本地——客户端根本拿不到。
常见错误现象：ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option，或者导出文件出现在 /var/lib/mysql/ 下却找不到入口。
-
INTO OUTFILE路径必须绝对，且得在secure_file_priv配置指定目录内 - 导出用户需有
FILE权限（不是普通 SELECT 权限） - 导出文件属主是 mysqld 进程用户（如 mysql），普通用户无法直接读取或下载
- 无法动态拼接文件名（
CONCAT()在INTO OUTFILE中不被允许）
真正能落地的“批处理导出”得靠客户端配合
所谓“存储过程实现批处理导出”，实际是指：用存储过程封装查询逻辑 + 参数化过滤 + 分页组装，再由外部工具（如 Python、Shell、甚至 MySQL 客户端）调用并完成格式化输出。这才是可维护、可调度、可监控的做法。
使用场景：定时导出昨日订单、按地区分片导出用户数据、导出前先做聚合清洗。
- 存储过程只负责
SELECT逻辑，比如proc_export_orders_by_date接收in_start_date和in_end_date - 避免在存储过程中做大量字符串拼接或游标循环——性能差、调试难、容易锁表
- 如果真要用游标分批处理（比如逐条发 HTTP 请求），务必加
COMMIT控制事务粒度，否则长事务拖垮并发 - Python 示例（用
mysql-connector-python）：cursor.callproc('proc_export_orders_by_date', ['2024-05-01', '2024-05-01'])<br>for result in cursor.stored_results():<br> rows = result.fetchall()后续用csv.writer写出即可
替代方案：用 mysqldump + WHERE 比写存储过程更轻量
如果只是导出某张表的子集，mysqldump 加 --where 参数比写存储过程快得多，也不依赖数据库权限配置。
参数差异：mysqldump -u user -p db table --where="status='done' AND created_at > '2024-05-01'" > output.csv，注意它导出的是 SQL 插入语句，如需 CSV，得配合 --tab 或管道过 sed/awk。
-
--tab会生成 .sql（建表语句）和 .txt（数据），后者是制表符分隔，可用sed 's/\t/,/g'简单转 CSV -
--where不支持子查询，复杂条件仍得靠视图或临时表前置 - 导出大表时加
--skip-extended-insert可提升导入兼容性，但会显著增大文件体积 - MySQL 8.0+ 支持
SELECT ... INTO DUMPFILE，但仅限单行二进制导出，无实用价值
最容易被忽略的点：字符集和换行符陷阱
导出含中文的 CSV 时，Excel 打开乱码？十有八九是没声明 UTF-8 BOM；字段含换行符导致 CSV 行数错乱？那是没做 REPLACE(col, '\n', ' ') 预处理。
- MySQL 默认连接字符集可能不是
utf8mb4，执行SET NAMES utf8mb4再查 - 用
INTO OUTFILE导出时，字段分隔符和行结束符必须显式指定：FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' - Excel 对 BOM 敏感：Python 写 CSV 时用
open(..., encoding='utf-8-sig')，不是utf-8 - NULL 值默认导出为空字符串，如需 \N 显式标识，加
ESCAPED BY ''并手动处理
