链接
1.介绍
优化方面
2.如何定位慢查询
方案1：开源工具
追踪功能
方案2：Mysql自带慢日志
将慢sql记录到日志文件中
总结
生产一般不开启 损耗mysql性能
3.SQL执行慢-分析方法
获取查询语句信息
type字段
总结
4.索引概念+底层数据结构
B+树是B树的优化
2：是因为数据都在叶子节点，查找路径差不多所以稳定
3：双向指针连接，所以范围查询方便
5.聚簇索引，非聚簇索引，回表查询
回表查询（二次）
总结
单独给字段创建的索引，一般多个
6.覆盖索引，超大分页优化
基于二级索引
二级索引的叶子，一定会包含索引键 (name) + 主键 id
总结1
超大分页-覆盖索引+子查询优化
总结2
先分页查询获取表中的**id，**然后对表的id进行排序，能筛选出分页之后的id集合，
因为id是覆盖索引，操作id效率高，最后通过id集合去到原来的表中做关联查询
效率就可以得到提升
7.索引创建的原则
总结
一般是数据量大的基础上，然后还需要查询
三个复杂查询
联合索引
索引数量
8.索引失效情况
不满足最左前缀
不正常情况，只是命中name
范围索引右边的列使用索引
在'索引列'进行运算
字符串不加单引号
总结
最左前缀，模糊，范围，字符串计算和单引号
9.SQL优化经验
表设计的优化
SQL语句的优化
主从复制、读写分离
总结
事务相关
1.事务特性
2.并发事务带来的问题、隔离级别
并发事务带来的问题
这个幻读的情况 是在解决了不可重复读问题的情况下 就是可以重复读取了 且重复读取时一致的数据
假设表里只有 id=1、2 两个账户，事务 A 要统计余额 > 0 的账户总数：
- 事务 A 第一次执行：
SELECT * FROM account WHERE money > 0，查到 2 条数据；- 此时事务 B 新开事务，执行
INSERT INTO account(id,money) VALUES(3,1000)，并commit 提交；- 事务 A 没有结束，再次执行一模一样的
SELECT * FROM account WHERE money > 0，这次查到 3 条；事务 A 在同一个事务里，同样的查询语句，前后结果行数变多了，仿佛凭空多出一行，这就是幻读。
反向场景：事务 B 删除了一条符合条件的数据并提交，A 第二次查询少了一行，也属于幻读。
即：
- UPDATE 改已有行 → 不可重复读
- INSERT/DELETE 增减行 → 幻读
| 问题 | 操作对象 | 触发 SQL 类型 | 现象 |
|---|---|---|---|
| 不可重复读 | 已存在的单行数据 | 其他事务 UPDATE 更新 | 同一行的值前后不一样 |
| 幻读 | 整个范围的数据集 | 其他事务 INSERT/DELETE 增删行 | 查询到的总行数变多 / 变少，出现 / 消失新记录 |
解决以上问题：事务隔离
隔离级别
串行化是强制加锁串行执行解决所有并发问题，一般不用，性能差
总结
3.undo log和redo log区别
都是mysql的日志文件
redo log
内存操作完的数据没同步到磁盘，属于脏页，此时如果服务器宕机，会导致数据同步失败，内存的数据可能会消失，违背事务持久化的特性
mysql引入了undo log日志文件
机制：先写日志，延迟刷磁盘数据文件
undo log
总结
4.mvcc多版本并发控制
实现快照读，读不阻塞写、写不阻塞读 ，高并发性能强，同时解决脏读、不可重复读；配合间隙锁 在 RR 隔离级别消除幻读
主从同步原理
总结
分库分表
目前主库和从库存的数据一样，那此时是解决访问的压力，但读写分开来进行访问时解决不了海量数据存储的问题
分库分表策略
垂直拆分
就是按模块分
水平拆分
分摊单机压力,缩小单次检索的数据范围,路由规则很多
| 拆分类型 | 拆分依据 | 部署位置 | 表结构特点 | 核心解决问题 |
|---|---|---|---|---|
| 垂直分库 | 业务功能模块 | 多个独立数据库实例 | 各库存放不同种类 数据表 | 业务解耦，不同业务分摊服务器压力 |
| 水平分库 | 分片路由 （取模 / 范围 / 哈希等） | 多个独立数据库实例 | 各个库内部的表结构完全一致 | **突破单机数据库并发、**硬件瓶颈 |
| 垂直分表 | 字段冷热、字段大小 | 同一个数据库当中 | 拆分出多张字段不同的子表 | 单表字段过多 、大字段拖慢查询的问题 |
| 水平分表 | 分片路由（取模 / 范围 / 哈希等） | 同一个数据库当中 | 拆分出多张结构一致的子表 | 单张表行数太多、索引臃肿的问题 |
总结
