迁移至Azure SQL后如何使用BCP批量导出CSV并配置定时作业

Azure SQL Database是PaaS服务，原生封禁了xp_cmdshell，也没有本地文件系统访问权限，你原来本地SQL Server调用bcp写本地磁盘的逻辑没法直接平移，下面两个方案都是纯T-SQL实现，可以直接挂到Azure SQL弹性作业/自动化定时任务里跑，完全匹配你按日期导出CSV、上传到存储的需求。

这个方案全程用T-SQL实现，不需要部署额外的虚拟机或服务，导出的CSV直接落在Azure Blob/ADLS Gen2存储里，参数和你原来的bcp配置完全对齐。
前置要求：

• Azure SQL数据库层级为S3及以上（通用、业务关键、超大规模层级都支持，基础层不支持），数据库兼容性级别设为150+
• 提前创建好存储账户和目标容器，给Azure SQL逻辑服务器开系统托管标识，给标识授予目标存储容器的存储Blob数据参与者权限

一次性配置（只需要跑一次）：

• 创建数据库主密钥（如果库内已经建过可以跳过）

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '替换成你自己的强密码';

• 创建指向目标存储的外部数据源

CREATE EXTERNAL DATA SOURCE SalesBackupDS
WITH (
    LOCATION = 'https://替换成你的存储账户名.blob.core.windows.net/替换成你的备份容器名/',
    IDENTITY = 'Managed Identity'
);

• 创建和原bcp参数匹配的CSV文件格式

CREATE EXTERNAL FILE FORMAT BackupCsvFormat
WITH (
    FORMAT_TYPE = DELIMITEDTEXT,
    FORMAT_OPTIONS (
        FIELD_TERMINATOR = ',', -- 对应原bcp的-t","逗号分隔符
        STRING_DELIMITER = '"',
        ENCODING = 'UTF8', -- 对应原bcp的-C ACP参数，避免乱码
        ROW_TERMINATOR = '\n', -- 对应原bcp的-r\n换行符
        FIRST_ROW = 2 -- 设为2会自动导出表头，不需要表头就改成1
    )
);

定时作业里每次执行的导出逻辑，和你原来按日期命名文件的逻辑一致，用动态SQL拼接即可：

DECLARE @fileName NVARCHAR(100) = REPLACE(CONVERT(VARCHAR, GETDATE(), 106), ' ', '') + '.csv';
DECLARE @extTableName NVARCHAR(200) = N'ext_sales_backup_' + REPLACE(CONVERT(VARCHAR, GETDATE(), 106), ' ', '');
DECLARE @execSql NVARCHAR(MAX) = N'
CREATE EXTERNAL TABLE ' + @extTableName + '
WITH (
    LOCATION = ''' + @fileName + ''',
    DATA_SOURCE = SalesBackupDS,
    FILE_FORMAT = BackupCsvFormat
)
AS
SELECT * FROM dbo.sales; -- 这里可以换成自定义的导出查询，加WHERE条件筛选数据都可以
';
EXEC sp_executesql @execSql;

小提示：CETAS每次导出会生成独立的CSV文件，如果你需要覆盖旧文件，在作业里提前加逻辑删除对应的外部表和旧文件即可；用带日期的文件名就和你原来的备份逻辑完全一致，不存在重名问题。

如果你需要把CSV传到第三方存储、或者导出后要触发通知、同步等后续逻辑，可以用sp_invoke_external_rest_endpoint存储过程，纯T-SQL调用提前配置好的逻辑应用/Azure函数接口，把查询结果传过去生成CSV上传到目标位置：

-- 把待导出数据序列化成JSON传递
DECLARE @queryResult NVARCHAR(MAX) = (SELECT * FROM dbo.sales FOR JSON AUTO);
-- 调用接口完成CSV生成和上传
EXEC sp_invoke_external_rest_endpoint
    @url = '替换成你自己的逻辑应用/函数触发地址',
    @method = 'POST',
    @payload = @queryResult;

这个方案灵活性更高，不需要受存储类型的限制，所有逻辑都可以在接口侧自定义，数据库侧只需要负责传数据。

内容的提问来源于stack exchange，提问作者SAJID BHAT