mysql调优

索引

索引是帮助mysql 高效获取数据的排好序的数据结构
红黑树就是平衡二叉树，mysql 不同红黑树 是因为树太高了
b树 存储更多的索引元素 在树高度可控制的前提下 存储更多数据（多路搜索）
b+树 非叶子节点不存储data 只存储第一个叶子节点数据的索引（冗余）
叶子节点包含所有索引字段，叶子节点用指针连接
查找过程折半查找，进行一次I/O
hash 一维数组加二维链表 虽然效率高但是几乎不用hash hash 仅能满足= in 不支持范围查询

b树与b+树区别

叶子节点没有双向指针，查询范围不能连续
b树没有冗余索引 b+树有

存储引擎

存储引擎形容数据库表的 表结构 存储引擎 索引等存储在data 目录下
用的比较多的 InnoDB 索引和数据都放在ibd 文件中 叶节点放data 所在行的其他列数据
聚集索引 叶子节点包含了完整的数据记录 非聚集索引是索引和数据没有存放在一起就是非聚集的 一般情况下聚集索引查询会快一点

为什么推荐使用自增整数主键

如果innoDB 如果找不到主键索引那么就去找一列唯一的 来构建B+树，如果找不到唯一的会帮你维护一个隐藏了rowid,自己键主键的话 节省了mysql 的维护，提高性能，整形数字更容易比较，比较大小快。使用自增是为了防止 叶子节点满了 插不进去了 导致叶子分裂 所以我们保证一直往后面插入

联合索引

尽可能合并为联合索引，不要建太多单值索引，联合索引会按照多个字段依次排序，如果第一个大则优先，如果第一个相同看第二个（最左前缀）因为存储的时候是按照多个字段依次排序的，如果查找时不用最左前缀原则，则相当于给所有全查一遍 所以效率低

explain 命令 key 有值则走索引

事务

一组操作要么全部成功，要么全部失败。目的是为了保证数据最终的一致性
原子性（Atomicity）:当前事物的操作要么同时成功，要么同时失败。原子性由undo log日志来保证。
一致性（Consistency）:使用事务的最终目的，有业务代码正确逻辑保证。
隔离性（lsolation）:在事务并发执行时，他们内部的操作不能互相干扰。一条更新操作新更新内存bufferpool 然后写redo日志 真实的ibd数据会随机去刷新真实数据 如果现在mysql 宕机了，重启后会从redo日志中再加载
四种隔离级别：级别越高事务隔离性越好，但性能越低，隔离性是由mysql 各种锁和MVCC机制（多版本并发控制机制）实现的。
read uncommit(读未提交)：有脏读问题 读到未提交的数据
read commiy(读已提交)：有不可重复读问题 提交后的数据才能被读到 在一个事务内读到同一个数据可能不一样
repeatable read（可重复读）：有幻读问题 mysql默认 在一个事务内读到同一个数据是一样都以第一次读到的数据库结果为结果（快照） 但是有可能事务在执行过程中 另一个事务已经将数据修改而在该事务中读到的仍然是快照中的结果 copyonwrite 机制 更新的时候复制一份拿出来更新，更新完后替换原 可能读到旧数据
serializable(串行)： 上面问题全部解决 有事务时 另一个事务阻塞 当事务提交 另一个事务才进行
持久性（Durability）:一旦提交了事务。它对数据库的改变就应该是永久性的，持久性由redo log日志来保证。

锁

读锁：读锁是共享的，多个事务可以同时读取同一个资源，但是不允许其他事务修改 串行相当于对读操作加了一把读锁。
写锁：写锁是排他的，会阻塞其他的写锁和读锁，增删改都会加写锁。
lock in share mode

乐观锁和悲观锁解决rr 和rc 的问题
乐观锁 where version
悲观锁 set a=a+1 带锁的都不会读快照数据

MVCC多版本控制并发

读和写高并发可行 undo日志形成记录版本链 实现原理copy on write

查询操作方法需要用事务嘛？

分场景
如果查询方法只有一条语句 不需要
如果有多条 如果是rr是需要事务的，如果不添加事务的话，可能同一时刻库中数据不一致 时间维度点不一致 如果是rc 则不要事务 需要保证一致性的选择rr

长事务影响

并发情况下，数据库连接池容易满
锁定太多数据，造成大量的阻塞和锁超时
执行时间长，容易造成主从延迟
回滚所需要的时间比较长
undo log膨胀
容易导致死锁

长事务的优化

将查询等数据准备操作放到事务外
食物中避免远程调用，远程调用设置超时，防止事务等待时间太久
食物中避免一次性处理太多数据，可以拆分成多个事务分次处理
更新等设计枷锁的操作尽可能放在事务靠后的位置
能异步处理的尽量异步处理
用用测业务代码保证数据的一致性，非实物执行