mysql 高可用9

再分享一下 之前MySQL优化相关的case

Query cache
MySQL内置的查询加速缓存
理念是好的,但设计不够合理，有点out
锁的粒度非常大MySQL 5.6默认已经关闭
When the query cache helps, it can help a lot. When it hurts, it can hurt a lot.
明显前半句已经没有太大用处
在高并发下非常容易遇到瓶颈

关于事务隔离级别 ，InnoDB默认隔离级别是可重复读级别
当然InnoDB虽然是设置的可重复读，但是也是解决了幻读的
建议改成读已提交级别，可以满足大多数场景需求
有利于更高的并发
修改transaction-isolation

上图是一个比较经典的死锁case，有兴趣可以测试下

关于SSD，还是提一下吧
某知名大V说过“最近10年对数据库性能影响最大的是闪存”
稳定性和性能可靠性已经得到大规模验证
多块SATA SSD做Raid5，推荐使用
采用PCIe SSD
主流云平台都提供SSD云硬盘支持

最后说一下大家关注的60亿表问题
表里数据也是微博线上比较核心的
先说下当时情况
表结构比较简单，都是bigint这种整型
索引比较多，应该有2-3个
单表行数60亿＋
单表容量1.2TB左右，当然内部肯定是有碎片的

形成原因：历史遗留问题
按照我们前面讲的开发规范，这个应该早拆分了
当然不拆有几个原因：1.性能未遇到瓶颈   ，主要原因  2. DBA比较“懒“
3.想看看InnoDB的极限，挑战一下

不过风险也是很大的，想想如果在一个1.2TB表上加个字段加个索引，那感觉 绝对酸爽。还有就是单表恢复的问题，恢复时间不可控