SQL Server存储过程无法真正生成.xlsx文件：OPENROWSET仅支持向现有Excel写入且依赖ACE驱动和权限，BCP只导出CSV文本，COM对象方案性能差且不稳定；推荐用外部工具（Python/SSIS）处理导出。
不能直接用 OPENROWSET 或 BCP 在存储过程中“生成 Excel 文件”——它们不支持 .xlsx 格式，且默认只输出 CSV/文本，强行套用容易导出乱码、公式失效、日期错位甚至权限报错。
OPENROWSET 写 Excel 为什么总报错 “Ad Hoc Distributed Queries”？
这是 SQL Server 默认禁用即席分布式查询导致的。启用它只是第一步，后面还有驱动、权限、格式三重坑：
-
sp_configure 'show advanced options', 1; RECONFIGURE;和sp_configure 'Ad Hoc Distributed Queries', 1; RECONFIGURE;必须成对执行，缺一不可 - 必须安装 Microsoft ACE OLEDB Provider（如
Microsoft.ACE.OLEDB.12.0或16.0），仅装 Office 不等于有这个驱动；64 位 SQL Server 必须配 64 位 ACE 驱动，否则报Cannot create an instance of OLE DB provider "Microsoft.ACE.OLEDB.12.0" -
OPENROWSET只能往已存在的 Excel 文件里追加或覆盖数据，且目标文件不能被 Excel 进程打开，否则报Cannot open database - 写入时字段类型全靠 Excel 自动推断，数字开头的字符串（如工号
00123）会丢前导零，时间字段可能变成数值（如45123）
BCP 导出看起来快，但根本不是 Excel 格式
BCP 是纯文本导出工具，输出的是带分隔符的平面文件（如 CSV、TXT），和 Excel 的二进制结构（.xlsx）完全无关。常见误操作和后果：
- 命令中写
queryout "D:\data.xlsx"—— 文件后缀是 .xlsx，但内容仍是 CSV，双击用 Excel 打开会提示“文件格式与扩展名不匹配”，点“是”才能看，且中文列名可能乱码 - 没加
-c -C 65001参数：默认 ANSI 编码，中文字段导出为???；-C 65001指定 UTF-8，但 Excel 2016+ 才原生识别 UTF-8 BOM，旧版仍需手动导入 - 没有预处理字段：含换行符、逗号、引号的字段不会自动加引号包裹，CSV 解析直接错行；
BCP不提供转义逻辑，得靠REPLACE()在 SQL 层手动处理 - 权限要求高：
BCP运行在 SQL Server 服务账户上下文，该账户必须对目标路径有写权限，而默认NT SERVICE\MSSQLSERVER对 D:\ 根目录无权写入
真正在存储过程中可控导出 Excel 的替代路径
如果硬要走 T-SQL 原生方案，且必须由存储过程触发，唯一较稳的方式是组合使用 sp_OACreate + Excel COM 对象（仅限 Windows + 服务端装 Office）：
- 必须开启 OLE Automation：
sp_configure 'Ole Automation Procedures', 1; RECONFIGURE;，且 SQL Server 服务账户需有桌面交互权限（通常得改服务登录为域账户） - Excel 启动后是隐藏进程，需显式调用
Application.Visible = False，否则服务器后台积压大量 Excel 实例卡死 - 每行写入都走 COM 调用，性能极差，1 万行以上就明显延迟；建议限制在 5000 行以内，且数据不含富文本、图表、合并单元格等
- 导出完必须显式调用
WorkBook.Close和Application.Quit，否则 Excel 进程残留，下次调用报Cannot create ActiveX component - 更现实的做法：把
BCP导出 CSV + PowerShell 脚本转 XLSX 封装成作业（SQL Agent Job），存储过程只负责发信号（如写控制表），避免在数据库线程里卡住
真正要导出结构完整、格式可控、支持大体量的 Excel，别在存储过程里硬扛——用 Python 脚本（pandas + openpyxl）或 SSIS 包才是正路。T-SQL 层只管把数据查出来，导出动作交给外部进程，边界清晰，也容易排查编码、权限、路径问题。
