存储过程中应避免使用 TRUNCATE 做条件清理，因其是 DDL 操作，不支持 WHERE、不可回滚（SQL Server/PostgreSQL 中隐式提交事务）、不触发 DELETE 触发器且跳过外键检查；安全的带参 DELETE 存储过程须包含事务控制、影响行数预检、参数化条件及语义化命名。
为什么不能在存储过程中用 TRUNCATE
TRUNCATE 是 DDL 操作，在多数数据库（如 SQL Server、PostgreSQL）中无法在事务内回滚，且不能出现在存储过程的某些上下文里——比如 SQL Server 中，TRUNCATE 会隐式提交当前事务，导致后续 ROLLBACK 失效；MySQL 虽允许，但不触发 DELETE 触发器，也跳过外键检查。更关键的是：TRUNCATE 不支持 WHERE，根本做不到“按条件清空”。所以，**存储过程中应避免使用 TRUNCATE 做条件清理**。
带参数的 DELETE 存储过程怎么写才安全
核心是把验证、执行、回滚控制全包进过程里，而不是只写一句 DELETE。以下要点必须落实：
- 开头加
SET XACT_ABORT ON（SQL Server）或显式BEGIN TRANSACTION，确保出错自动中断 - 删除前用
SELECT COUNT(*)统计影响行数，并用RAISERROR或PRINT输出，人工确认后再继续 - 参数命名要带语义，比如
@CutoffDate比@p1更易维护；对字符串条件用@Pattern并加LIKE验证逻辑 - 避免直接拼接 SQL 字符串，防止注入；所有条件都走参数化，例如
WHERE create_time
示例片段：
CREATE PROCEDURE DeleteOldLogs @DaysAgo INT
AS
BEGIN
SET XACT_ABORT ON;
DECLARE @Cutoff DATETIME = DATEADD(day, -@DaysAgo, GETDATE());
<pre class='brush:php;toolbar:false;'>-- 先查数量
SELECT COUNT(*) AS AffectedRows FROM logs WHERE created_at < @Cutoff;
-- 确认后执行
DELETE FROM logs WHERE created_at < @Cutoff;END
大表批量删除卡死或锁超时怎么办
单次删几十万行容易锁表、占日志、拖慢业务。必须分批，但不能靠应用层循环调用——那会暴露事务边界、增加网络开销。正确做法是在存储过程内用 WHILE + TOP 控制每批数量：
- SQL Server：用
DELETE TOP (5000)+@@ROWCOUNT > 0循环 - 避免
ORDER BY在DELETE TOP中（性能差），改用主键范围推进，比如WHERE id BETWEEN @start AND @end - 每批后加
WAITFOR DELAY '00:00:00.1'让出资源，降低阻塞概率 - 注意日志增长：简单恢复模式下，大事务仍可能撑爆日志文件
真正危险的不是删得慢，而是删到一半失败又没回滚机制——所以分批逻辑必须包裹在事务内，或至少每批独立事务并捕获错误。
外键约束和触发器容易被忽略
很多人测试时用单表跑通就上线，结果生产环境删主表时被子表外键拦住，或触发器悄悄改了其他表数据。必须提前检查：
- 用
sp_fkeys 'YourTable'（SQL Server）查依赖的外键关系 - 删之前加
SELECT * FROM sys.triggers WHERE parent_id = OBJECT_ID('YourTable')看是否有DELETE触发器 - 如果存在级联动作，确认是否符合预期；否则临时禁用（
DISABLE TRIGGER）并记录操作依据 - 特别注意：有些触发器会写审计日志表，若该表也受外键约束，可能形成死锁
最隐蔽的问题是：你以为只删 A 表，但触发器顺手把 B 表某字段置 NULL，而 B 表该字段有 NOT NULL 约束——这时语句直接报错，且错误信息不提示触发器来源。
