MySQL

操作都成功或者都不成功

原子性

操作都成功或者不成功数据要保持一直

一致性

每个会话都有自己独立的环境不受其他会话的影响

隔离性

操作完的数据储存在磁盘上

持久性

t1会话的数据被t2修改了根本没写在磁盘上

脏写

读到未提交的数据

脏读

读到已提交的数据

不可重复读

自己读的数据被被人修改了，在innoDB可重复读的级别被mvcc机制解决了，但是解决不了自己读-写的幻读

幻读

事务并发问题

读已提交

读未提交

可重复读

通过读也加锁的方式解决所有问题

串行化

隔离级别

undo日志

read-view试图

mvcc

事务

表锁

行锁

间隙锁gap-lock

行锁+间隙锁

临键锁(Next-key Locks)

锁

innoDB执行的过程

事务与锁

分库分表

非叶子节点放上去冗余主键（或索引）叶子节点放上主键和data数据或者是索引和主键

b+tree

如果是mongodb非关系型，内存行数据库当然选择b-tree，b+tree的冗余索引对它来说放到内存中是一种负担

为什么不用b-tree

索引结构

最左前缀原则

小表（指结果集小的表）驱动大表

尽量查询都覆盖索引

因为你不建立主键MySQL会找列中找一个不重复的做主键如果没有他会隐藏列做一个主键

建立主键唯一约束

如果不需要太多字段的查询可以尽量在索引覆盖（using index）上查询

t1表有索引的时候EXPLAIN select * from t1 inner join t2 on t1.a= t2.a;

将t2的表拿出数据一行一行比较t1表，总共磁盘iot2全部，t1扫描t2的全部所以一共是2倍的t2次

nlj（nested-loop join）算法

t1无索引的时候

将t2拿到join buffer(那么1024字节)内存中比较，内存次数就是t2*t1次，然后join buffer不够就会分段去拿再次比较t1所以会多次磁盘io拿t1

因为走了就是t1*t2次磁盘io相比较内存比较的方式效率大大降低

为什么不走npj算法

bnl(block nested-loop join)算法

底层算法导致的

最好都建立索引

join优化也是优化子查询语句一旦出现性能问题不好处理

join数量不要超过3个

因为java集群，多线程，中间件等等很容易扩展，MySQL一旦出现性能问题难以扩展

java可以分担查询的任务

join查询

原则

索引优化

索引

配置binlog

1 mysql> show variables like '%log_bin%'; 查看bin-log是否开启222 mysql> flush logs; 会多一个最新的bin-log日志3 mysql> show master status; 查看最后一个bin-log日志的相关信息4 mysql> reset master; 清空所有的bin-log日志

恢复命令

从bin-log恢复数据1恢复全部数据/usr/local/mysql/bin/mysqlbinlog --no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001 |mysql -uroot -p tuling(数据库名)2恢复指定位置数据/usr/local/mysql/bin/mysqlbinlog --no-defaults --start-position=\"408\" --stop-position=\"731\"  /usr/local/mysql/data/binlog/mysql-bin.000001 |mysql -uroot -p tuling(数据库)3恢复指定时间段数据/usr/local/mysql/bin/mysqlbinlog --no-defaults /usr/local/mysql/data/binlog/mysql-bin.000001 --stop-date= \"2018-03-02 12:00:00\"  --start-date= \"2019-03-02 11:55:00\"|mysql -uroot -p test(数据库)

数据归档操作

binlog

sql底层执行原理

MySQL