V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
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
t123yh
V2EX  ›  MySQL

MySQL count where xxx=yyy 这种如何优化?

  •  
  •   t123yh ·
    t123yh · 2016-11-06 08:53:36 +08:00 · 5558 次点击
    这是一个创建于 2941 天前的主题,其中的信息可能已经有所发展或是发生改变。
    比如 Online Judge 系统里面有很多道题目,每道题目有很多 submission ,而 submission 有几种结果,比如 Accepted , WrongAnswer ,用 int 存储。
    现在如果需要快速找出每道题目的 Accepted 提交数和 Accepted 人数(即 submission 对于 userid 去重),应该如何优化?
    16 条回复    2016-11-15 10:51:05 +08:00
    azh7138m
        1
    azh7138m  
       2016-11-06 09:18:30 +08:00 via Android   ❤️ 1
    COUNT(DISTINCT user_id) 不就很好吗?
    bazingaterry
        2
    bazingaterry  
       2016-11-06 09:59:38 +08:00 via iPhone
    单独开一个表记录一下?
    t123yh
        3
    t123yh  
    OP
       2016-11-06 11:06:40 +08:00 via Android
    @azh7138m 这样大量数据的时候不会很慢吗
    hxsf
        4
    hxsf  
       2016-11-06 11:27:38 +08:00 via iPhone
    select count 1 group by userid
    cjyang1128
        5
    cjyang1128  
       2016-11-06 11:59:04 +08:00
    这种类型的优化一般都是通过反范式,比如题目表里面单独开一个字段记录 accepted 人数和 accepted 提交数,更新的时候采用 select for update 上行锁进行更新。或者可以用其他的数据库实现这种类似的计数器操作,比如 Redis 或 HBase
    latyas
        6
    latyas  
       2016-11-06 12:40:58 +08:00
    @t123yh
    现在的问题是,要多快?现有的速度是否无法接受?
    如果还没达到量级建议暂时不要考虑优化问题,良结构的方案都会相对来说慢,但是如果不需要,还是不要放弃良好的结构比较好。

    @cjyang1128 计数器场景的话建议不要使用 select for update ,我们在这上面被坑出 shi 来了,不如直接用 REDIS 的 INC 操作。
    t123yh
        7
    t123yh  
    OP
       2016-11-06 13:25:09 +08:00 via Android
    @latyas 以后估计得有几万条吧。。
    latyas
        8
    latyas  
       2016-11-06 14:19:32 +08:00
    几万条都是小数据,没必要优化
    iyaozhen
        9
    iyaozhen  
       2016-11-06 14:21:55 +08:00 via Android
    @t123yh 等到了几百万再考虑吧。
    azh7138m
        10
    azh7138m  
       2016-11-06 20:35:50 +08:00
    @t123yh 讲道理, poj 这么多年也才千万提交,没遇到瓶颈不用提前优化的
    ZiLong
        11
    ZiLong  
       2016-11-07 11:12:17 +08:00
    @latyas @iyaozhen @azh7138m 我跟 lz 一样感兴趣这个问题,如果我们假设我们现在有了五百万条数据呢
    azh7138m
        12
    azh7138m  
       2016-11-07 11:18:57 +08:00 via Android
    @ZiLong 做张 ac 表,加个缓存。
    但这会遇到其他的问题,比如 rejudge 时,要重新统计下,还是要用 submit 表去算,其实也没啥,数据量真的很难多到数据库出现瓶颈
    ZiLong
        13
    ZiLong  
       2016-11-07 11:25:41 +08:00
    @azh7138m web 应用的瓶颈基本都在数据库上
    azh7138m
        14
    azh7138m  
       2016-11-07 11:40:34 +08:00 via Android
    @ZiLong 真的,你数据库出现瓶颈,是要笑出声的,一般网站哪来那么多用户
    cjyang1128
        15
    cjyang1128  
       2016-11-07 13:00:08 +08:00
    @latyas 是不是导致了死锁。。
    latyas
        16
    latyas  
       2016-11-15 10:51:05 +08:00
    @cjyang1128 是的,如果 select for update 语句放在一个比较大的事务里,经常会发生死锁 /
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1042 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 20:30 · PVG 04:30 · LAX 12:30 · JFK 15:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.