数据库&MySQL

数据库&MySQL，学习资料

数据库，知识点概述

数据库，知识点概述】】--------事务i。并发i。数据库故障和恢复技术i。

数据库事务

事务i】】------------事务，是什么/定义。数据事务的实现原理。事务相关SQL语句及解释。

事务，是什么/定义】事务是一系列的数据库操作，是数据库应用程序的基本逻辑单元。所谓事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是个不可分割的工作单位。例如，在关系数据库中，一个事务可以是一条SQL 语句、一组SQL语句或整个程序。事务和程序是两个概念。一般地讲，一个程序中包含多个事务。
事务是数据库的逻辑工作单位，事务不仅是恢复的基本单位，也是并发控制的基本单位。

数据事务的实现原理】
JavaGuide—以 MySQL 的 InnoDB 引擎为例来简单说一下。
MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。
MySQL InnoDB 引擎通过 锁机制、MVCC 等手段来保证事务的隔离性（ 默认支持的隔离级别是 REPEATABLE-READ ）。
保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。------JavaGuide

事务相关SQL语句及解释】
事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务，则由数据库管理系统按默认规定自动划分事务。在SQL中，定义事务的语句一般有三条:BEGIN TRANSACTION、COMMIT、ROLLBACK。
事务通常是以 BEGIN TRANSACTION开始，以 COMMIT 或ROLLBACK结束。COMMIT表示提交，即提交事务的所有操作，具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束。ROLLBACK表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。这里的操作指对数据库的更新操作。

明确辨识事务和操作】如，某公司在银行中有A，B两个账号，现在公司想从账号A中取出一万元，存入账号B，这就可以定义一个事务，该事务包括两个操作，第一个操作是从账号A中减去一万元第二个操作是向账号B中加入一万元。

事务处理技术，主要包括】数据库恢复技术和并发控制技术。

事务的ACID特性】事务具有4个特性:原子性（Atomicity)、一致性（Consistency)、隔离性(Isolation)和持续性（Durability）。具体见书。

原子性Atomicity：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。

一致性Consistency：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成的事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。例如，某公司在银行中有A,B两个账号，现在公司想从账号A中取出一万元，存入账号B。那么就可以定义一个事务，该事务包括两个操作，第一个操作是从账号A中减去一万元,第二个操作是向账号B中加入一万元。这两个操作要么全做，要么全不做。全做或者全不做，数据库都处于一致性状态。如果只做一个操作，则逻辑上就会发生错误，减少或增加一万元，这时数据库就处于不一致性状态了。可见一致性与原子性是密切相关的。

隔离性Isolation：一个事务的执行不能被其他事务干扰。即一个事务的内部操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰。

持续性Durability：持续性也称永久性（Permanence)，指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

可能会导致事务的ACID特性遭到破坏的因素】(1）多个事务并行运行时,不同事务的操作交叉执行;(2）事务在运行过程中被强行停止。在第一种情况下，数据库管理系统必须保证多个事务的交叉运行不影响这些事务的原子性;在第二种情况下，数据库管理系统必须保证被强行终止的事务对数据库和其他事务没有任何影响。这些就是数据库管理系统中恢复机制和并发控制机制的责任。

数据库并发

并发i】】-------数据库并发场景。并发事务带来哪些问题/并发操作带来的数据不一致性。并发控制i。

事务的并发执行，概述】
事务可以一个一个地串行执行，即每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行，事务在执行过程中需要不同的资源，有时需要 CPU，有时需要存取数据库，有时需要IO，有时需要通信，如果事务串行执行，则许多系统资源将处于空闲状态，因此，为了充分利用系统资源，发挥数据库共享资源的特点,应该允许多个事务并行地执行。

单处理机系统的事务的交叉并发执行方式】
在单处理机系统中，事务的并行执行实际上是这些并行事务的并行操作轮流交叉运行，这种并行执行方式称为交叉并发方式(interleaved concurrency)，虽然单处理机系统中的并行事务并没有真正地并行运行，但是减少了处理机的空闲时间，提高了系统的效率。我们讨论的数据库系统并发控制concurrency control in database systen技术是以单处理机系统为基础的，该理论可以推广到多处理机的情况。

多处理机系统的真正的并行】
在多处理机系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行。这种并行执行方式称为同时并发方式simultaneous concurrency，以单处理机系统为基础的并发控制可以推广到多处理机的情况。

数据库并发场景】
网友----1.读-读:不存在任何问题，也不需要并发控制;⒉读-写:有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读;3.写-写:有线程安全问题，可能会存在更新丢失问题。--------网友

并发事务带来哪些问题/并发操作带来的数据不一致性】

并发事务带来哪些问题/并发操作带来的数据不一致性---------阅读《数据库系统概论》307页。

并发控制i】】---------并发控制，概述。并发控制的机制。封锁机制可能带来的问题-----活锁、死锁。数据库对并发事务的正确调度：串行。并发控制机制MVCC。

并发控制，概述】
数据库是一个共享资源，可以供多个用户使用，允许多个用户同时使用同一个数据库的数据库系统称为多用户数据库系统，当多个用户并发地存取数据库时就会产生多个事务同时存取同一数据的情况，若对并发操作不加控制就可能会存取和存储不正确的数据,破坏事务的一致性和数据库的一致性，所以数据库管理系统必须提供并发控制机制。并发控制机制是衡量一个数据库管理系统性能的重要标志之一。
事务是并发控制的基本单位，保证事务的ACID特性是事务处理的重要任务，而事务的ACID 特性可能遭到破坏的原因之一是多个事务对数据库的并操作造成的，为了保证事务的隔离性和一致性，数据库管理系统需要对并发操作进行正确调度，这些就是数据库管理系统中并发控制机制的责任。

并发控制的机制】并发控制的主要技术有封锁(locking)、时间戳（timestamp)、乐观控制法（optimisticscheduler）和多版本并发控制（multi-version concurrency control, MVCC）等。

数据库的重要特征是能为多个用户提供数据共享。数据库管理系统必须提供并发控制机制来协调并发用户的并发操作以保证并发事务的隔离性和一致性，保证数据库的一致性。

并发控制机制-----封锁(locking)】
封锁(locking)，概述】封锁是实现并发控制的一个非常重要的技术，所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁，加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其他事务不能更新此数据对象，例如，在例11.1中，事务T要修改A，若在读出A前先锁住A，其他事务就不能再读取和修改A了，直到T修改并写回A后解除了对A的封锁为止，这样，就不会丢失T的修改。

确切的控制由封锁的类型决定。基本的封锁类型有两种:排他锁（exclusive locks，简称X锁，又叫写锁）和共享锁（share locks，简称S锁，又叫读锁)。

