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 
这是一个创建于 3339 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如 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-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 语句放在一个比较大的事务里，经常会发生死锁 / |
Select Language