sockball07

@youthfire #4 为什么不平齐高一些就会容易干眼呢

如果还记得改了哪些文件 本地历史还能救回一些

挖个坟 已经 1 个月多了 还是能正常收发件 应该不只有我一个吧
但是还是不敢继续使用

我就说一句以前没感受到的 在垃圾项目里面才发现 php 数组这玩意就是个黑箱 还到处传这传那 里面到底有什么根本就不知道

@flyhelan #54 刚好也直接 google 了一下 1000000007 https://www.zhihu.com/question/49374703

借楼问问 这种漏洞 要研发背锅的吗

刚好我也想问 把这些常数条件和常数值用 UNION 连接起来 再和待更新的表 JOIN 一下再更新对应的值 哪个快

大概长这样
UPDATE table main, { union } tmp
SET main.status = tmp.status
WHERE main.id = tmp.id

#16 @zheng96 和我优化另外 2 个的思路很像（一个也是 UNION ALL 固定数据，一个也是使用多个临时变量）像是一个结合体 应该是可行的 （还是很像一种循环

要指出的一个错误是 你的 @b 在没有初始化的情况下始终为 NULL 而 NULL 不能与任何类型作比较 于是执行 IF(@b != t.id, @a := 0, 0)的时候永远会是 FALSE 的逻辑

另外要提醒的是 IF(@b != t.id, @a := 0, 0) 为 TRUE 的逻辑中是一个赋值表达式 最终返回为 NULL

#8 @feigle 10 楼解释了 因为前一次 update 可能会满足下一次的条件...

#9 @zheng96 应该不对 第一次大于 1 的 更新以后是满足下一组条件的...

#10 @nuanshen 前人的成果😅 也不知道是怎么变成这样的 开始叫我优化的时候没仔细看想着这还不简单 然而还隐藏了个下次递增... 能不能保证为连续数 这个得去验证一下 谢谢