InnoDB

这里是我精选出来的内容，原文地址： https://blog.csdn.net/l269798518/article/details/82428601 isset 和 empty isset 用来判断变量是否存在； empty 用来判断变量是否有值 。 $a 不存在和 $a = null 两种情况在 isset 看来为 true ，其余为 false （包括 $a = ‘’ ; ） $a = null, 0, false, ‘ ’ , 或不存在时在 empty 看来为 true ，其余为 false 。 private 、 protected 、 public 、 final 区别 public: 权限是最大的，可以内部调用，实例调用等。 protected: 受保护类型，用于本类和继承此类的子类调用。 private: 私有类型，只有在本类中使用。 static ：静态资源，可以被子类继承。 abstract ：修饰抽象方法，没有方法体，由继承该类的子类来实现。 final ：表示该变量、该方法已经 “ 完成 ” ，不可被覆盖。修饰类时该类不能被继承。 （因此 final 和 abstract 不能同时出现） 抽象类、接口 接口通常是为了抽象一种行为，接口是一种规范，在设计上的意义是为了功能模块间的解耦，方便后面的功能扩展、维护，接口不能有具体的方法 ; 抽象类可以有具体的方法

MySQL 5.6 ，是现在 最流行 的版本。 很遗憾有一些功能一直没有，例如： （1）哈希索引； （2）T-tree索引； （3）原生高可用； （4）auto-sharding； （5）... 画外音：你最希望看到支持什么特性？ 但，5.6版本中，InnoDB有些有意思的特性，或许是大伙还不清楚，今天简单和大家介绍一下。 画外音：大家应该都是用InnoDB吧？ 1. 从这个版本开始，可以支持 全文索引 了。 2. alter table可以不拷贝表了，且不阻塞写操作， online DDL ，酷炫吧。 画外音：并不是所有的alter table都这样。 3. 建表时，允许 一个table一个文件 了，具体能玩出什么花呢？ 这样就能够实现，热数据表放SSD里，数据量大的表放HDD里了。 4. 可以支持 memcached插件 了，关系型数据库和memcached缓存实现在一起，支持几十万的吞吐量，是不是简化了系统架构？ 5. 可以支持 只读实例 了，这样就能够实现： (1)把InnoDB表放在DVD或CD里，方便共享； (2)多个实例 共 用一份数据了； 这些有意思的特性，你会最想尝试哪一个呢？ 画外音：我猜是memcached插件。 为帮助更多开发工程师、架构师掌握 MySQL 核心，这里推荐一下奈学最新打造的 《3天挑战架构师级MySQL海量数据设计与实践 》 在线专栏课。

MySQL事务隔离级别详解 前两天面试，问到了四种隔离级别，当时觉得大多数数据库都为read committed，结果没想到mysql是个例外。在此做一下隔离级别和各种数据库锁的使用。 首先说一下ACID四大特性： 四大特性 · 原子性 　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。 　　· 一致性 　　 事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部 数据结构 （如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。 　　· 隔离性 　　由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同

在上一篇文章 《锁的类型以及加锁原理》 主要总结了 MySQL 锁的类型和模式以及基本的加锁原理，今天我们就从原理走向实战，分析常见 SQL 语句的加锁场景。了解了这几种场景，相信小伙伴们也能举一反三，灵活地分析真实开发过程中遇到的加锁问题。 如下图所示， 数据库的隔离等级，SQL 语句和当前数据库数据会共同影响该条 SQL 执行时数据库生成的锁模式，锁类型和锁数量 。 下面，我们会首先讲解一下隔离等级、不同 SQL 语句 和 当前数据库数据对生成锁影响的基本规则，然后再依次具体 SQL 的加锁场景。 隔离等级对加锁的影响 MySQL 的隔离等级对加锁有影响，所以 在分析具体加锁场景时，首先要确定当前的隔离等级 。 读未提交（Read Uncommitted 后续简称 RU）：可以读到未提交的读，基本上不会使用该隔离等级，所以暂时忽略。 读已提交（Read Committed 后续简称 RC）：存在幻读问题， 对当前读获取的数据加记录锁 。 可重复读（Repeatable Read 后续简称 RR）：不存在幻读问题，对当前读获取的数据加记录锁，同时对涉及的范围加间隙锁，防止新的数据插入，导致幻读。 序列化（Serializable）：从 MVCC 并发控制退化到基于锁的并发控制，不存在快照读，都是当前读，并发效率急剧下降，不建议使用。 这里说明一下， RC 总是读取记录的最新版本

##产生死锁的必要条件 多个并发事务（2个或者以上） 每个事物都持有了锁（或者是已经在等待锁） 每个事务都需要再继续持有锁（为了完成事务逻辑，还必须更新更多的行） 事物之间产生加锁的循环等待，形成死锁 常规锁模式 LOCK_S（读锁，共享锁） LOCK_X（写锁，排它锁） 锁的属性 LOCK _REC_NOT_GAP（锁记录） LOCK_GAP（锁记录前的GAP） LOCK_ORDINARY（同时锁记录+记录前的GAP，Next key锁） LOCK_INSERT_INTETION（插入意向锁） 锁组合（属性+模式） 可以任意组合 锁冲突矩阵 锁是加在那里的？ 根据主键查找-锁加在主键上 如 begin;select * from tt_copy where id=4 for update; 加锁情况 index PRIMARY of table test . tt_copy trx id 1101588 lock_mode X locks rec but not gap 根据普通索引查找-锁加在普通索引和主键上 如 begin;select * from tt_copy force index(idx_a) where a=4 for update; 加锁情况 index idx_a of table test . tt_copy trx id 1101590 lock_mode

一、Binlog日志格式 根据日志定义的格式不一样，可以分为Statement格式、Row格式或者MIXED格式 mysql5.6----》 | binlog_format | STATEMENT | mysql5.7---》 | binlog_format | ROW | 理解三种不同的格式 A： Statement格式 说明：基于语句的，记录操作的sql语句 优点： binlog文件大小较小 易于理解，方便阅读 日志中包含原始SQL，方便统计和审计 缺点： 存在安全隐患，可能导致主从不一致 对一些系统函数不能复制，比如sysdate，uuid等 不支持不确定的SQL语句 （以上格式不推荐使用，但是在mysql5.7以前都是默认的格式） B： Row格式 说明： 记录操作的每一行数据 优点： 相比statement更加安全的复制格式 系统的特殊函数也可以复制 更少的锁 数据一致性高 缺点： binlog 文件会比较大 无法从binlog中看见用户执行的SQL 每个表最好都要有一个主键 （推荐使用） 从mysql5.7之后，默认的格式为Row格式 Table_map： 记录表的元数据信息 ROWS_EVENT分为三种：WRITE_ROWS_EVENT，UPDATE_ROWS_EVENT，DELETE_ROWS_EVENT，分别对应insert，update和delete操作。