本系列包含后端优化场景相关的技术文档和学习笔记。

性能调优

📎高性能mysql第三版.pdf

explain 查看执行计划

(十七)SQL优化篇：如何成为一位写优质SQL语句的绝顶高手！ - 掘金

索引

• 索引是数据的目录
• 索引和数据存储在存储引擎中

• 查询优化器可以使用索引来快速定位数据，而不必针对给定查询扫描表中的每一行
• 但是需要额外的写入和存储来维护索引

索引分类

• 按「数据结构」分类：B+tree索引、Hash索引、Full-text索引。

• 按「物理存储」分类：聚簇索引（主键索引）、二级索引（辅助索引）。

• 按「字段特性」分类：主键索引、唯一索引、普通索引、前缀索引。

• 按「字段个数」分类：单列索引、联合索引。

• 每一种存储引擎支持的索引类型不一定相同

• MySQL 5.5 后 InnoDB 成为默认存储引擎，同时也支持选择 MyISAM、Memory 等引擎

锁

MySQL 有哪些锁？

根据加锁的范围，可以分为 全局锁、表级锁和行锁 三类。

• 全局锁： FTWRL
• 表级锁：表锁、元数据锁、意向锁、AUTO-INC 锁
• 行级锁：Record Lock、Gap Lock、Next-key Lock

全局锁

全局锁用法

要使用全局锁，则要执行这条命令：

sql 执行顺序

执行顺序

1. 先执行 from、join 来确定表之间的连接关系，得到初步数据
2. where 对数据进行初步的筛选
3. group by 分组
4. 各组分别执行 having 中的普通筛选或聚合函数的筛选
5. 再把根据我们要的的数据进行 select，可以是普通字段查询也可以是获取聚合函数的查询结果。 如果是聚合函数，select 的查询结果会增加一条字段
6. 将查询结果去重 distinct
7. 最后合并各组的查询结果，按照 order by 的条件进行排序

压缩列表

压缩列表是什么

• 压缩列表：排列紧凑的列表
• 压缩列表在 redis 中有两种编码形式
• ziplist
• listpack：5.0 引入，直到 7.0 完全取代 ziplist，成为 ziplist 的进阶版本

解决什么问题

压缩列表是 list 的底层数据结构，压缩列表作为底层数据结构能提供紧凑型的数据存储方式，能节约内存（节省链表指针的开销），小数据量时遍历访问性能好（连续+缓存命中率高）

对象过期时间

是什么

redis 的过期时间是给一个 key 指定一个时间点，等达到这个时间，数据就被认为是过期数据，由 redis 进行回收

为什么要过期

• 如果不是需要常驻的数据，设置过去时间可以有效节约内存。
• 有些场景也是需要过期时间支持：缓存
• 如果存在时间过久，可能导致和数据源差距过大，而设置过期时间，可以很方便清除缓存以便后续再次加载进去
• 比如分布式锁：需要一定时间后，数据自动消失，以实现最大占据时间的特性

跳表

是什么

• 跳表是有序集合 zset 底层数据结构，也是 zset 的灵魂所在。
• 跳表本质还是链表

• 虽然链表结构简单清晰，但是查询某个节点的效率比较低，为了调高查找性能，引入了跳表。
• 跳表在链表基础上，给链表增加了多级索引，通过索引可以一次实现多个节点的跳跃，调高性能

跳表的结构

redis 单线程为什么这么快

快的 4 点原因

1. 基于内存设计，内存的读写速度对比磁盘和固态都快，有更高的吞吐量和低延迟。
2. 单线程，因为执行本身不是瓶颈。对比多线程，从投入产生来看，引入多线程要付出更大的时间复杂度：上下文切换，同步机制的开销等等成本很高。事实也证明单纯性的 redis 已经很高效。瓶颈通常在网络 IO。
3. IO 多路复用
4. 高效的底层数据结构

redis 单线程

redis 使用单线程，能达到每秒数万级别的处理能力

redis 单线程还是多线程

结论

• 核心处理逻辑：redis 一直都是单线程，4.0 后对使用多线程处理异步删除的操作。
• 辅助模块：复制模块、某些异步流程、网络 IO 解包 6.0 后用的多线程

为什么选择单线程

官方

[图片下载失败]

• reids 的定位是内存的 k-v 存储，做的就是短平快的热点数据处理
• 一般来说执行会很快，执行本身不应该成为瓶颈，而瓶颈通常在网络 IO，所以处理逻辑使用多线程不会有太多收益
• 同时引入 多线程带来的复杂度远比现象的大