那么优化自然是要针对SQL中性能较差的部分进行优化，因而这部分我们先讲解如何分析其性能差异

Multiversion concurrency control (版本并发控制)：并发访问(读或写)数据库时，对正在事务内处理的数据做多版本的管理。以达到用来避免写操作的堵塞，从而引发读操作的并发问题。...

事务:数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；事务是一组不可再分割的操作集合（工作逻辑单元）; 典型事务场景(转账)：...

对于 SQL 语句的执行来说，定位 B-TREE 索引中的一条记录，是个举足轻重的能力。

本文大多数都整理自《死锁-何登成 - 管中窥豹——MySQL(InnoDB)死锁分析之道》

1.什么是刷脏2.刷脏的场景1.redolog日志满2.bufferpool满3.间歇性flush4.关闭实例flush3.刷脏频率跟什么参数有关？实时刷脏算法主要与如下参数有关：Innodb_io_capcity 是代表全力刷脏的速度Innodb_max_dirty_pages_pct ...

在我们使用锁的时候，有一个问题是需要注意和避免的，我们知道，排它锁有互斥的特性。一个事务或者说一个线程持有锁的时候，会阻止其他的线程获取锁，这个时候会造成阻塞等待，如果循环等待，会有可能造成死锁。...

由于 innodb_buffer_pool_size 和 query_cache_size 都是我手动配置的，所以这个差异报告让我立刻注意到了 innodb_ibuf_max_size

我注意到最后两项(内存消耗最大两项)，分别是 21.19G (22221844K/1024/1024) 和 7.44G (7801584K/1024/1024)怎么会有这么多的内存消耗呢~~非常奇怪!

一次巡检过程中发现数据库使用内存有些过量，innodb_buffer_pool_size 设置值为 20G ，但实际物理内存消耗为 37G ，总虚拟内存消耗达 42G ，直接导致监控报警，于是开启了一次内存使用探究之旅，整理出来和大家分享一下...