用 INSERT … ON DUPLICATE KEY UPDATE 实现幂等写入
消息队列重投、用户连点两次提交、定时任务因为上一次超时被重新调度——这些场景都会让同一条业务数据被写入两次。如果写入逻辑是「先 SELECT 判断存在再 INSERT」,在并发下会稳定地漏判:两个事务同时 SELECT 都没查到,然后都去 INSERT,最后要么产生两条脏数据,要么撞唯一索引报 Duplicate entry。把判断和写入压进一条 SQL,交
消息队列重投、用户连点两次提交、定时任务因为上一次超时被重新调度——这些场景都会让同一条业务数据被写入两次。如果写入逻辑是「先 SELECT 判断存在再 INSERT」,在并发下会稳定地漏判:两个事务同时 SELECT 都没查到,然后都去 INSERT,最后要么产生两条脏数据,要么撞唯一索引报 Duplicate entry。把判断和写入压进一条 SQL,交
一、为什么要用消息队列 三个核心价值:解…
一、为什么需要幂等 网络不可靠:客户端重…
树形评论的分页是论坛和社区类产品里最容易被低估的一块。表面需求是"一页显示 20 条评论",实际难点在于:评论是嵌套的,一条根评论下面可能挂着十几层回复,你既不能让某一层的子回复被分页切口拦腰截断,也不能因为要算好层级导致每次翻页都全表扫描。很多项目最后退化成一次性把整棵树的评论全部查出来丢给前端拼,帖子一火,接口就是几百毫秒起步,内存里堆着上万行 JSON
排行榜、Top N、分组取最新一条——这类需求用窗口函数写起来最舒服。但老代码里常见的是自连接或子查询写法,数据量一上来就慢到不可用。 一个典型场景 每门课程要取分数最高的前 3 名学生。自连接写法: SELECT s.* FROM sco