排他锁(即写锁)】
排他锁又称为写锁：若事务T对数据对象A加上X锁，则只允许T读取和修改，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁为止，这别保证了其他事务在T释放A上的锁之前不能再读取和修改A。

共享锁(即读锁)】
共享锁又称为读锁：若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁为止，这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

封锁这种方法可能带来的问题】活锁；死锁

封锁这种方法带来的活锁问题】

避免活锁的方法】

封锁的方法带来的死锁问题】两个事务处于互相等待，永远不能结束的局面，形成死锁。

数据库中解决死锁的方法】：方法一：采取措施预防死锁的发生(少用)。方法二：诊断与解除。由于采取预防措施其实有弊端，所以数据库普遍采用的是诊断并解除死锁的方法。

预防死锁问题的方法】一次封锁法、顺序封锁法

顺序封锁法，是什么/解释】…。存在的缺点。

一次封锁法，是什么/解释】要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。存在的缺点

解决死锁的方法–诊断与解除】诊断死锁的方法：超时法、事务等待图法

并发控制机制MVCC】

MVCC，概述】多版本并发控制MVCC:Multi-Version Concurrency Control，MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，提高数据库的并发性能。MVCC不只使用在MySQL中，Oracle、PostgreSQL，以及其他一些数据库系统也同样使用它。各个存储引擎对于MVCC的实现各不相同。

可将MVCC看成行级别锁的一种妥协，它在许多情况下避免了使用锁，同时可以提供更小的开销。根据实现的不同，它可以允许非阻塞式读，在写操作进行时只锁定必要的记录。

使用MVCC多版本并发控制比锁定模型的主要优点是在MVCC里， 对检索（读）数据的锁要求与写数据的锁要求不冲突， 所以读不会阻塞写，而写也从不阻塞读。

InnoDB存储引擎对MVCC的实现，dai看JavaGuide

MVCC解决并发哪些问题】

MVCC的实现原理】

数据库对并发事务的正确调度：串行】

• 处理并发过程中出现的术语名词"调度"，是什么/解释】对于多个并发事务涵盖的操作的先后顺序排列。
• 数据库系统如何处理多个并发事务】对多个并发事务采取调度，可以采用串行调度或可串行调度。
• 如何判断多个事务的并发调度是正确的/怎样是正确的并发调度】串行调度是正确的。可串行化的并发调度是正确的。
• “可串行化调度”，是什么/定义】当此调度结果与按某一次序串行地执行这些事务时的结果相同，称这种调度策略为可串行化（serializable）调度
• “串行调度“，是什么】多个不同事务，按顺序一个事务的操作全部执行完后，再执行另一个事务，这样的调度方式叫作串行调度。
• “冲突操作”，是什么】冲突操作是指不同的事务对同一个数据的读写操作和写写操作:
• 如何判断两个连续的操作是否冲突】
• “冲突可串行化的调度”，是什么】一个调度 Sc在保证冲突操作的次序不变的情况下，通过交换两个事务不冲突操作的次序得到另一个调度Sc’，如果Sc’是串行的，称调度Sc为冲突可串行化的调度。
• 如何判断这个调度是可串行化调度】若一个调度是冲突可串行化的，则一定是可串行化的调度，这是个充分条件。
• 如何使封锁机制能够产生可串行化的调度】方法：两段锁(2PL)协议

