CMUG第9期那些年优化踩过的坑v2.0.pdfVIP

那些年优化踩过的坑 2015年5⽉ 肖鹏@SINA “站的⾼，看的远，是因为掉的坑⾜够多了。” –by 匿名 案例分析 ⺫录 • 微博博⽂库设计优化 • QC的悲剧 • batch insert优化 • 反范式设计 • ⼤分⻚的优化 • 计数器优化 • feed架构优化 微博博⽂库设计 • 业务需求：存储微博博⽂内容 • 业务特点：持续写⼊，数据不可删除 • 访问特点：主键查询 最初的结构 单端⼝ 单库 单表 M S S S S S 现在的结构 M M 分⽚8套 S S S S • 8端⼝，每个端⼝4个库，表先Hash后⽇期 经验教训 • 单表拆多表费时费⼒费成本，pre sharding • 容量稳定增⻓的，pre sharding • 预估会是⼤业务的，先垂直后⽔平 适当过度设计 • 有时间属性的，尽量按照⽇期建表 ⺫录 • 微博博⽂库设计优化 • QC的悲剧 • batch insert优化 • 反范式设计 • ⼤分⻚的优化 • 计数器优化 • feed架构优化 Query Cache • 运⾏相同的SQL ，会直接从缓存中返回结果。 看上去很美， 实际呢？ 悲剧 select wait for qc lock upd/del/ins check qc for query + wait for qc lock = check permissions flush qc send data • 满屏的 “waiting for query cache lock” 经验教训 • 默认关闭QC • 根据特殊场景单独开启 • 针对QC单独监控 ⺫录 • 微博博⽂库设计优化 • QC的悲剧 • batc