InnoDB与MyISAM存储引擎区别::
InnoDB支持事务,支持行级别锁,支持热备,支持自动故障恢复,MVCC
MyISAM 不支持事务,支持表级锁,支持温备份,不支持自动故障恢复和MVCC
详:
1)InnoDB 支持事务,而 MyISAM 不支持。
2)InnoDB 支持外键,而 MyISAM 不支持。因此将一个含有外键的 InnoDB 表 转为 MyISAM 表会失败。
3)InnoDB 和 MyISAM 均支持 B+ Tree 数据结构的索引。但 InnoDB 是聚集索引,而 MyISAM 是非聚集索引
4)InnoDB 不保存表中数据行数,执行 select count(*) from table 时需要全表扫描。而 MyISAM 用一个变量记录了整个表的行数,速度相当快(注意不能有 WHERE 子句)
那为什么 InnoDB 没有使用这样的变量呢?
因为InnoDB的事务特性,在同一时刻表中的行数对于不同的事务而言是不一样的。
5)InnoDB 支持表、行(默认)级锁,而 MyISAM 支持表级锁。
InnoDB 的行锁是基于索引实现的,而不是物理行记录上。即访问如果没有命中索引,则也无法使用行锁,将要退化为表锁。
6)InnoDB 必须有唯一索引(如主键),如果没有指定,就会自动寻找或生产一个隐藏列 Row_id 来充当默认主键,而 Myisam 可以没有主键。
hash类型的索引和btree类型的索引的区别:
hash类型的索引:查询单条快,范围查询慢
btree类型的索引:b+树,层数越多,数据量指数级增长(我们就用它,因为innodb默认支持它)
Hash
1)Hash 进行等值查询更快,但无法进行范围查询。因为经过 Hash 函数建立索引之后,索引的顺序与原顺序无法保持一致,故不能支持范围查询。同理,也不支持使用索引进行排序。
2)Hash 不支持模糊查询以及多列索引的最左前缀匹配,因为 Hash 函数的值不可预测,如 AA 和 AB 的算出的值没有相关性。
3)Hash 任何时候都避免不了回表查询数据.
4)虽然在等值上查询效率高,但性能不稳定,因为当某个键值存在大量重复时,产生 Hash 碰撞,此时查询效率反而可能降低。
B+ Tree
1)B+ 树本质是一棵查找树,自然支持范围查询和排序。
2)在符合某些条件(聚簇索引、覆盖索引等)时候可以只通过索引完成查询,不需要回表。
3)查询效率比较稳定,因为每次查询都是从根节点到叶子节点,且为树的高度。
事务及其特性:
- 在MySQL中只有使用了Innodb数据库引擎的数据库或表才支持事务
- 事务处理可以用来维护数据库的完整性,保证成批的sql语句要么全部执行,要么全部不执行。全部执行称为事务提交,全部不执行称为事务回滚。
- 事务主要用于管理insert、update、delete
ACID特性
- 一般来说,事务必须满足四个特性(ACID)
- A:原子性,事务必须是执行任务的最小原子单位,事务要么成功要么撤回
- C:一致性,事务是把数据库从一个一致性状态转化为另一个一致性状态
- I:隔离性,每个事务之间是隔离的
- D:持久性,事务一旦执行,数据的修改是永久的
四个隔离等级
- read uncommitted(未提交读):出现脏读的现象
- read conmitted (提交读):能够解决脏读,修改数据时会加锁。会出现幻读现象
- repeatable read (可重读):能够解决幻读现象
- serializable(可串行化读):事务需要按串行化解决(MVCC)
MVCC 在 MySQL InnoDB 中的实现主要是为了提高数据库并发性能,用更好的方式去处理读-写冲突,做到即使有读写冲突时,也能做到不加锁,非阻塞并发读
mysql> show variables like '%iso%';
#查看隔离级别
vim /etc/my.cnf
[mysqld]
transaction_isolation=repeatable-read
#修改隔离级别
MySQL 中的常见日志:
-
重做日志(redo log):物理日志
作用是确保事务的持久性。 redo 日志记录事务执行后的状态,用来恢复未写入 data file 的已提交事务数据。 -
回滚日志(undo log):逻辑日志
作用是保证数据的原子性。 保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。 -
二进制日志(binlog):逻辑日志
常用于主从同步或数据同步中,也可用于数据库基于时间点的还原。 -
错误日志(errorlog)
记录着 MySQL 启动和停止,以及服务器在运行过程中发生的错误的相关信息。在默认情况下,系统记录错误日志的功能是关闭的,错误信息被输出到标准错误输出。 -
普通查询日志(general query log)
记录了服务器接收到的每一个命令,无论命令语句是否正确,因此会带来不小开销,所以也是默认关闭的。 -
慢查询日志(slow query log)
记录执行时间过长和没有使用索引的查询语句(默认 10s),同时只会记录执行成功的语句。 -
中继日志(relay log)
在从节点中存储接收到的 binlog 日志内容,用于主从同步。
主从复制的原理:
复制过程
- 主服务器上任何的更新操作会被写入到二进制日志文件中
- 从服务器上的IO线程:
- 检测主服务器的二进制日志文件的变化
- 同步主服务器的二进制日志文件到本地的中继日志中
- 从服务器上的sql线程负责读取和执行中继日志中的sql语句
图解
MHA高可用的原理和优势:
相较于其它HA软件,MHA的目的在于维持MySQL Replication中Master库的高可用性,其最大特点是可以修复多个Slave之间的差异日志,最终使所有Slave保持数据一致,然后从中选择一个充当新的Master,并将其它Slave指向它,工作流程主要如下:
a.当master出现故障时,通过对比slave之间读取master binlog的位置,选取最接近的slave做为latest slave;
b.其它slave通过与latest slave对比生成差异中继日志;
c.在latest slave上应用从master保存的binlog,同时将latest slave提升为master;
d.最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制.
在MHA实现Master故障切换过程中,MHA Node会试图访问故障的master(通过SSH),如果可以访问(不是硬件故障,比如InnoDB数据文件损坏等),会保存二进制文件,以最大程度保证数据不丢失.MHA和半同步复制一起使用会大大降低数据丢失的危险
参考其他博客:
https://blog.csdn.net/adminpd/article/details/122910606
https://www.cnblogs.com/fawaikuangtu123/p/10927888.html