Java高级工程师常见面试题（八）-数据库MySql

亦凉 2022-01-23 09:39 249阅读 0赞

1. MySql的存储引擎的不同

存储引擎查看

MySQL给开发者提供了查询存储引擎的功能，我这里使用的是MySQL5.1，可以使用：

SHOW ENGINES

![20190603145008962.png][]

如果要想查看数据库默认使用哪个引擎，可以通过使用命令：

SHOW VARIABLES LIKE 'storage\_engine';

来查看，查询结果为：

![20190603145035424.png][]

在MySQL中，不需要在整个服务器中使用同一种存储引擎，针对具体的要求，可以对每一个表使用不同的存储引擎。Support列的值表示某种引擎是否能使用：YES表示可以使用、NO表示不能使用、DEFAULT表示该引擎为当前默认的存储引擎 。

InnoDB存储引擎

InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID），支持行锁定和外键，上图也看到了，InnoDB是默认的MySQL引擎。InnoDB主要特性有：

1、InnoDB给MySQL提供了具有提交、回滚和崩溃恢复能力的事物安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句中提供一个类似Oracle的非锁定读。这些功能增加了多用户部署和性能。在SQL查询中，可以自由地将InnoDB类型的表和其他MySQL的表类型混合起来，甚至在同一个查询中也可以混合

2、InnoDB是为处理巨大数据量的最大性能设计。它的CPU效率可能是任何其他基于磁盘的关系型数据库引擎锁不能匹敌的

3、InnoDB存储引擎完全与MySQL服务器整合，InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB将它的表和索引在一个逻辑表空间中，表空间可以包含数个文件（或原始磁盘文件）。这与MyISAM表不同，比如在MyISAM表中每个表被存放在分离的文件中。InnoDB表可以是任何尺寸，即使在文件尺寸被限制为2GB的操作系统上

4、InnoDB支持外键完整性约束，存储表中的数据时，每张表的存储都按主键顺序存放，如果没有显示在表定义时指定主键，InnoDB会为每一行生成一个6字节的ROWID，并以此作为主键

5、InnoDB被用在众多需要高性能的大型数据库站点上

InnoDB不创建目录，使用InnoDB时，MySQL将在MySQL数据目录下创建一个名为ibdata1的10MB大小的自动扩展数据文件，以及两个名为ib\_logfile0和ib\_logfile1的5MB大小的日志文件

MyISAM存储引擎

MyISAM基于ISAM存储引擎，并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM拥有较高的插入、查询速度，但不支持事物。MyISAM主要特性有：

1、大文件（达到63位文件长度）在支持大文件的文件系统和操作系统上被支持

2、当把删除和更新及插入操作混合使用的时候，动态尺寸的行产生更少碎片。这要通过合并相邻被删除的块，以及若下一个块被删除，就扩展到下一块自动完成

3、每个MyISAM表最大索引数是64，这可以通过重新编译来改变。每个索引最大的列数是16

4、最大的键长度是1000字节，这也可以通过编译来改变，对于键长度超过250字节的情况，一个超过1024字节的键将被用上

5、BLOB和TEXT列可以被索引

6、NULL被允许在索引的列中，这个值占每个键的0~1个字节

7、所有数字键值以高字节优先被存储以允许一个更高的索引压缩

8、每个MyISAM类型的表都有一个AUTO\_INCREMENT的内部列，当INSERT和UPDATE操作的时候该列被更新，同时AUTO\_INCREMENT列将被刷新。所以说，MyISAM类型表的AUTO\_INCREMENT列更新比InnoDB类型的AUTO\_INCREMENT更快

9、可以把数据文件和索引文件放在不同目录

10、每个字符列可以有不同的字符集

11、有VARCHAR的表可以固定或动态记录长度

12、VARCHAR和CHAR列可以多达64KB

使用MyISAM引擎创建数据库，将产生3个文件。文件的名字以表名字开始，扩展名之处文件类型：frm文件存储表定义、数据文件的扩展名为.MYD（MYData）、索引文件的扩展名时.MYI（MYIndex）

MEMORY存储引擎

MEMORY存储引擎将表中的数据存储到内存中，未查询和引用其他表数据提供快速访问。MEMORY主要特性有：

