openrowset 不能直接读 excel，仅限本地 sql server（2016+）且需安装 access database engine、启用 ad hoc distributed queries，并限定 excel 文件位于服务器本地路径；azure sql 数据库完全不支持。
SQL Server 中 OPENROWSET 能否直接读 Excel？
不能，除非你用的是本地 SQL Server 实例，且 Excel 文件在数据库服务器本地磁盘上。Azure SQL 数据库完全不支持 OPENROWSET 读 Excel —— 这是硬性限制，不是配置问题。
常见错误是执行时抛出：Msg 7302, Level 16, State 1, Line X: Cannot create an instance of OLE DB provider "Microsoft.ACE.OLEDB.12.0"。原因很明确：Azure 环境禁用 OLE DB 提供程序，且 ACE 驱动本身不被托管环境允许。
- 仅限本地 SQL Server（2016+），需手动安装
Microsoft Access Database Engine（x64 版本） - SQL Server 实例必须启用
Ad Hoc Distributed Queries：sp_configure 'show advanced options', 1; RECONFIGURE; sp_configure 'Ad Hoc Distributed Queries', 1; RECONFIGURE; - Excel 文件路径必须是数据库服务器能访问的本地路径（如
C:\data\input.xlsx），网络路径或 UNC 路径会失败
为什么不用 BULK INSERT 导入 Excel？
BULK INSERT 只接受纯文本格式（如 CSV、TXT），它根本无法解析 .xlsx 或 .xls 的二进制结构。强行用它读 Excel 文件只会报错：Cannot bulk load because the file "xxx.xlsx" could not be opened. Operating system error code 2(The system cannot find the file specified.) —— 实际是格式不识别，不是文件找不到。
如果你坚持走存储过程路线，必须先让 Excel 变成 CSV：
- 用 PowerShell 或 Python 脚本预处理：调用
Convert-ExcelToCsv或pandas.read_excel().to_csv() - 确保 CSV 使用 UTF-8 编码、逗号分隔、双引号包裹含逗号/换行的字段
- 再用
BULK INSERT加FORMAT = 'CSV'（SQL Server 2017+）导入，否则需手写格式文件（.fmt）
存储过程中调用 xp_cmdshell 安全风险高吗？
极高。启用 xp_cmdshell 相当于给 SQL Server 进程赋予了操作系统 shell 权限。一旦 SQL 注入或账户泄露，攻击者可直接执行任意系统命令。
即使你只用它来调用 PowerShell -Command "Import-Excel ... | Export-Csv"，也等同于开放了一个远程代码执行入口。生产环境严禁开启，尤其在面向公网或多人共用的实例上。
- 替代方案：用外部调度器（如 Windows Task Scheduler + PowerShell）完成 Excel → CSV 转换，再由存储过程只负责
BULK INSERT - 若必须用存储过程触发转换，改用 CLR 存储过程（需
UNSAFE ASSEMBLY权限，同样危险，且 Azure SQL 不支持） - 更稳妥的做法是把 Excel 解析逻辑移出数据库——用应用层（Python/Node.js）读取、清洗、批量插入
真正适合生产的“存储过程导入”是什么样？
它其实不是“从 Excel 导入”，而是“从已清洗的临时表导入”。典型流程是：业务系统上传 Excel → 后端服务解析为 DataTable → 用 SqlBulkCopy 写入 SQL Server 的 staging 表 → 存储过程从 staging 表做校验、去重、转换后 INSERT INTO target_table SELECT ... FROM staging_table。
这个模式里，存储过程只承担数据整合逻辑，不碰文件 I/O。好处是：
- 完全规避驱动、权限、路径、编码等 Excel 解析陷阱
- 便于加事务控制、错误回滚、日志记录（比如
INSERT ... OUTPUT记录失败行） - 可复用同一套存储过程处理来自 API、CSV、甚至其他数据库的源数据
真正的难点从来不在“怎么读 Excel”，而在于字段类型推断不准、空值语义混乱、日期格式歧义、合并单元格破坏行列结构——这些必须在进入数据库前解决，而不是指望存储过程兜底。
