SQL存储过程迁移为Cassandra CQL：存储过程支持与变量设置方法

首先给明确结论：Cassandra原生不存在和SQL存储过程对等的服务端执行能力。

• 虽然Cassandra支持编写UDF（用户定义函数）、UDA（用户定义聚合），但这类能力仅支持单行计算、聚合计算的场景，完全不支持在服务端跑带循环、条件分支、多步操作的流程化逻辑
• CQL本质是声明式查询语言，没有内置的变量声明、流程控制、执行结果反馈（类似SQL的@@ROWCOUNT）这类存储过程核心能力，所有需要编排的流程都必须在外部应用/调度层实现，不能下沉到Cassandra服务端执行
• 原SQL里的DBCC CHECKIDENT（自增序列重置）、全局自增ID计数器这类机制，在Cassandra里没有对等实现：Cassandra一般靠应用侧生成时间UUID、雪花ID这类全局唯一主键，没有数据库层维护的自增计数，自然也不存在重置自增起点的操作概念

先对齐原存储过程的核心目标：清理指定回溯天数之前的旧交易日志，通过分批删除避免单一大规模操作造成集群抖动，同时处理ID值过大后的历史段清理问题。

前置表结构适配 #

Cassandra不支持无分区键的大范围扫描、范围查询，要实现按时间维度的高效清理，必须提前按时间做分区设计：

-- 交易日志表，按天做分区键，从结构上支持按时间批量清理
CREATE TABLE transaction_log (
    log_id timeuuid,
    log_time timestamp,
    log_content text,
    log_date_bucket date, -- 按天生成的分区值，比如'2024-05-20'
    PRIMARY KEY (log_date_bucket, log_id)
) WITH CLUSTERING ORDER BY (log_id DESC);

具体编排逻辑（全流程在外部应用/定时任务层实现） #

1. 变量设置
   CQL本身不支持声明变量，原存储过程里所有用到的参数（回溯天数p_daysback、每批删除数量5000、最大循环次数7、ID阈值10亿、待清理ID段5亿）全部在外部的调度代码里定义即可，举个简单的脚本变量示例：

   # 对应原SQL的DECLARE部分
   p_daysback = 30
   batch_delete_limit = 5000
   max_loop_times = 7
   deleted_count = 0
   billion_threshold = 1000000000
   

2. 计算清理边界
   原SQL需要查询早于指定天数的最大日志ID，在Cassandra的时间分区设计下，直接计算出早于回溯天数的所有日期桶即可作为清理边界，不需要额外查全局最大ID：

   -- 取回溯截止日期的桶值，所有早于这个值的分区都属于待清理范围
   SELECT log_id FROM transaction_log 
   WHERE log_date_bucket = '2024-04-20' -- 对应30天前的日期
   ORDER BY log_id ASC LIMIT 1; -- 拿到边界ID
   

3. 分批循环删除
   原SQL的DELETE TOP (5000)循环7次的逻辑，因为CQL本身不支持DELETE语句加行数限制，需要按下面的流程实现：
   • 每轮先查出符合删除条件的前5000条记录的主键
   • 拿到主键列表后执行批量删除
   • 统计本轮删除的实际行数，累加到总删除计数
   • 如果本轮删除行数为0、或者已经循环满7次，直接退出循环
     每轮对应的CQL示例：

   -- 第一步：查待删除的主键列表
   SELECT log_id FROM transaction_log 
   WHERE log_date_bucket < '2024-04-20'
   LIMIT 5000;
   
   -- 第二步：批量删除查到的所有主键
   BEGIN BATCH
   DELETE FROM transaction_log WHERE log_date_bucket = '2024-04-19' AND log_id = <id1>;
   DELETE FROM transaction_log WHERE log_date_bucket = '2024-04-19' AND log_id = <id2>;
   ... -- 把上一步查询到的所有主键拼接进批量操作
   APPLY BATCH;
   

4. 原逻辑里的ID重置段处理
   原SQL当日志ID超过10亿时，删除5亿以下旧ID、重置自增序列的逻辑，在Cassandra场景下需要做适配：
   • Cassandra没有数据库层面维护的自增ID，不存在需要RESEED的计数器，所以这部分的序列重置逻辑完全不需要在数据库侧执行，如果是应用侧维护的自增ID生成器，直接在生成服务里调整起始计数即可
   • 如果确实需要清理ID小于5亿的历史段数据，按照前面的分批删除逻辑操作即可

实操注意事项 #

• 严禁执行不带分区键的大范围DELETE操作：这类操作会造成全集群的墓碑积压，严重拖慢读性能，必须严格按照提前设计的时间分区做小批量删除
• 可以优先用TTL机制优化清理逻辑：如果业务上有明确的数据保留时长，建表时给每个分区设置对应保留时间的TTL，数据到期会自动过期删除，完全免去手动清理的流程，这也是Cassandra处理日志类数据的推荐方式

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