1、MEMORY表的每个表可以有多达32个索引，每个索引16列，以及500字节的最大键长度

2、MEMORY存储引擎执行HASH和BTREE缩影

3、可以在一个MEMORY表中有非唯一键值

4、MEMORY表使用一个固定的记录长度格式

5、MEMORY不支持BLOB或TEXT列

6、MEMORY支持AUTO\_INCREMENT列和对可包含NULL值的列的索引

7、MEMORY表在所由客户端之间共享（就像其他任何非TEMPORARY表）

8、MEMORY表内存被存储在内存中，内存是MEMORY表和服务器在查询处理时的空闲中，创建的内部表共享

9、当不再需要MEMORY表的内容时，要释放被MEMORY表使用的内存，应该执行DELETE FROM或TRUNCATE TABLE，或者删除整个表（使用DROP TABLE）

存储引擎的选择

不同的存储引擎都有各自的特点，以适应不同的需求，如下表所示：

<table> 
 <tbody> 
 <tr> 
 <td> 功&nbsp; 能 </td> 
 <td> MYISAM </td> 
 <td> Memory </td> 
 <td> InnoDB </td> 
 <td> Archive </td> 
 </tr> 
 <tr> 
 <td> 存储限制 </td> 
 <td> 256TB </td> 
 <td> RAM </td> 
 <td> 64TB </td> 
 <td> None </td> 
 </tr> 
 <tr> 
 <td> 支持事物 </td> 
 <td> No </td> 
 <td> No </td> 
 <td> Yes </td> 
 <td> No </td> 
 </tr> 
 <tr> 
 <td> 支持全文索引 </td> 
 <td> Yes </td> 
 <td> No </td> 
 <td> No </td> 
 <td> No </td> 
 </tr> 
 <tr> 
 <td> 支持数索引 </td> 
 <td> Yes </td> 
 <td> Yes </td> 
 <td> Yes </td> 
 <td> No </td> 
 </tr> 
 <tr> 
 <td> 支持哈希索引 </td> 
 <td> No </td> 
 <td> Yes </td> 
 <td> No </td> 
 <td> No </td> 
 </tr> 
 <tr> 
 <td> 支持数据缓存 </td> 
 <td> No </td> 
 <td> N/A </td> 
 <td> Yes </td> 
 <td> No </td> 
 </tr> 
 <tr> 
 <td> 支持外键 </td> 
 <td> No </td> 
 <td> No </td> 
 <td> Yes </td> 
 <td> No </td> 
 </tr> 
 </tbody> 
</table>

如果要提供提交、回滚、崩溃恢复能力的事物安全（ACID兼容）能力，并要求实现并发控制，InnoDB是一个好的选择

如果数据表主要用来插入和查询记录，则MyISAM引擎能提供较高的处理效率

如果只是临时存放数据，数据量不大，并且不需要较高的数据安全性，可以选择将数据保存在内存中的Memory引擎，MySQL中使用该引擎作为临时表，存放查询的中间结果

如果只有INSERT和SELECT操作，可以选择Archive，Archive支持高并发的插入操作，但是本身不是事务安全的。Archive非常适合存储归档数据，如记录日志信息可以使用Archive

使用哪一种引擎需要灵活选择，一个数据库中多个表可以使用不同引擎以满足各种性能和实际需求，使用合适的存储引擎，将会提高整个数据库的性能

2. 单个索引、联合索引、主键索引

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。索引的遵循原则：1、最左侧原则，表的最左侧的一列，往往数据不会发生改变，不影响其他列的数据；2、命名短小原则，索引命名过长会使索引文件变大，损耗内存。

普通索引（由关键字KEY或INDEX定义得到索引）：加快数据的查询速度。

唯一索引（由关键字UNIQUE把它定义为唯一索引）：保证数据记录的唯一性。

主键：一种特殊的唯一索引，在一张表中只能定义一个主键索引，用来标识唯一一条数据，用PRIMARY KEY创建。

联合索引：索引可以覆盖多个数据列，如像INDEX(columnA, columnB)索引，这就是联合索引。

索引可以极大的提高查询访问速度，但是会降低插入，删除，更新表的速度，因为在执行写操作的时候还要操作索引文件。

注意：索引是在存储引擎中实现的，也就是说不同的存储引擎，会使用不同的索引