封锁协议，概述】在运用X锁和S锁这两种基本封锁对数据对象加锁时，还需要约定一些规则。何时申请X锁或S锁、持锁时间、何时释放等。这些规则称为封锁协议(locking protocol）对封锁方式制定不同的规则，就形成了各种不同的封锁协议。一级封锁协议、二级封锁协议、三级封锁

保证调度是可串行化的方式： 两段锁(2PL)协议】
------- 两段锁(2PL)协议，是什么/解释】所谓两段锁协议是指所有事务必须分两个阶段对数据项加锁和解锁。·在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁。;·在释放一个封锁之后，事务不再申请和获得任何其他封锁。所谓“两段”锁的含义是，事务分为两个阶段,第一阶段是获得封锁，也称为扩展阶段，在这个阶段，事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁;第二阶段是释放封锁，也称为收缩阶段，在这个阶段，事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。
--------- 两段锁(2PL)协议，作用】在数据库使用封锁的机制实现并发控制时，为保证封锁机制下的调度能够产生可串行化调度。若并发执行的所有事务均遵守两段锁协议,则对这些事务的任何并发调度策略都是可串行化的。事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。

数据库故障和恢复技术

数据库故障和恢复技术i，知识点概述】】--------数据库恢复技术是什么。数据库系统可能发生的故障。恢复数据库技术和策略。

数据库恢复技术是什么】
尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失。因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能,这就是数据库的恢复。恢复子系统是数据库管理系统的一个重要组成部分，而且还相当庞大，常常占整个系统代码的10%以上。数据库系统所采用的恢复技术是否行之有效，不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大影响，是衡量系统性能优劣的重要指标。

数据库系统可能发生的故障】
1.事务故障 2.系统故障 3.介质故障 4.计算机病毒
各类故障对数据库的影响有两种可能性，一是数据库本身被破坏，二是数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的。

事务故障 ：事务故障是指事务在运行至正常终止点前被终止，事务故障意味着事务没有达到预期的终点(COMMIT 或者显式的ROLLBACK),因此数据库可能处于不正确状态，恢复程序要在不影响其他事务运行的情况下，强行回滚该务，即撤销该事务已经作出的任何对数据库的修改，使得该事务好像根本没有启动一样.这类恢复操作称为事务撤销（UNDO)。事务内部更多的故障是非预期的，是不能由应用程序处理的，如运算溢出、并发事务发生死锁而被选中撤销该事务、违反了某些完整性限制而被终止等。

系统故障：系统故障常称为软故障（soft crash)。系统故障是指造成系统停止运转的任何事件，使得系统要重新启动，例如，特定类型的硬件错误（CPU 故障)、操作系统故障、DBMS 代码错误、系统断电等，这类故障影响正在运行的所有事务，但不破坏数据库，此时主存内容，尤其是数据库缓冲区（在内存)中的内容都被丢失，所有运行事务都非正常终止，发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，从而造成数据库可能处于不正确的状态，为保证数据一致性，需要清除这些事务对数据库的所有修改。恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销所有未完成事务。另一方面，发生系统故障时，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，系统故障使得这些事务对数据库的修改部分或全部丢失，这也会使数据库处于不一致状态，因此应将这些事务已提交的结果重新写入数据库，所以系统重新启动后，恢复子系统除需要撤销所有未完成的事务外，还需要重做（REDO)所有已提交的事务，以将数据库真正恢复到一致状态。

介质故障：介质故障称为硬故障（hard crash)。硬故障指存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等，这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务，这类故障比前两类故障发生的可能性小得多但破坏性最大。

计算机病毒(略)。

恢复数据库技术和策略】】----恢复数据库技术，概述。数据库恢复的实现技术。针对不同数据库故障的恢复策略。

恢复数据库技术，概述】恢复的基本原理十分简单，可以用一个词来概括:“冗余”，这就是说，数据库中任何部分被破坏或不正确的数据可以根据存储在系统别处的冗余数据来重建，尽管恢复的基本原理很简单，但实现技术的细节却相当复杂。

数据库恢复的实现技术】
恢复机制涉及的两个关键问题是:如何建立冗余数据，以及如何利用这些冗余数据实施数据库恢复。建立冗余数据最常用的技术是数据转储和登记日志文件logging，通常在一个数据库系统中,这两种方法是一起使用的。

