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

挖个坟 已经 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 前人的成果😅 也不知道是怎么变成这样的 开始叫我优化的时候没仔细看想着这还不简单 然而还隐藏了个下次递增... 能不能保证为连续数 这个得去验证一下 谢谢

#4 抱歉有点没看懂 这边实质上就是不停的更新 sort 只是多次执行之后可能会递增多次（像 6 楼说的那样）

#5 如果能在程序里计算也不会来问啦 毕竟程序计算前提就是取出数据

#6 @zlowly 就是会递增多次...试图通过一次 update 也只是尝试 实在不行就没办法了

#1 @joooooker21 当初我的第一反应也是这样 整个文件下来所有操作全是用 SQL 在 UPDATE 而现在只要求优化这一部分（能优化的话） 似乎起初是因为数据量太大不好一次性查出来再操作（怕内存炸掉）
#2 @MidGap 一组条件就调个百来次... 然后调用的地方还有 10 多组... 够多了吧

所以还有救吗 绑定了太多东西 指不定哪个忘了换就 gg 了...

让我想起最近看到 苦瓜那么苦是为了让其他生物不要吃它...

家里喜欢广合腐乳 挺下面的

redis 键名可以缩 数据库可真别缩写

再苦真别不舍得为住花钱，至少心情会好很多

@ryd994 #8 试过了 确实用上了...

@coolcoffee #2 那看来确实是这么个道理 而且如果对面站点使用了 Authorization 就无效了（ 5 楼也有提到）

@ryd994 #5 那为什么根据配置 使用 443 的话 HTTPS 网站也能代理访问呢...

就很讨厌之前的 "南极人 太南了" 南 nmd，还有就是现在的 "帮帮帮，作业帮"，其他看点有创意的还好吧，就怕恶心没意思还重复的

像我这边的急性子直接一个电话撩过来的