MyISAM和InnoDB存储引擎：只支持BTREE索引， 也就是说默认使用BTREE，不能够更换

MEMORY/HEAP存储引擎：支持HASH和BTREE索引

联合索引使用结论:

1):查询条件中出现联合索引第一列,或者全部,则能利用联合索引.

2):条件列中只要条件相连在一起,以本文例子来说就是:

last\_name=’1′ and first\_name=’1′与first\_name=’1′ and last\_name=’1′,无论前后,都会利用上联合索引.

3):查询条件中没有出现联合索引的第一列,而出现联合索引的第二列,或者第三列,都不会利用联合索引查询.

单一列索引的应用结论:

1):只要条件列中出现索引列,无论在什么位置,都能利用索引查询.

两者的共同点:

1):要想利用索引,都要符合SARG标准.

2) :都是为了提高查询速度.

3):都需要额外的系统开销,磁盘空间.

补充说明: stmtText信息来产生,在查询语句前面加上:SET STATISTICS PROFILE on.可以通过运行它,来观察你的查询是否合理,这样才能真正做到优化.

优缺点比较:

1):索引所占用空间:单一列索引相对要小.

2):索引创建时间:单一列索引相对短.

3):索引对insert,update,delete的影响程序:单一列索引要相对低.

4):在多条件查询时,联合索引效率要高.

3. Mysql怎么分表，以及分表后如果想按条件分页查询怎么办(如果不是按分表字段来查询的话，几乎效率低下，无解)

例子：

select \* from

(SELECT d2013.\* FROM data\_2013 d2013

WHERE ( d2013.point\_id IN ('16') ) AND ( d2013.collected\_time <= '2014-01-24+09:50' )

UNION

SELECT d2014.\* FROM data\_2014 d2014

WHERE ( d2014.point\_id IN ('16') ) AND ( d2014.collected\_time >= '2013-01-01+00:00' )

) d

INNER JOIN monitor\_point p ON d.point\_id = p.point\_id

INNER JOIN hydro h ON h.hydro\_id = p.hydro\_id

INNER JOIN monitor\_type t ON d.monitor\_type\_id = t.monitor\_type\_id

INNER JOIN agency a ON p.agency\_id = a.id

ORDER BY d.collected\_time

LIMIT 0,30

一些想法：

1.有损服务，只给他查一年内的数据，或者只存1kw条数据。建一个表存一年内的数据，每隔一个月把表最旧的数据迁到分表上面。如果需求方要查所有数据，让他自己选年份去查。

2.先由关键字算出所有年份的总数total，根据前端传来的页面数请求（即limit，start），确定需要查询的数据在哪一个年份，或者数据是多个年份组合出来。

假如

2012 25,2013 40,2014 15 ，共 80条

limit 0,20 ＝>落到2012年，那么只需查2012就够了;

limit 20,20 =>2012 后5条 +2013 15条 以此类推。。

如果再折腾一下，可以以关键字+年份为key，把非当前年份的条数存个cache，减少计算次数

3.最后是无脑union了，应该会很慢

4.如果是针对特定的关键字做报表统计，一次性的那就随意了

果断的选了1，因为老数据基本是没什么人关心的了。

4. 分表之后想让一个id多个表是自增的，效率实现

1、mysql数据中记录；

2、redis的incr；

3、使用队列服务，如redis、memcached等等，将一定量的ID预分配在一个队列里，每次插入操作，先从队列中获取一个ID，若插入失败的话，将该ID再次添加到队列中，同时监控队列数量，当小于阀值时，自动向队列中添加元素。这种方式可以有规划的对ID进行分配，还会带来经济效应，比如ＱＱ号码，各种靓号，明码标价。如网站的userid, 允许uid登陆，推出各种靓号，明码标价，对于普通的ID打乱后再随机分配。

5. MySql的主从实时备份同步的配置，以及原理(从库读主库的binlog)，读写分离

一、主从数据库的区别

从数据库(Slave)是主数据库的备份，当主数据库(Master)变化时从数据库要更新，这些数据库软件可以设计更新周期。这是提高信息安全的手段。主从数据库服务器不在一个地理位置上，当发生意外时数据库可以保存。

(1) 主从分工

其中Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。但是为什么要分离读和写呢？熟悉DB的研发人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。

