SQL定时DELETE任务失败应先确认是否执行，再查原因；重点排查Agent服务状态、执行权限、锁阻塞、超时设置及上下文差异，避免仅凭现象猜测。
SQL定时DELETE任务失败如何排查
直接看日志和执行状态，别猜。定时DELETE失败通常不是SQL写错了，而是环境、权限或锁在背后卡住——先确认它到底“有没有执行”，再查“为什么没成功”。常见现象包括：任务显示“已成功”但数据没删、作业状态停在“正在运行”不动、报错信息只显示“执行失败”没具体原因。
检查SQL Server Agent服务是否真正运行
SQL Server Agent是定时任务的调度引擎，它挂了，所有作业都只是摆设。不能只看服务管理器里显示“正在运行”，要验证它是否真在响应请求。
- 运行
SELECT servicename, status_desc FROM sys.dm_server_services WHERE servicename LIKE '%SQL Server Agent%'，返回必须是RUNNING，且last_startup_time不是很久以前的时间 - 如果状态是
STOPPED或PENDING_START，用 PowerShell 执行Start-Service -Name "SQLSERVERAGENT"启动；若启动失败，重点查错误代码 1069（多因服务账户密码过期或权限变更） - 代理服务图标在 SSMS 中灰色不可用？说明登录账户配置异常，不要用
NT AUTHORITY\LocalSystem，改用有SQLAgentUserRole的专用域账户
确认DELETE语句在作业中能否独立执行成功
把作业里的 @command 内容单独复制出来，在SSMS里用作业执行账户的身份运行一遍。很多失败根本不是定时问题，而是SQL本身就有隐患。
- 先执行
SELECT COUNT(*) FROM your_table WHERE create_time ，确认条件能命中数据——返回 0 就别删了，作业当然“成功”却无动作 - 检查
create_time字段是否有有效索引，EXPLAIN（或 SQL Server 的执行计划）里不能出现Clustered Index Scan；否则大表上 DELETE 会锁表几小时 - 避免在 WHERE 里用函数，比如
WHERE YEAR(create_time) = 2023或WHERE DATEDIFF(day, create_time, GETDATE()) > 30，这些都会让索引失效 - 如果语句含参数（如
EXEC sp_clean_logs @days = 30），确保存储过程里没漏掉SET NOCOUNT ON——某些客户端会把影响行数消息误判为错误中断
查锁、查阻塞、查超时
DELETE 卡住不返回，大概率是被别的会话锁住了。尤其在业务高峰期跑清理任务，很容易撞上未提交的事务或长查询。
- 运行
SELECT blocking_session_id, session_id, wait_type, wait_time, last_wait_type FROM sys.dm_exec_requests WHERE blocking_session_id 0，重点关注wait_type = 'LCK_M_X'或'LCK_M_U' - 对阻塞源会话，用
DBCC INPUTBUFFER(blocking_session_id)看它在跑什么，常是某个应用连接长期空闲但事务没提交 - 作业步骤里没设超时，默认是无限等待。编辑作业步骤时，在“高级”页手动填入
Timeout（单位秒），比如设成300（5分钟），避免一个卡死拖垮整条调度链 - 如果删的是分区表，确认没人在同时往该分区插数据——
DROP PARTITION需要 SCH-M 锁，和 INSERT/SELECT 全部互斥
权限与上下文容易被忽略的细节
作业默认以代理账户身份运行，但它的数据库上下文、默认架构、甚至 SET 选项，都可能和你在 SSMS 里手动执行时不一样。
- 作业步骤的
@database_name必须显式指定，不能依赖“当前库”。哪怕你是在msdb里建的作业，删的是AppDB的表，也得写清楚@database_name = N'AppDB' - 执行账户需在目标库中有
DELETE权限，不是db_owner就一定行——检查是否只授了SELECT，或者权限只给了dbo架构下的表，而实际表在log架构下 - 某些环境启用了
READ_COMMITTED_SNAPSHOT，但作业步骤里又显式写了SET TRANSACTION ISOLATION LEVEL SERIALIZABLE，会导致锁升级更激进，反而更容易超时 - 如果 DELETE 包含触发器逻辑，确认触发器没抛异常——作业不会自动捕获触发器里的错误，它就静默失败
最麻烦的往往不是语法或逻辑，而是作业账户看不见的上下文：它不知道你手动执行时用的是哪个库、哪个用户、哪个 SET 选项。每次改完配置，一定要用作业账户身份连上去，手工跑一遍命令，再扔进作业里。
