SQL Server存储过程中删除日志必须加WHERE条件和时间戳字段索引，否则将导致全表扫描和长时间锁表；应预计算截止时间变量、用TOP分批删除，并确保created_at有非聚集索引。
SQL Server 存储过程中用 DELETE + 时间戳删日志，必须加 WHERE 和索引
直接 DELETE FROM logs 没 WHERE 是灾难性操作，哪怕表名带 _log 也不代表安全。核心是靠时间戳字段（如 created_at、log_time）做边界判断，但光写条件不够。
常见错误现象：DELETE FROM logs WHERE created_at 看似合理，但如果 <code>created_at 没索引，每次执行都全表扫描，锁表十几秒甚至更久，线上写入直接卡死。
-
created_at字段必须建非聚集索引（或作为聚集索引的一部分），否则 DELETE 效率随数据量指数下降 - 别用
GETDATE()做计算主体——它每行都求值，改用DECLARE @cutoff DATETIME2 = DATEADD(day, -30, GETDATE())预先算好再引用 - 大表务必加
LIMIT类控制（SQL Server 用TOP (1000)）：DELETE TOP (1000) FROM logs WHERE created_at - 如果要清空整月分区（如
log_202503），优先走DROP TABLE而不是 DELETE，速度差两个数量级
MySQL 存储过程里 DATE_SUB 和 NOW() 的坑不能踩
MySQL 的事件或存储过程里写 WHERE created_at 很常见，但 <code>NOW() 在语句执行中不固化，遇到长事务可能被反复求值，导致同一批数据删多次或漏删。
正确做法是把阈值抽成变量，且注意单位语法：
- 必须用
CURRENT_TIMESTAMP或字面量，NOW()在CREATE EVENT的ON SCHEDULE里直接报错ERROR 1064 - 时间单位必须单数：
INTERVAL 1 HOUR合法，INTERVAL 1 HOURS语法错误 - 大表清理建议分批：先
SELECT id INTO TEMPORARY TABLE获取待删ID，再用DELETE ... WHERE id IN (...)分页删，避免事务过大 - 别依赖表名含日期（如
log_202503）来判断过期——表名可伪造，时间戳字段才可信
PostgreSQL 分区表删日志，不能只看表名匹配
很多团队给日志表按月分区并命名为 logs_202503，然后在存储过程里 IF relname ~ '^logs_\d{6}$' 就删，这极危险。PostgreSQL 中 pg_class.relname 不唯一，也没绑定分区逻辑。
真正安全的判定方式是结合元数据与边界解析：
- 查
pg_class时必须加AND relkind = 'r'，排除视图、索引、序列等干扰项 - 不能只靠表名推断时间范围，得用
pg_get_expr(relpartbound, oid)解析实际分区边界，比如确认log_time >= '2025-03-01' AND log_time - 执行
DROP TABLE前必须加IF EXISTS，否则并发清理时一个失败会中断整个流程 - 如果用
pg_cron调度，函数体里别写COMMIT—— pg_cron 自动在事务内执行，手动提交会报错
跨数据库统一清理逻辑，information_schema 元数据差异要硬处理
写一个“通用清理存储过程”跑在 SQL Server / MySQL / PostgreSQL 上？不现实。三者 information_schema 结构差异大，连“表是否存在”这种基础判断都要重写。
比如判断某张日志表是否还存在：
- SQL Server 查
sys.tables，用SCHEMA_ID('dbo')锁定 schema - MySQL 查
information_schema.TABLES，字段是TABLE_SCHEMA和TABLE_NAME，大小写敏感取决于配置 - PostgreSQL 查
pg_tables，但要注意schemaname可能是public或自定义，且pg_tables不包含分区子表 - 所有动态拼接的
DROP TABLE必须套QUOTENAME()（SQL Server）、CONCAT('`', table_name, '`')（MySQL）、quote_ident()（PostgreSQL），否则带中划线或中文的表名直接报错
最易被忽略的一点：SQL Server 的 sys.tables 默认不返回临时表，但 MySQL 的 information_schema.TABLES 会列出 TEMPORARY 表——如果没过滤 TABLE_TYPE = 'BASE TABLE'，可能误删开发用的临时日志表。