(2) 基本过程

1)、Mysql的主从同步就是当master（主库）发生数据变化的时候，会实时同步到slave（从库）。

2)、主从复制可以水平扩展数据库的负载能力，容错，高可用，数据备份。

3)、不管是delete、update、insert，还是创建函数、存储过程，都是在master上，当master有操作的时候，slave会快速的接受到这些操作，从而做同步。

(3) 用途和条件

1)、mysql主从复制用途

●实时灾备，用于故障切换

●读写分离，提供查询服务

●备份，避免影响业务

2)、主从部署必要条件：

●主库开启binlog日志（设置log-bin参数）

●主从server-id不同

●从库服务器能连通主库

二、主从同步的粒度、原理和形式：

(1)、 三种主要实现粒度

详细的主从同步主要有三种形式：statement、row、mixed

1)、statement: 会将对数据库操作的sql语句写道binlog中

2)、row: 会将每一条数据的变化写道binlog中。

3)、mixed: statement与row的混合。Mysql决定何时写statement格式的binlog, 何时写row格式的binlog。

(2)、主要的实现原理、具体操作、示意图

1)、在master机器上的操作：

当master上的数据发生变化时，该事件变化会按照顺序写入bin-log中。当slave链接到master的时候，master机器会为slave开启binlog dump线程。当master的binlog发生变化的时候，bin-log dump线程会通知slave，并将相应的binlog内容发送给slave。

2)、在slave机器上操作：

当主从同步开启的时候，slave上会创建两个线程：I\\O线程。该线程连接到master机器，master机器上的binlog dump 线程会将binlog的内容发送给该I\\O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log；sql线程。该线程读取到I/O线程写入的ralay log。并且根据relay log。并且根据relay log 的内容对slave数据库做相应的操作。

3)、MySQL主从复制原理图如下:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70][]

从库生成两个线程，一个I/O线程，一个SQL线程；

i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；

主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；

SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

(2)、主从形式

mysql主从复制 灵活

● 一主一从

● 主主复制

● 一主多从---扩展系统读取的性能，因为读是在从库读取的；

● 多主一从---5.7开始支持

● 联级复制---

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 1][]

三、主从同步的延迟等问题、原因及解决方案：

(1)、mysql数据库从库同步的延迟问题

1）相关参数：

首先在服务器上执行show slave satus;可以看到很多同步的参数：

Master\_Log\_File： SLAVE中的I/O线程当前正在读取的主服务器二进制日志文件的名称 Read\_Master\_Log\_Pos： 在当前的主服务器二进制日志中，SLAVE中的I/O线程已经读取的位置 Relay\_Log\_File： SQL线程当前正在读取和执行的中继日志文件的名称 Relay\_Log\_Pos： 在当前的中继日志中，SQL线程已读取和执行的位置 Relay\_Master\_Log\_File： 由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称 Slave\_IO\_Running： I/O线程是否被启动并成功地连接到主服务器上 Slave\_SQL\_Running： SQL线程是否被启动 Seconds\_Behind\_Master： 从属服务器SQL线程和从属服务器I/O线程之间的时间差距，单位以秒计。

从库同步延迟情况出现的 ● show slave status显示参数Seconds\_Behind\_Master不为0，这个数值可能会很大 ● show slave status显示参数Relay\_Master\_Log\_File和Master\_Log\_File显示bin-log的编号相差很大，说明bin-log在从库上没有及时同步，所以近期执行的bin-log和当前IO线程所读的bin-log相差很大 ● mysql的从库数据目录下存在大量mysql-relay-log日志，该日志同步完成之后就会被系统自动删除，存在大量日志，说明主从同步延迟很厉害

(2)、MySql数据库从库同步的延迟问题

1)、MySQL数据库主从同步延迟原理mysql主从同步原理：主库针对写操作，顺序写binlog，从库单线程去主库顺序读”写操作的binlog”，从库取到binlog在本地原样执行（随机写），来保证主从数据逻辑上一致。mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave\_IO\_Running线程到主库取日志，效率比较高，下一步，问题来了，slave的Slave\_SQL\_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave\_SQL\_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave\_SQL\_Running线程却不可以。