数据转储：数据转储是数据库恢复中采用的基本技术。所谓转储即数据库管理员定期地将整个据库复制到磁带、磁盘或其他存储介质上保存起来的过程。这些备用的数据称为后备副(backup）或后援副本。
当数据库遭到破坏后可以将后备副本重新装入，但重装后备副本只能将数据库恢复转储时的状态,要想恢复到故障发生时的状态,必须重新运行自转储以后的所有更新事务。例如，在图10.1中系统在T时刻停止运行事务，进行数据库转储，在T时刻转储完毕,得到T。时刻的数据库一致性副本。系统运行到T时刻发生故障。为恢复数据库，首先!数据库管理员重装数据库后备副本,将数据库恢复至T,时刻的状态，然后重新运行自T。T次时刻的所有更新事务，这样就把数据库恢复到故障发生前的一致状态。

数据转储可以分为静态转存和动态转存，数据转储还可以分为海量转储和增量转储两种方式。

登记日志文件logging】】----日志文件的格式和内容、日志文件的使用、“先写日志文件”原则。

日志文件的格式和内容：日志文件是用来记录事务对数据库的更新操作的文件。不同数据库系统采用的日志文件格式并不完全一样。日志文件主要有两种格式:以记录为单位的日志文件和以数据块为单位的日志文件。

日志文件的使用】

“先写日志文件”原则】
把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作，有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了，如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的 UNDO操作，并不会影响数据库的正确性，所以为了安全，一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改，这就是“先写日志文件”的原则。

针对不同数据库故障的恢复策略】】-----针对事务故障的恢复策略；针对系统故障的恢复策略；针对介质故障的恢复策略。

当系统运行过程中发生故障，利用数据库后备副本和日志文件就可以将数据库恢复故障前的某个一致性状态，不同故障其恢复策略和方法也不一样。

针对事务故障的恢复策略】
事务故障是指事务在运行至正常终止点前被终止，这时恢复子系统应利用日志文件撤销（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。系统的恢复步骤是:
(1）反向扫描日志文件（即从最后向前扫描日志文件)，查找该事务的更新操作。
(2）对该事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时“更新前的值”为空);若记录中是删除操作，则做插入操作;若是修改操作，则相当于用修改前值代替修改后值。
（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
(4）如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

针对系统故障的恢复策略】

针对介质故障的恢复策略】

MySQL，知识点概述

MySQL，知识点概述】】-----------MySQL简介。MySQL中的数据类型。MySQL存储引擎。MySQL基本逻辑架构。MySQL的日志。MySQL索引i。MySQL数据库维护：备份、诊断、查看日志。 MySQL 高性能优化规范建议。MySQL锁。事务隔离级别。InnoDB。乐观锁。悲观锁。MySQL相关杂i。

MySQL是一种DBMS，即它是一种数据库软件。

MySQL存储引擎】
存储引擎
MySQL有很多种存储引擎
MySQL存储引擎
MySQL 5.5 之前：MyISAM 引擎是 MySQL 的默认存储引擎
MySQL 5.5 版本后默认的存储引擎为 InnoDB。

MyISAM】
MySQL 5.5 之前，MyISAM 引擎是 MySQL 的默认存储引擎
MyISAM 不支持事务和行级锁，而且最大的缺陷就是崩溃后无法安全恢复。

InnoDB】】-------InnoDB的锁算法。
MySQL 5.5 版本后默认的存储引擎为 InnoDB。

InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。
InnoDB 提供事务支持，具有提交(commit)和回滚(rollback)事务的能力。
MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。
MySQL InnoDB 引擎通过 锁机制、MVCC 等手段来保证事务的隔离性（ 默认支持的隔离级别是 REPEATABLE-READ ）。

在InnoDB中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表。

MySQL基本逻辑架构】
MySQL可以分为Server层和存储引擎层两部分。
Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务 功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在 这一层实现，比如存储过程、触发器、视图等。存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、 Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了 默认存储引擎。
不同存储引擎的表数据存取方式不同，支持的功 能也不同。

MySQL 日志，概述】MySQL 日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和重做日志 redo log和 undo log（回滚日志）。

待读JavaGuide----------https://javaguide.cn/database/mysql/mysql-logs.html#%E5%89%8D%E8%A8%80

二进制日志binlog】---------是什么；有什么用；怎么用。
Server层也有自己的日志，称为binlog（归档日志）。

物理日志redo log 】------redo log：是什么；有什么用；怎么用。
当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log（粉板）里 面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作 记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做

回滚日志undo log】

网友-------InnoDB中通过undo log实现了数据的多版本，而并发控制通过锁来实现，undo log除了实现MVCC外，还用于事务的回滚。

MySQL索引i】】--------------------什么是索引i。给表建立索引优缺点。索引是如何工作的i。实现索引的方式i。不同的存储引擎对于索引结构的支持情况。索引类型。插入一个记录后如何进行维护。InoDB的B+树索引模型。覆盖索引。索引失效问题。如何使用好索引。回表。最左前缀原则。

什么是索引i】
索引（index）是帮助MySQL高效获取数据的数据结构。要知道没有索引时是如何查询的，从而体会有索引的好处。在无索引情况下，就需要从第一行开始扫描，一直扫描到最后一行，我们称之为 全表扫描，性能很低。如果我们针对于这张表建立了索引，以某个字段为索引，就会对这个字段建立一个在二叉搜索树基础上演化来的树结构，进行查询时，减少查询次数，提高查询效率。

实现索引的方式i】】--------实现索引的方式有哪些。 每一种实现索引的方式的工作过程。每一种实现索引的方式的特性分析。不同的实现索引的方式的应用场景。

实现索引的方式有哪些】实现索引的方式有很多种，常见的实现它的数据结构有：哈希表、有序数组和二叉搜索树基础上演变而来的N叉树。
我们平常所说的索引，如果没有特别指明，都是指B+树结构组织的索引。
索引结构，主要包含以下几种：

哈希Hash表】

哈希表是一种以键-值（key-value）存储数据的结构，哈希的思路很简单，把值放在数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置。不可避免地，多个key值经过哈希函数的换算，会出现同一个值的情况。处理这种情况的一种方 法是，拉出一个链表。
哈希索引做区间查询的速度是很慢 的，需要把表全部扫描一遍。
哈希表这种结构适用于只有等值查询的场景 哈 ，比如Memcached及其他一些NoSQL引擎。
Hash 索引不支持顺序和范围查询，这是它最大的缺点。

有序数组】

用二分法就可以快速得到，这个时间复杂度是O(log(N))，查询效率很高。
更新数据时，如往中间插入一个记录，需要移动后续元素，成本太高。
有序数组索引只适用于静态存储引擎，即数据库中存入一般不会再修改。
有序数组在等值查询和范围查询场景中的性能就都非常优秀 。

B+树】
InnoDB存储引擎选择使用B+tree索引结构

给表建立索引优缺点】

JavaGuide--------优点 ：使用索引可以大大加快 数据的检索速度（大大减少检索的数据量）, 这也是创建索引的最主要的原因。
通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
缺点 ：创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率。索引需要使用物理文件存储，也会耗费一定空间。但是，使用索引一定能提高查询性能吗?大多数情况下，索引查询都是比全表扫描要快的。但是如果数据库的数据量不大，那么使用索引也不一定能够带来很大提升。—JavaGuide
帅地--------同样索引也会带来很多负面影响:创建索引和维护索引需要耗费时间，这个时间随着数据量的增加而增加;索引需要占用物理空间，不光是表需要占用数据空间，每个索引也需要占用物理空间;当对表进行增、删、改、的时候索引也要动态维护，这样就降低了数据的维护速度。------帅地

不同的存储引擎对于索引结构的支持情况】

不同的存储引擎有不同的索引结构
同一种索引结构，在不同存储引擎中的实现可能不同。

索引类型】

索引类型：主键、非主键。聚簇、非聚簇】

mine----存储引擎会自动给主键创建索引？主键的树的叶子节点指向的就是数据库？
mine—非主键索引k已经“覆盖了”我们的查询需求，我们称为覆盖索引。

索引类型分为主键索引和非主键索引。

主键索引，概述】
主键索引：主键索引的叶子节点存的是整行数据。在InnoDB里，主键索引属于聚簇索引（clustered index）。数据表的主键列使用的就是主键索引。
自增主键是指自增列上定义的主键，在建表语句中一般是这么定义的： NOTNULL PRIMARY KEY AUTO_INCREMENT。插入新记录的时候可以不指定主键的值，系统会获取当前主键最大值加1作为下一条记录的主键值。在InnoDB的B+树索引存储结构结构上看，每次插入一条 新记录，都是追加操作，都不涉及到挪动其他记录，也不会触发叶子节点的分裂。

主键索引的查询：假设表的主键是ID，非主键k，且在建表时给k建立索引。
如果语句是select *from T where ID=500，即主键查询方式，则只需要搜索ID这棵B+树；

非主键索引(又叫二级索引 )】
非主键索引的叶子节点内容是主键的值。二级索引的叶子节点存储的数据是主键。也就是说，通过二级索引，可以定位主键的位置。JavaGuide—唯一索引，普通索引，前缀索引等索引属于二级索引。

非主键索引的查询：
假设表的主键是ID，非主键k，且在建表时给k建立索引。
如果语句是select *from T where k=5，即普通索引查询方式，则需要先搜索k索引树，得到ID 的值为500，再到ID索引树搜索一次。回到主键索引树搜索的过程，我们称为回表。基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。

从物理存储角度，索引分为聚集索引与非聚集索引】
-------聚集索引】
聚集索引即索引结构和数据一起存放的索引，找到索引也就找到了数据。主键索引属于聚集索引。
一个表仅有一个聚簇索引。
聚集索引的优点、缺点。
-----非聚集索引】
非聚集索引：非聚集索引即索引结构和数据分开存放的索引。二级索引属于非聚集索引。
非聚集索引的优点、缺点。

索引失效问题】】----什么情况下索引会失效，即查询不走索引?

模糊查询】
如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

MySQL在查询时，会评估使用索引的效率与走全表扫描的效率，如果走全表扫描更快，则放弃索引，走全表扫描。 因为索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则还不如走全表扫描来的快，此时索引就会失效。

如何使用好索引】
JavaGuide-------对于中到大型表索引都是非常有效的，但是特大型表的话维护开销会很大，不适合建索引。避免 where 子句中对字段施加函数，这会造成无法命中索引。在使用 InnoDB 时使用与业务无关的自增主键作为主键，即使用逻辑主键，而不要使用业务主键。删除长期未使用的索引，不用的索引的存在会造成不必要的性能损耗 MySQL 5.7 可以通过查询 sys 库的 schema_unused_indexes 视图来查询哪些索引从未被使用。在使用 limit offset 查询缓慢时，可以借助索引来提高性能------JavaGuide

帅地--------建立索引的原则:1.在最频繁使用的、用以缩小查询范围的字段上建立索引;2.在频繁使用的、需要排序的字段上建立索引。不适合建立索引的情况:1.对于查询中很少涉及的列或者重复值比较多的列，不宜建立索引;2.对于—些特殊的数据类型，不宜建立索引，比如:文本字段(text)等。--------帅地

1.如果数据重复度高，就不需要创建索引。通常在重复度超过 10% 的情况下，可以不创建这个字段的索引。比如性别这个字段（取值为男和女）。
2.要注意索引列的位置对索引使用的影响。比如我们在 WHERE 子句中对索引字段进行了表达式的计算，会造成这个字段的索引失效。
3.要注意联合索引对索引使用的影响。我们在创建联合索引的时候会对多个字段创建索引，这时索引的顺序就很重要了。比如我们对字段 x, y, z 创建了索引，那么顺序是 (x,y,z) 还是 (z,y,x)，在执行的时候就会存在差别。
4.要注意多个索引对索引使用的影响。索引不是越多越好，因为每个索引都需要存储空间，索引多也就意味着需要更多的存储空间。此外，过多的索引也会导致优化器在进行评估的时候增加了筛选出索引的计算时间，影响评估的效率。

最左前缀原则】

最左前缀原则的适用场景？/已创建了联合索引，查询的语句的条件是什么的时候会走这个联合索引】where条件必须有联合索引的第一个字段，联合索引与where条件的顺序无关。参考：https://zhuanlan.zhihu.com/p/110427099。

MySQL锁】

MySQL中的锁，按照锁的粒度分，分为以下三类：
全局锁：锁定数据库中的所有表。
表级锁：每次操作锁住整张表。
行级锁：每次操作锁住对应的行数据。

全局锁】
全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞。

全局锁应用场景】
做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。

全局锁，相关语法】

表级锁】
表级锁，概述】
表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。

表级锁，分类】
表级锁，主要分为以下三类：表锁、元数据锁（meta data lock，MDL）、意向锁

行级锁】

对比表级锁和行级锁】
网友--------MyISAM只支持表锁,InnoDB支持表锁和行锁，默认为行锁。表级锁:开销小，加锁快，不会出现死锁。锁定粒度大，发生锁冲突的概率最高，并发量最低。行级锁:开销大，加锁慢，会出现死锁。锁粒度小，发生锁冲突的概率小，并发度最高。------网友

MySQL的事务隔离级别】当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantomread）的问题，为了解决这些问题，就有了“隔离级别”的概 念。
隔离得越严实，效率就会越低。因此很多时候，我们都要 在二者之间寻找一个平衡点。在不同的隔离级别下，数据库行为是有所不同的。

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。

事务隔离级别】
事务隔离级别包括：读未提交（read uncommitted）、 读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）。

读未提交（read uncommitted）：读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。

读取已提交（read committed）：读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。 JavaGuide-----允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。

可重复读（repeatable read）：可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一 致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。 JavaGuide----对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。

串行化（serializable ）：串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突 的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。JavaGuide----最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

MySQL数据库维护：备份、诊断、查看日志】
见《MySQL必知必会》第二十九章

dai读，JavaGuide----------https://javaguide.cn/database/mysql/transaction-isolation-level.html#%E5%89%8D%E8%A8%80

“mysql的隔离级别，默认的隔离级别，可重复读是怎么实现的，读已提交和读未提交的区别，会出现哪些问题”--------字节跳动面试

MySQL 高性能优化规范建议】
dai看JavaGuide
dai看《MySQL必知必会》第30章
insert插入数据i的优化】
如果我们需要一次性往数据库表中插入多条记录，可以从以下三个方面进行优化：批量插入数据;手动控制事务; –-local-infile从本地导入文件
怎么才可以知道这条语句运行很慢的原因】

主键优化】-----不懂dai

limit分页查询的优化】

在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。

update更新数据的优化】

为什么这些SQL语句逻辑相同，性能却差异巨大？条件字段函数操作。对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃 对 走树搜索功能。对索引字段做函数操作，可能会破坏 对 索引值的有序性，因此优化器就决定放弃走树搜索功能。

SQL慢查询分析】什么样的查询是慢查询？如何分析慢查询。MySQL中如何使用explain来分析慢查询？explain的十个列。

MySQL相关杂i】
MySQL问题排查都有哪些手段?
MySQL数据库CPU飙升到500%的话他怎么处理?
InnoDB和MyISAM的比较?

杂

mysql命令行常用】：进入cmd进入bin目录下，启动mysql服务net start mysql 连接到Mysql数据库：mysql -h 主机 -p 端口 -u 用户名 -p密码 (-p和密码之间没空格) use mysql; 修改mysql密码；update user set authentication_string=password(“ning”) where user='root’and Host='localhost '; 退出命令行实用程序 quit ；服务器停止 ：net stop mysql

关系数据库系统与非关系数据库系统的区别是，关系系统只有“表”这一种数据结构;而非关系数据库系统还有其他数据结构，以及对这些数据结构的操作。

数据库主从复制

数据库主从复制，概述】MySQL的主从复制，顾名思义就是将MySQL主数据库中的数据复制到从数据库中去。通过数据库主从复制的方式，可以实现数据库的读写分离。写操作访问主数据库，读操作访问从数据库。

数据库主从复制的原理】主要的复制原理是，当应用程序客户端发送一条更新命令到主服务器数据库时，数据库会把这条更新命令同步记录到Binlog中，然后由另外一个线程从Binlog中读取这日志，并通过远程通信的方式将它复制到从服务器去。从服务器获得这条更新日志后，将其加入自己的Relay Log中，然后由另外一个SQL执行线程，从Relay Log中读取这条新的日志，并把它在本地的数据库中重新执行一遍，这样当客户端应用程序执行一个update命令时，这个命令会同时在主数据库和从数据库上执行，从而实现了主数据库向从数据库的复制，让从数据库和主数据库保持一样的数据。

在实践中通常采用一主多从的数据复制方案，也就是说一个主数据库将数据复制到多个从数据库，多个从数据库承担更多的读操作压力，这些从数据库扮演着不同的角色，比如有的从数据库用来做实时数据分析，有的用来做批任务报表计算，有的单纯做数据备份。 采用一主多从的方案时，如果某个从数据库宕机，还可以将读操作迁移到其他从数据库上保证读操作的高可用。如果主数据库宕机，系统就没法使用了。

数据库主主复制

在数据库主从复制的方式下，如果某个主数据库宕机，系统就没法使用了，因此在现实中，也会采用MySQL主主复制方案。MySQL主主复制方案----:两台服务器互相备份，任何一台服务器都会将自己的Binlog复制到另一台机器的Relay Log中，以保持两台服务器的数据一致。

使用主主复制需要注意的点…。

数据库分片技术

数据库分片技术，概述】将一张表的数据分成若干片，每一片都包含了数据表中一部分的行记录，且每一片都存储在不同的服务器上，这样一张表就存储在多台服务器上了。最简单的数据库分片存储可以采用硬编码的方式。

SQL性能分析

通过 show [session|global] status 命令可以提供服务器状态信
息。通过上述指令，我们可以查看到当前数据库到底是以查询为主，还是以增删改为主，从而为数据库优化提供参考依据。 如果是以增删改为主，我们可以考虑不对其进行索引的优化。 如果是以查询为主，那么就要考虑对数据库的索引进行优化了。通过配置慢查询日志，就可以定位出执行效率比较低的SQL，从而有针对性的进行优化。

MySQL是支持 profile操作，若开启后，我们所执行的SQL语句，都会被MySQL记录，并记录执行时间消耗到哪儿去了。
查看每一条SQL的耗时基本情况：show profiles;
查看指定query_id的SQL语句各个阶段的耗时情况 show profile for query query_id;
查看指定query_id的SQL语句CPU的使用情况 show profile cpu for query query_id;

EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序。

EXPLAIN语法。EXPLAIN命令执行后返回的数据的内容解释。

数据库备份

在InnoDB引擎中，我们可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致性数据备份

数据库中加全局锁，是一个比较重的操作，存在以下问题：
如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆。
如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志（binlog），会导致主从延迟

MySQL中的慢查询日志】
慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有SQL语句的日志。
在MySQL的配置文件（/etc/my.cnf）中配置慢查询日志。

防止MySQL异常重启

1. 定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开 连接，之后要查询再重连。
2. 如果你用的是MySQL 5.7或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection来重新初始化连接资源。这个过程不需要重连和重新做权限验证， 但是会将连接恢复到刚刚创建完时的状态。

关系数据库的混合部署

设计数据库表

设计数据表的原则】

------------《极客时间》
我们在设计数据表的时候，经常会考虑到各种问题，比如：用户都需要什么数据？需要在数据表中保存哪些数据？哪些数据是经常访问的数据？如何提升检索效率？如何保证数据表中数据的正确性，当插入、删除、更新的时候该进行怎样的约束检查？如何降低数据表的数据冗余度，保证数据表不会因为用户量的增长而迅速扩张？
如何让负责数据库维护的人员更方便地使用数据库？
除此以外，我们使用数据库的应用场景也各不相同，可以说针对不同的情况，设计出来的数据表可能千差万别。那么有没有一种设计原则可以让我们来借鉴呢？这里我整理了一个“三少一多”原则：
1.数据表的个数越少越好 RDBMS 的核心在于对实体和联系的定义，也就是 E-R 图（Entity Relationship Diagram），数据表越少，证明实体和联系设计得越简洁，既方便理解又方便操作。
2.数据表中的字段个数越少越好 字段个数越多，数据冗余的可能性越大。设置字段个数少的前提是各个字段相互独立，而不是某个字段的取值可以由其他字段计算出来。当然字段个数少是相对的，我们通常会在数据冗余和检索效率中进行平衡。
3.数据表中联合主键的字段个数越少越好 设置主键是为了确定唯一性，当一个字段无法确定唯一性的时候，就需要采用联合主键的方式（也就是用多个字段来定义一个主键）。联合主键中的字段越多，占用的索引空间越大，不仅会加大理解难度，还会增加运行时间和索引空间，因此联合主键的字段个数越少越好。
4.使用主键和外键越多越好 数据库的设计实际上就是定义各种表，以及各种字段之间的关系。这些关系越多，证明这些实体之间的冗余度越低，利用度越高。这样做的好处在于不仅保证了数据表之间的独立性，还能提升相互之间的关联使用率。
你应该能看出来“三少一多”原则的核心就是简单可复用。简单指的是用更少的表、更少的字段、更少的联合主键字段来完成数据表的设计。可复用则是通过主键、外键的使用来增强数据表之间的复用率。因为一个主键可以理解是一张表的代表。键设计得越多，证明它们之间的利用率越高。

DBMS

DBMS（数据库管理系统）数据库软件应称为DBMS（数据库管理系统）。
数据库是通过DBMS创建和操纵的容器。数据库可以是保存在硬设备上的文件，但也可以不是。在很大程度上说，数据库究竟是文件还是别的什么东西并不重要，因为你并不直接访问数据库；你使用的是DBMS，它替你访问数据库。

DBMS可分为两类：一类为基于共享文件系统的DBMS，另一类为基于客户机—服务器的DBMS。

基于共享文件系统的DBMS（包括诸如Microsoft Access和FileMaker）用于桌面用途，通常不用于高端或更关键的应用。

基于客户机—服务器的数据库:MySQL、Oracle以及Microsoft SQL Server等数据库。客户机—服务器应用分为两个不同的部分。客户机和服务器软件可能安装在两台计算机或一台计算机上，不管它们在不在相同的计算机上，为进行所有数据库交互，客户机软件都要与服务器软件进行通信。

服务器部分是负责所有数据访问和处理的一个软件，这个软件运行在称为数据库服务器的计算机上。与数据文件打交道的只有服务器软件，关于数据、数据添加、删除和数据更新的所有请求都由服务器软件完成，这些请求或更改来自运行客户机软件的计算机。

客户机是与用户打交道的软件，例如，如果你请求一个按字母顺序列出的产品表，则客户机软件通过网络提交该请求给服务器软件，服务器软件处理这个请求，根据需要过滤、丢弃和排序数据；然后把结果送回到你的客户机软件。

使用MySQL，服务器软件为MySQL DBMS，你可以在本地安装的副本上运行，也可以连接到运行在你具有访问权的远程服务器上的一个副本。
客户机可以是MySQL提供的工具、脚本语言（如Perl）、Web应用开发语言（如ASP、ColdFusion、JSP和PHP）、程序设计语言（如C、C++、Java）等。
数据库管理系统DBMS】数据库管理系统是个软件，数据库软件应称为DBMS（数据库管理系统）。数据库是通过DBMS创建和操纵的容器.几乎所有重要的DBMS都支持SQL，所以，学习此语言使你几乎能与所有数据库打交道。你并不直接访问数据库；你使用的是DBMS，它替你访问数据库。有基于 SQL 的数据库，如 Oracle、MySQL、SQL Server、Access、WebSQL、SQLite 等，也有基于 NoSQL 的数据库，比如 MongoDB、Redis 等。DBMS是在操作系统的基础上实现的,数据库中数据的组织和存储是通过操作系统中文件系统来实现的。

建表：
主键的选择：选择创建一个自增主键还是使用表中的字段作为主键？考虑角度：考虑索引的存储机制和查询过程，来考虑这个问题。
一般情况下建议创建一个自增主键，这样非主键索引占用的 空间最小。何时使用业务字段做主键：典型的KV场景：1. 只有一个索引； 2. 该索引必须是唯一索引。由于没有其他索引，所以也就不用考虑其他索引的叶子节点大小的问题。