Category: MySQL Theory & Solution

1. 背景 几年前我曾经服务过的一家电商公司，随着业务增长我们每天的订单量很快从30万单增长到了100万单，订单总量也突破了一亿。当时用的Mysql数据库。根据监控，我们的每秒最高订单量已经达到了2000笔（不包括秒杀，秒杀TPS已经上万了。秒杀我们有一套专门的解决方案，详见《秒杀系统设计～亿级用户》）。不过，直到此时，订单系统还是单库单表，幸好当时数据库服务器配置不错，我们的系统才能撑住这么大的压力。 业务量还在快速增长，再不重构系统早晚出大事，我们花了一天时间快速制定了重构方案。 重构？说这么高大上，不就是分库分表吗？的确，就是分库分表。不过除了分库分表，还包括管理端的解决方案，比如运营，客服和商务需要从多维度查询订单数据，分库分表后，怎么满足大家的需求？分库分表后，上线方案和数据不停机迁移方案都需要慎重考虑。为了保证系统稳定，还需要考虑相应的降级方案。

SQL连接图解演示-共七页   数据库底层数据结构与数据库索引类型 跳表，哈希索引，SSTable，LSM树，B树，倒排索引，R树，后缀树。   如果MySQL磁盘满了，会发生什么？还真被我遇到了！ 要进行磁盘碎片化整理。原因是datafree占据的空间太多，看看自己的系统的datafree大不大 show table status from 表名; 100G内存下，MySQL查询200G大表会OOM么？   MySQL中ORDER BY与LIMIT 不要一起用，有大坑 如果order by的列有相同的值时，mysql会随机选取这些行，为了保证每次都返回的顺序一致可以额外增加一个排序字段（比如：id），用两个字段来尽可能减少重复的概率。

MySQL 备份恢复（一） mysqldump MySQL 备份恢复（二） select …… into outfile MySQL 备份恢复（三） mydumper MySQL 备份恢复（四） XtraBackup  

    [转]解决线上数据库死锁

近一个多月，写了一些MySQL内核的文字，稍作总结，希望对大家有帮助。 1.《InnoDB，为何并发如此之高？》 文章介绍了： （1）什么是并发控制； （2）并发控制的常见方法：锁，数据多版本； （3）redo，undo，回滚段的实践； （4）InnoDB如何利用回滚段实现MVCC，实现快照读。 结论是，快照读(Snapshot Read)，这种不加锁的读，是InnoDB高并发的核心原因之一。 番外篇：《快照读，在RR和RC下的差异》 快照读，在可重复读与读提交两种事务隔离级别下，有微小的差异，文章通过案例做了简单叙述。