安装好Docker，然后执行下面的脚本。
> docker run -d --name imysql --network=host \
-v /home/work/volumes/mysql/my.cnf:/etc/my.cnf \
-v /home/work/volumes/mysql/init:/docker-entrypoint-initdb.d/ \
-e MYSQL_ROOT_PASSWORD=123456 \
-e MYSQL_ROOT_HOST=% \
-e TZ=Asia/Shanghai \
-p 3306:3306 \
--privileged=true \
mysql:8.0.37一家互联网公司的UC（User Center）系统，千万级注册用户，百万级DAU，暂时没有分库分表，所有的用户数据都在一张大表中。
UC会结合营销系统，依据某些设置条件作出筛选，然后给符合条件的用户推送消息，有时候筛选出来的数据量特别大，导致服务器性能急剧下降。
现在需要对这个UC系统的SQL查询做一些优化，提升服务器性能，下面是筛选用户的SQL语句。
> SELECT userid, type FROM user_auth WHERE userid IN (SELECT id FROM user WHERE age BETWEEN 26 AND 33);不管是单表关联还是多表关联，对于SQL查询优化器来说，其实都是有多种执行计划可供选择的，那么如何能够保证MySQL选择一个成本最低，效率最佳的执行计划呢？
但问题是，怎么确定成本呢？
MySQL首先会对查询计算一个全表扫描的成本，计算方法如下。
开发一个系统的时候，一般都是设计好表结构，然后通过代码进行CRUD操作，再根据实际场景创建主联合索引或辅助联合索引，但如果查询当中遇到了问题，该怎么知道问题出在了哪里呢？
这就需要了解MySQL对查询语句的执行计划分析和对SQL的优化措施了，这也属于开发工程师需要掌握的一个必备技能。
其实设计良好的索引本身就属于一种SQL优化的技巧，但SQL优化的技巧并不仅仅只包含索引优化，还有很多其他东西。
在设计完表结构之后，不用马上就加索引，因为此时根本不知道会经常查询哪些数据，也就不知道怎么加索引合适。
当系统差不多开发完毕了，功能都跑通了，就可以考虑该如何创建索引了。
设计索引的第一条原则：针对SQL查询语句中的WHERE条件子句、ORDER BY排序子句和GROUP BY分组子句中出现的字段设计索引。
尽量利用联合索引，联合索引尽量包含WHERE、ORDER BY和GROUP BY中出现的字段，而且遵循最左列匹配原则、等值匹配原则和范围匹配原则。
InnoDB存储引擎通过聚簇索引和二级索引实现对索引页、数据页和数据行的管理，搜索时根据不同的索引来查找主键或非主键字段值，通过页分裂实现对数据页的扩展。
但刚创建的一张新表，是没有这么复杂的结构的，甚至可能只有一个数据页。
这个初始数据页可以称为原始页/根页，其内部就有一个页目录，直接通过主键来查找会非常快。
当数据不断插入，根页无法存储更多数据时，就通过页分裂创建一个新数据页，同时根据主键值大小进行排序挪动，新数据页的最小主键值一定要大于原始页的最大主键值。
数据库中所有的数据，最终都是要存放到磁盘上的，而对应的磁盘文件，对于数据库管理系统RDBMS来说，其实都是一个个数据页的集合。
数据页是按顺序一页页存放的，相邻的数据页之间会采取双向链表的形式相互引用。在数据页内部会存储一行行的数据，每一行数据都会按照主键大小进行排序存储，每一行数据都有指针指向下一行数据的位置，数据行之间组成单向链表。
在了解Buffer pool、redo log、LRU/flush、undo log、ReadView、MVCC、行锁、表锁等机制后，需要通过案例来说明问题了。
性能抖动的根本原因可能有两点。
buffer pool缓存页已满，当遇到大批量查询时，瞬间要把大量缓存页刷入磁盘，导致执行阻塞。
redo log被磁盘文件写满，且等待flush操作，无法处理任何新的请求，必须等刷完磁盘才能继续执行。