2)、MySQL数据库主从同步延迟是怎么产生的？当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。首要原因：数据库在业务上读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高次要原因：读写binlog带来的性能影响，网络传输延迟。

(3)、MySql数据库从库同步的延迟解决方案

1)、架构方面

1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。

2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。

3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。

4.不同业务的mysql物理上放在不同机器，分散压力。

5.使用比主库更好的硬件设备作为slave总结，mysql压力小，延迟自然会变小。

2)、硬件方面

1.采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。

2.存储用ssd或者盘阵或者san，提升随机写的性能。

3.主从间保证处在同一个交换机下面，并且是万兆环境。

总结，硬件强劲，延迟自然会变小。一句话，缩小延迟的解决方案就是花钱和花时间。

3)、mysql主从同步加速

1、sync\_binlog在slave端设置为0

2、–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。

3、直接禁用slave端的binlog

4、slave端，如果使用的存储引擎是innodb，innodb\_flush\_log\_at\_trx\_commit =2

4)、从文件系统本身属性角度优化

master端修改linux、Unix文件系统中文件的etime属性， 由于每当读文件时OS都会将读取操作发生的时间回写到磁盘上，对于读操作频繁的数据库文件来说这是没必要的，只会增加磁盘系统的负担影响I/O性能。可以通过设置文件系统的mount属性，组织操作系统写atime信息，在linux上的操作为：打开/etc/fstab，加上noatime参数/dev/sdb1 /data reiserfs noatime 1 2然后重新mount文件系统\#mount -oremount /data

5)、同步参数调整主库是写，对数据安全性较高，比如sync\_binlog=1，innodb\_flush\_log\_at\_trx\_commit = 1 之类的设置是需要的而slave则不需要这么高的数据安全，完全可以讲sync\_binlog设置为0或者关闭binlog，innodb\_flushlog也可以设置为0来提高sql的执行效率

1、sync\_binlog=1 oMySQL提供一个sync\_binlog参数来控制数据库的binlog刷到磁盘上去。默认，sync\_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。一旦系统Crash，在binlog\_cache中的所有binlog信息都会被丢失。

如果sync\_binlog>0，表示每sync\_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync\_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。但是binlog虽然是顺序IO，但是设置sync\_binlog=1，多个事务同时提交，同样很大的影响MySQL和IO性能。虽然可以通过group commit的补丁缓解，但是刷新的频率过高对IO的影响也非常大。

对于高并发事务的系统来说，“sync\_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。所以很多MySQL DBA设置的sync\_binlog并不是最安全的1，而是2或者是0。这样牺牲一定的一致性，可以获得更高的并发和性能。默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，你可以使用sync\_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘同步。即使sync\_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。

2、innodb\_flush\_log\_at\_trx\_commit （这个很管用）抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。

3、ls(1) 命令可用来列出文件的 atime、ctime 和 mtime。

atime 文件的access time 在读取文件或者执行文件时更改的ctime 文件的create time 在写入文件，更改所有者，权限或链接设置时随inode的内容更改而更改mtime 文件的modified time 在写入文件时随文件内容的更改而更改ls -lc filename 列出文件的 ctimels -lu filename 列出文件的 atimels -l filename 列出文件的 mtimestat filename 列出atime，mtime，ctimeatime不一定在访问文件之后被修改因为：使用ext3文件系统的时候，如果在mount的时候使用了noatime参数那么就不会更新atime信息。这三个time stamp都放在 inode 中.如果mtime,atime 修改,inode 就一定会改, 既然 inode 改了,那ctime也就跟着改了.之所以在 mount option 中使用 noatime, 就是不想file system 做太多的修改, 而改善读取效能

(4)、MySql数据库从库同步其他问题及解决方案

1)、mysql主从复制存在的问题：  ● 主库宕机后，数据可能丢失  ● 从库只有一个sql Thread，主库写压力大，复制很可能延时2)、解决方法：  ● 半同步复制---解决数据丢失的问题  ● 并行复制----解决从库复制延迟的问题

3)、半同步复制mysql semi-sync（半同步复制）半同步复制：  ● 5.5集成到mysql，以插件的形式存在，需要单独安装  ● 确保事务提交后binlog至少传输到一个从库  ● 不保证从库应用完这个事务的binlog  ● 性能有一定的降低，响应时间会更长  ● 网络异常或从库宕机，卡主主库，直到超时或从库恢复4)、主从复制--异步复制原理、半同步复制和并行复制原理比较

