Closed sfindme closed 9 months ago
这是查询没过期，并且还有流量的用户 SELECT * FROM users WHERE useDays != 0 AND quota != 0
然后循环读取出来的用户执行：重置用户流量 UPDATE users SET download=0, upload=0 WHERE id=N
能不能改成直接，不加参数的重置流量。，这样执行时间感觉更快。全部用户都重置流量。 UPDATE users SET download=0, upload=0
假设因为如有有200+个trojan服务器，使用同一个数据库，那么就会在执行的一时间CPU暴增。 200个trojan都循环执行以上的操作大量的update操作，我看了，CPU瞬间就会飙到100%，持续执行结束。这样会短暂的连接中断。
当然类似的还有，每天0点查询过期的用户，并且循环设置流量为0的操作。 SELECT * FROM users WHERE quota != 0 可以改成 update users set quota=0,useDays=0 where expiryDate='前一天的日期'，因为0点执行的，前一天的都过期。，这样一条语句， 200个Trojan服务器，也就执行200次。
不知道大神这样写的，是否还有其他考虑呢。这个只是我的优化而已，200+个trojan服务器就会出现这样的 问题。
这是查询没过期，并且还有流量的用户 SELECT * FROM users WHERE useDays != 0 AND quota != 0
然后循环读取出来的用户执行：重置用户流量 UPDATE users SET download=0, upload=0 WHERE id=N
能不能改成直接，不加参数的重置流量。，这样执行时间感觉更快。全部用户都重置流量。 UPDATE users SET download=0, upload=0
假设因为如有有200+个trojan服务器，使用同一个数据库，那么就会在执行的一时间CPU暴增。 200个trojan都循环执行以上的操作大量的update操作，我看了，CPU瞬间就会飙到100%，持续执行结束。这样会短暂的连接中断。
当然类似的还有，每天0点查询过期的用户，并且循环设置流量为0的操作。 SELECT * FROM users WHERE quota != 0 可以改成 update users set quota=0,useDays=0 where expiryDate='前一天的日期'，因为0点执行的，前一天的都过期。，这样一条语句， 200个Trojan服务器，也就执行200次。
不知道大神这样写的，是否还有其他考虑呢。这个只是我的优化而已，200+个trojan服务器就会出现这样的 问题。