1
azh7138m 2016-11-06 09:18:30 +08:00 via Android 1
COUNT(DISTINCT user_id) 不就很好吗?
|
2
bazingaterry 2016-11-06 09:59:38 +08:00 via iPhone
单独开一个表记录一下?
|
4
hxsf 2016-11-06 11:27:38 +08:00 via iPhone
select count 1 group by userid
|
5
cjyang1128 2016-11-06 11:59:04 +08:00
这种类型的优化一般都是通过反范式,比如题目表里面单独开一个字段记录 accepted 人数和 accepted 提交数,更新的时候采用 select for update 上行锁进行更新。或者可以用其他的数据库实现这种类似的计数器操作,比如 Redis 或 HBase
|
6
latyas 2016-11-06 12:40:58 +08:00
@t123yh
现在的问题是,要多快?现有的速度是否无法接受? 如果还没达到量级建议暂时不要考虑优化问题,良结构的方案都会相对来说慢,但是如果不需要,还是不要放弃良好的结构比较好。 @cjyang1128 计数器场景的话建议不要使用 select for update ,我们在这上面被坑出 shi 来了,不如直接用 REDIS 的 INC 操作。 |
8
latyas 2016-11-06 14:19:32 +08:00
几万条都是小数据,没必要优化
|
11
ZiLong 2016-11-07 11:12:17 +08:00
|
12
azh7138m 2016-11-07 11:18:57 +08:00 via Android
@ZiLong 做张 ac 表,加个缓存。
但这会遇到其他的问题,比如 rejudge 时,要重新统计下,还是要用 submit 表去算,其实也没啥,数据量真的很难多到数据库出现瓶颈 |
15
cjyang1128 2016-11-07 13:00:08 +08:00
@latyas 是不是导致了死锁。。
|
16
latyas 2016-11-15 10:51:05 +08:00
@cjyang1128 是的,如果 select for update 语句放在一个比较大的事务里,经常会发生死锁 /
|