在上一篇文章中，我提到MySQL对自增主键锁做了优化，尽量在申请到自增id以后，就释放自增锁。 因此，insert语句是一个很轻量的操作。不过，这个结论对于“普通的insert语句”才有效。也就是说，还有些insert语句是属于“特殊情况”

在第4篇文章中，我们提到过自增主键，由于自增主键可以让主键索引尽量地保持递增顺序插入，避免了页分裂（为了保证索引叶子下面元素的有序性，有时候会执行插入操作，如果是插入页之间会发生页分裂腾出空间），因此索引更紧凑。 之前我见过有的业务设计依赖

在第16和第34篇文章中，我分别和你介绍了sort buffer、内存临时表和join buffer。这三个数据结构都是用来存放语句执行过程中的中间数据，以辅助SQL语句的执行的。其中，我们在排序的时候用到了sort buffer，在使用j

在上一篇文章中，我和你介绍了join语句的两种算法，分别是Index Nested-Loop Join(NLJ)和Block Nested-Loop Join(BNL)。 我们发现在使用NLJ算法的时候，其实效果还是不错的，比通过应用层拆分

在实际生产中，关于join语句使用的问题，一般会集中在以下两类： 我们DBA不让使用join，使用join有什么问题呢？ 如果有两个大小不同的表做join，应该用哪个表做驱动表呢？ 今天这篇文章，我就先跟你说说join语句到底是怎么执行

我经常会被问到这样一个问题：我的主机内存只有100G，现在要对一个200G的大表做全表扫描，会不会把数据库主机的内存用光了？ 这个问题确实值得担心，被系统OOM（out of memory）可不是闹着玩的。但是，反过来想想，逻辑备份的时候，

在MySQL中有两个kill命令： 一个是kill query +线程id，表示终止这个线程中正在执行的语句 一个是kill connection +线程id，这里connection可缺省，表示断开这个线程的连接，当然如果这个线程有语句

今天这篇文章，我会继续和你介绍在业务高峰期临时提升性能的方法。从文章标题“MySQL是怎么保证数据不丢的？”，你就可以看出来，今天我和你介绍的方法，跟数据的可靠性有关。 在专栏前面文章和答疑篇中，我都着重介绍了WAL机制（你可以再回顾下第2

不知道你在实际运维过程中有没有碰到这样的情景：业务高峰期，生产环境的MySQL压力太大，没法正常响应，需要短期内、临时性地提升一些性能。 我以前做业务护航的时候，就偶尔会碰上这种场景。用户的开发负责人说，不管你用什么方案，让业务先跑起来再说