a、异步复制原理：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 2][]

b、半同步复制原理：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 3][]

事务在主库写完binlog后需要从库返回一个已接受，才放回给客户端；5.5集成到mysql，以插件的形式存在，需要单独安装确保事务提交后binlog至少传输到一个从库不保证从库应用完成这个事务的binlog性能有一定的降低网络异常或从库宕机，卡主库，直到超时或从库恢复

c、并行复制mysql并行复制  ● 社区版5.6中新增  ● 并行是指从库多线程apply binlog  ● 库级别并行应用binlog，同一个库数据更改还是串行的(5.7版并行复制基于事务组)设置set global slave\_parallel\_workers=10;设置sql线程数为10

原理：从库多线程apply binlog在社区5.6中新增库级别并行应用binlog，同一个库数据更改还是串行的5.7版本并行复制基于事务组

6. 写SQL语句。。。

略

7. 索引的数据结构，B+树

mysql索引主要是基于Hash表和B+树的数据结构，

首先，数据库使用树型结构来增加查询效率，并保持有序。那么，为什么不使用二叉树来实现数据结构呢，二叉树算法时间复杂度是lg(N)，查询速度和比较次数都是较小的。

实际上，查询索引操作最耗资源的不在内存中，而是磁盘IO。索引是存在磁盘上的，当数据量比较大的时候，索引的大小可能达到几个G。那么，我们利用索引进行查询的时候，不可能把索引直接加载到内存中，只能一次读取一个磁盘页，一个磁盘页对应着一个节点，一次读取操作时一个磁盘io。

在二叉树查询时，最坏的情况下查找的次数是树的高度，即io次数为树的高度。B-树就是比二叉树“矮胖”的树。

二叉树的特征如下：

1. 根节点至少有两个子女

2. 每个中间节点包含k-1个元素和k个孩子，其中 m/2 <= k <= m

3. 每个叶子节点包含k-1个元素，其中 m/2 <= k <= m

4. 所有叶子节点位于同一层

5. 节点中的元素从小到大排列，正好是孩子节点的值域。（就是孩子节点的元素都比父节点中元素的最小值大，比父节点元素的最大值小）

B-树查询的次数并不比二叉树的次数小，但是相比起磁盘io速度，内存中比较的耗时就不足为提了。所以只要树的高度足够低，io次数少，就可以提升查找性能。而每个节点中有多个元素，都只在内存中操作。

而B+树是基于B-树的，增加了如下规则：

1. 有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。

2. 所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。

3. 所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。

所以，B+树对比B-树有如下好处：

io次数少：b+树中间节点只存索引，不存在实际的数据，所以可以存储更多的数据。索引树更加的矮胖，io次数更少。

性能稳定：b+树数据只存在于叶子节点，查询性能稳定

范围查询简单：b+树不需要中序遍历，遍历链表即可。

8. 事务的四个特性，以及各自的特点（原子、隔离）等等，项目怎么解决这些问题

