› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 3376 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如 Online Judge 系统里面有很多道题目，每道题目有很多 submission ，而 submission 有几种结果，比如 Accepted ， WrongAnswer ，用 int 存储。
现在如果需要快速找出每道题目的 Accepted 提交数和 Accepted 人数（即 submission 对于 userid 去重），应该如何优化？
现在如果需要快速找出每道题目的 Accepted 提交数和 Accepted 人数（即 submission 对于 userid 去重），应该如何优化？
16 条回复 • 2016-11-15 10:51:05 +08:00
 |
1
azh7138m 2016 年 11 月 6 日 via Android  1
COUNT(DISTINCT user_id) 不就很好吗？
|
 |
2
bazingaterry 2016 年 11 月 6 日 via iPhone
单独开一个表记录一下？
|
 |
4
hxsf 2016 年 11 月 6 日 via iPhone
select count 1 group by userid
|
 |
5
cjyang1128 2016 年 11 月 6 日
这种类型的优化一般都是通过反范式，比如题目表里面单独开一个字段记录 accepted 人数和 accepted 提交数，更新的时候采用 select for update 上行锁进行更新。或者可以用其他的数据库实现这种类似的计数器操作，比如 Redis 或 HBase
|
 |
6
latyas 2016 年 11 月 6 日
@t123yh
现在的问题是，要多快？现有的速度是否无法接受？ 如果还没达到量级建议暂时不要考虑优化问题，良结构的方案都会相对来说慢，但是如果不需要，还是不要放弃良好的结构比较好。 @cjyang1128 计数器场景的话建议不要使用 select for update ，我们在这上面被坑出 shi 来了，不如直接用 REDIS 的 INC 操作。 |
|
8
latyas 2016 年 11 月 6 日
几万条都是小数据，没必要优化
|
|
12
azh7138m 2016 年 11 月 7 日 via Android
@ZiLong 做张 ac 表，加个缓存。
但这会遇到其他的问题，比如 rejudge 时，要重新统计下，还是要用 submit 表去算，其实也没啥，数据量真的很难多到数据库出现瓶颈 |
|
15
cjyang1128 2016 年 11 月 7 日
@latyas 是不是导致了死锁。。
|
|
16
latyas 2016 年 11 月 15 日
@cjyang1128 是的，如果 select for update 语句放在一个比较大的事务里，经常会发生死锁 /
|
Select Language