参考：[https://blog.csdn.net/u014378181/article/details/79236774][https_blog.csdn.net_u014378181_article_details_79236774]

9. 数据库的锁：行锁，表锁；乐观锁，悲观锁

mysql为什么提供锁：防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决。

锁，在现实生活中是为我们想要隐藏于外界所使用的一种工具。在计算机中，是协调多个进程或县城并发访问某一资源的一种机制。在数据库当中，除了传统的计算资源（CPU、RAM、I/O等等）的争用之外，数据也是一种供许多用户共享访问的资源。如何保证数据并发访问的一致性、有效性，是所有数据库必须解决的一个问题，锁的冲突也是影响数据库并发访问性能的一个重要因素。从这一角度来说，锁对于数据库而言就显得尤为重要。

MySQL锁

相对于其他的数据库而言，MySQL的锁机制比较简单，最显著的特点就是不同的存储引擎支持不同的锁机制。根据不同的存储引擎，MySQL中锁的特性可以大致归纳如下：

<table> 
 <tbody> 
 <tr> 
 <td> &nbsp; </td> 
 <td> 行锁 </td> 
 <td> 表锁 </td> 
 <td> 页锁 </td> 
 </tr> 
 <tr> 
 <td> MyISAM </td> 
 <td> &nbsp; </td> 
 <td> √ </td> 
 <td> &nbsp; </td> 
 </tr> 
 <tr> 
 <td> BDB </td> 
 <td> &nbsp; </td> 
 <td> √ </td> 
 <td> √ </td> 
 </tr> 
 <tr> 
 <td> InnoDB </td> 
 <td> √ </td> 
 <td> √ </td> 
 <td> &nbsp; </td> 
 </tr> 
 </tbody> 
</table>

开销、加锁速度、死锁、粒度、并发性能

表锁：

开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低

行锁：

开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高

页锁：

开销和加锁速度介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般

从上述的特点课件，很难笼统的说哪种锁最好，只能根据具体应用的特点来说哪种锁更加合适。仅仅从锁的角度来说的话：

表锁更适用于以查询为主，只有少量按索引条件更新数据的应用；行锁更适用于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用。

深入了解：[https://blog.csdn.net/mysteryhaohao/article/details/51669741][https_blog.csdn.net_mysteryhaohao_article_details_51669741]

10. 数据库事务的几种粒度；

参考：[https://blog.csdn.net/u014378181/article/details/79236774][https_blog.csdn.net_u014378181_article_details_79236774]

11. 关系型和非关系型数据库区别

一、关系型数据库

![20190603145544409.png][]

关系型数据库最典型的数据结构是表，由二维表及其之间的联系所组成的一个数据组织

优点：

1、易于维护：都是使用表结构，格式一致；

2、使用方便：SQL语言通用，可用于复杂查询；

3、复杂操作：支持SQL，可用于一个表以及多个表之间非常复杂的查询。

缺点：

1、读写性能比较差，尤其是海量数据的高效率读写；

2、固定的表结构，灵活度稍欠；

3、高并发读写需求，传统关系型数据库来说，硬盘I/O是一个很大的瓶颈。

二、非关系型数据库

![2019060314555814.png][]

非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合，可以是文档或者键值对等。

优点：

1、格式灵活：存储数据的格式可以是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，使用灵活，应用场景广泛，而关系型数据库则只支持基础类型。

2、速度快：nosql可以使用硬盘或者随机存储器作为载体，而关系型数据库只能使用硬盘；

3、高扩展性；

4、成本低：nosql数据库部署简单，基本都是开源软件。

缺点：

1、不提供sql支持，学习和使用成本较高；

2、无事务处理；

3、数据结构相对复杂，复杂查询方面稍欠。

非关系型数据库的分类和比较：

1、文档型

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 4][]

2、key-value型

![20190603145623452.png][]

3、列式数据库

![20190603145634685.png][]

4、图形数据库

![20190603145645305.png][]

[20190603145008962.png]: /images/20220123/8297c72709d44400bb7cbc7287e8373d.png
[20190603145035424.png]: /images/20220123/9b63d97274954c36b3254d318a98c61b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70]: /images/20220123/a1403d5400ad4efe9652bb02365273c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 1]: /images/20220123/d18fddc5c5484fb691555f2a3bfcdabd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 2]: /images/20220123/b283d0b9e70744d0a00909182563e27d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 3]: /images/20220123/956de71d718d4d1093c22d8d178f2bc8.png
[https_blog.csdn.net_u014378181_article_details_79236774]: https://blog.csdn.net/u014378181/article/details/79236774
[https_blog.csdn.net_mysteryhaohao_article_details_51669741]: https://blog.csdn.net/mysteryhaohao/article/details/51669741
[20190603145544409.png]: /images/20220123/9dcabe0f1cbb4a8dbb50e9d7ed26ff2d.png
[2019060314555814.png]: /images/20220123/dea714f07b944e4fb77610ee1d0b0f9a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQzNzgxODE_size_16_color_FFFFFF_t_70 4]: /images/20220123/d85d843911744f78b7cc7fd9d52169aa.png
[20190603145623452.png]: /images/20220123/cce7af9c8cf44e979099fa8f9b7bfabe.png
[20190603145634685.png]: /images/20220123/d1b2b96cba484293985112914a4a1225.png
[20190603145645305.png]: /images/20220123/1072890ad0f24d688538e854fa71d922.png