一:什么是库 数据库是一个长期存储在计算机内，有组织的，有共享的，统一化管理数据集合。 它简便而言之就是一个数据存储仓库，为了方便数据存储和管理，它将数据按照特定的规律存储在磁盘上。通过数据库管理系统，可以有效的组织和管理存储在数据中的数据。

通过上面三种方法创建的新用户还不能直接登录到MySQL，我们需要刷新权限才可以登录：FLUSH PRIVLEGES；

重启mysql，重启mysql也会产生二进制日志，flush logs 也会出现二进制日志。

二进制日志默认和mysql数据目录下（/var/mysql），我们也可以自定义。

MySQL二进制日志存储了所有变更信息，mysql二进制日志经常使用。。当mysql创建二进制日志文件时，首先创建一个以‘filename’（默认bin-log）为名称，以‘index’为后缀的索引文件（这个文件是用来记录二进制日志的文件名的）；在创建一个以‘filename’为名称，以‘000001’为后缀日志文件。当mysql服务重启一次，以‘000001’为后缀的文件会增加一个，并且后缀加1递增，如果日志长度超过max_binlog_size的上限，也会创建一个新的日志。

show binary/master logs；可以查看当前的二进制日志文件个数及其文件名。 想要查看二进制内容，需要通过mysqlbinlog工具。

【删除二进制日志】 mysql的二进制文件可以匹配自动删除，也可以手动删除：

【暂时停止二进制日志的功能】 如果mysql的配置文件已经启动了二进制日志，mysql会一直记录二进制日志，修改配置文件，可以停止二进制日志，但是需要从起mysql。mysql提供了暂时停止二进制日志的功能，通过SET SQL_LOG_BIN语句可以是mysql暂时停止二进制 mysql>SET SQL_LOG_BIN=0； 暂停二进制

错误日志： 错误日志文件包含了当mysql启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

设置错误日志： 在默认的情况下错误日志是开启的，它默认被记录到数据目录下/var/mysql/data/。如果，没有在配置文件中指定文件名，文件默认为f中添加 log-error=路径/文件名 来自定义错误日志文件。

【查看错误日志的存储路径】 通过错误日志可以见识系统的运行状态，便于即使发现故障、修复故障。mysql错误日志是以文本文件的形式存储的，可以使用文本编辑器直接查看；

删除错误日志： mysql的错误日志是以文本文件的形式存储的，可以直接删除。 在运行状态下删除错误日志文件后，则会自动创建。

一般查询日志： 它记录了所有用户的操作，宝库启动和关闭服务、执行查询和更新语句等。mysql默认没有开启 一般查询日志。如果需要可以修改f里添加log = /路径/文件名。一般查询 日志是以文本格式文件存储的，日知名.Pid。 可以直接删除。开启一般查询并且mysql服务在 运行状态下，删除了日志文件，它会自动创建新的。

慢查询日志： 慢查询日志是记录查询时长超过指定时间的日志。慢查询日志主要用来优化查询语句的。慢查询 日志默认是关闭的，我们可以修改配置文件来开启： [mysqld] log-slow-queries //开启慢查询 long_query_time = 1 //设置慢查询时间，默认10秒

查看慢查询日志 MySQL慢查询日志是以文本文件的形式存储的，可以直接使用文本编辑器查看。 删除慢查询日志可以直接删除。删除后不再重启服务器的情况，需要执行 mysqladmin -u root -p flush-logs 重新生成日志文件，或者在客户端登陆到服务器执行 flush logs语句重建日志文件。

MySQL主从复制概念MySQL主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接

MySQL主从复制主要用途读写分离 在开发工作中，有时候会遇见某个sql语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样即使主库出现了

MySQL主从形式：一主一从、一主多从、多主一从、双主复制、 一主一从和一主多从

杜兴宇 16:04:50 MySQL 主从复制概念MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。 MySQL 主从复制主要用途l 读写分离 在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。 l 数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换

我正在开发一个新的游戏项目,包括一个React Native前端和一个基于Lambda的后端.该应用程序需要一些实时功能,如活动用户记录,地理围栏等.

我正在研究Firebase的实时数据库,它看起来像是一个非常优雅的实时数据同步解决方案,但我不认为AWS有任何类似的东西.

我只能使用AWS服务来考虑"无服务器"实时的3个选项是:

这一点非常明显,通过IoT SDK实现了托管WebSockets连接.我正在考虑触发Lambdas以响应入站和出站事件,并且只使用WebSockets作为实时层,就像通常那样在应用客户端上构建自定义处理逻辑.

至少与Firebase相比,这方面的缺点是我将不得不自己处理事件中的数据,这将在WebSockets之上添加另一层管理,并且必须使用应用程序商店中的API数据层进行标准化. .

• 仅在应用程序打开时有效

选项2:推送触发重新获取

另一种选择是使用推送通知作为实时触发器,但使用常规HTTP请求到API网关实际获取更新的有效负载.

我喜欢这种方法,因为它只适用于一个传输层和应用程序状态的单一事实来源.当应用程序未打开时,它也会触发更新,因为这些是推送通知.

缺点是这是很多自定义工作,在推送通知与需要获取的数据之间可能存在困难的映射.

• 即使应用关闭,推送通知仍然有效
• 单一的事实来源,传输层

• 将涉及更多的整体HTTP请求

选项3:Cognito Sync 这对我来说比较新,我不确定它是否可以与服务器实际连接.

Cognito Sync提供用户状态同步.跨设备完成离线支持,是我将要使用的Cognito SDK的一部分.这听起来就像我正在寻找但却无法找到任何确凿的证据,因为它可以修改或"触发"来自AWS的更新,而不仅仅是来自其中一个设备.

• 提供抽象的实时数据模型

• 不确定是否可以从Lambdas修改或更新

我想知道是否有人有经验在AWS上实时作为基于Lambda的架构的一部分,如果你对什么是最好的方法有意见？

详细看这里吧，太多字懒得打了

7.MYSQL索引讲一下，为什么B+树更好？B+树与B树的差别在哪里？

1.有k个元素的中间节点的包含k个元素(b树中是k个元素),中间节点的每个元素不保存数据,数据存储在叶子上面

2.叶子节点包含了全部元素的信息，以及指向含这些元素记录的指针。

3.所有的叶子接点都同时存在于子接点，在子接点中是最大(或最小)的元素

8.B+树相对于B树的优势：

1.单一节点存储更多的元素，使得查询的IO次数更少；
　　2.所有查询都要查找到叶子节点，查询性能稳定；
　　3.所有叶子节点形成有序链表，便于范围查询。

9,mysql各个数据类型有什么需要注意的地方

读未提交(会产生脏读)

(A事务读取了B事务未提交的数据)

解决方法:在事务提交前,不允许读取其修改后的数据

读已提交(会产生不可重复读)

修改事务完全提交后，才可以读取数据，就可以解决不可重复读

可重复读(会产生幻读)

解决方法:在其他操作事务完成数据处理之前，任何其他新事务都不可以添加新数据，可以避免该问题(只允许一个事务进行)

(一次只运行一个事务进行)

1.中间节点会在子节点中冗余一份，而且在子节点中是最大(或最小的)

2.叶子结点存的数据，而且数据之间有双向指针把数据连接在一起

2.b+树的增删改查？

在索引列上进行运算操作，索引将失效

字符串类型字段使用时,不加引号，索引将失效

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

用or分割开的条件，如果or前的条件中有索引，后面的列中没有索引，那么涉及的索引都不会被用到。

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

14.存储引擎知道哪些,有哪些索引，底层是什么实现的

空间索引(针对空间的数据结构建立的索引)

原子性是指一个事务是一个不可分割的整体，内部的操作要么都做，要么都不做，所以说，实现原子性的核心就在于如何实现回滚

事务执行的结果是数据库从一个一致性状态变到另一个一致状态，即数据库完整性没有被破坏，事务执行的前后都是合法的状态

(数据完整性包括但不限于，实体完整性，如行的主键存在且唯一，列完整性如字段的类型，大小，长度要符合要求，外键约束，用户自定义完整性)

事物内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

持久性是指事务一旦提交，他对数据库的改变就是永久的，接下来的其他操作不对应该对其有任何影响，并且不能回滚

1.保证原子性，持久性，隔离性，如果这些无法保证，事务的一致性也无法保证

2.数据库本身提供保障，例如不运行向整行列插入字符串值，字符串长度不能超过列的限制等

3.应用层面进行保障，例如如果转账操作只扣除转账者的劲儿，二没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致性

1.一个事务写操作对另外一个事务写操作的影响:锁机制保证隔离性

2.一个事务写操作对另外一个事务读操作的影响:MVVC保证隔离性

数据是放在磁盘的，但是如果每次读写数据都需要磁盘io，效率会很低，为此，Innodb提供了缓存，bp中包含了部分数据页的映射，作为访问数据库的缓冲，当从数据库读取数据时，会首先写入BP，BP中修改的数据会定期刷新到磁盘中(这一过程称为刷脏)

BP的使用打打提高了读写数据的效率，但是也带来了新的问题，如果MYSQL宕机，而此时BP中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性就无法保证。

redo log就被引入来解决这个问题(宕机导致BP中的数据没有刷新磁盘，造成数据丢失)当数据被修改时，除了修改BP中的数据，还会在redo log中记录这次操作

当事务提交是，会调用fsync接口对redo log 进行刷盘，如果MYSQL宕机，重启时可以读取redo log 中的数据，对数据库进行恢复，redo log 采用的是 WAL(write-ahead logging,预写式日志)所有修改先写入日志，在更新到BP，保证了数据不会因为MYSQL宕机而丢失，从而满足了持久性的要求。

将数据库设定为多主模式，这样每次新增数据都会去做同步这样避免生成一样的iad

4.自动增长列(也被称为升级版本号段模式)

设置起始值和步长(缺点是需要规定数据库个数)

18mysql索引慢分析:线上开启slowlog，提取慢查询，然后仔细分析explain中type字段以及extra字段，发生的具体场景以及mysql是怎么做的?

19mysql分表分库平滑扩容方案

2.同步完成后进行主主双写

3.删除双主同步，修改数据库配置并重启(秒级)

4.清空数据库中多余数据

2.需要考虑分布式id的问题见问题17，避免数据库id重复

20隔离级别，sql慢查询

21对mysql的设计掌握如何(应该是范式那些东西)

23.存储引擎了解哪些？

25mysql主键索引和非主键索引在搜索和检索的过程中有什么区别吗

在innodb中普通索引只包含主键id需要回表查询，而myisam则不需要，因为存的都是数据

26mysql如何实现事务的？(复习)

27.mysql主从同步过程了解吗？

1.中间节点只保存索引，并且在子节点中冗余一份，而且是子节点数据中的最小(或最大)值

2.叶子节点存储的是数据，并且通过双向链表链接起来

31mysql事务的隔离级别,分别解决了什么问题

可重复读(不可重复读)

39mysql根据多列构造索引(实践题吧…)

40mysql索引结构为什么不用跳表(这个因为上面一个问题问到的是zset为什么用的是跳表)

41mysql有哪些存储引擎，你用到的是什么存储引擎,区别是什么

43.mysql索引，联合索引，索引失效，左连接

2.索引失效(复习题12)

5.数据分布影响(如果全表更快的话就不走索引)

45.为什么项目的数据库要用到mysql innodb特性底层了解吗数据分区，怎么加快读写效率

55mysql ab 两个分别建立索引会更快吗

56.mysql主从复制以及好处，工作原理和机制

1.数据更安全:做了数据冗余，不会因为单台服务器的宕机而丢失数据

2.性能大大提升:一主多从，不同用户从不同数据库读取，性能提升

3.扩展性更优:流量增大时，可以方便的增加从服务器，不影响系统使用

4.负载均衡:一主多从相当于分担了主机任务，做了负载均衡

2.发扬不同表引擎的优点

1.slave端的io线程链接上master端，并请求从制定binlog日志文件指定的pos节点位置(或则从最开始)开始复制之后的日志内容

2.master端在接受到来自slave端的io线程请求后，通知负责复制线程的io线程，根据slave端io线程的请求信息，读取制定binlog日志指定pos节点位置之后的日志信息，然后放回给slave端的io线程。该放回信息中除了binlog日志所包含的信息之外，还包括本次返回信息在master端的binlog文件名以及在binlog日志中的pos节点位置(便于下次同步)

3.slave端的io线程在接受到master端io放回的信息后，将接收到的binlog日志内容依次写入到slave端的relaylog文件(mysql-reply-bin.xxx)的最末端，并将读取到的master端的binlog文件名和pos节点的位置记录到master-info(该文件存在slave端)文件中，以便在下一次读取的时候能够qingchude告诉masrer，我需要从那个binlog文件的哪个pos节点位置开始，请把此节点后的日志内容发给我。

4.slave的sql线程在检测到relaylog文件中新增内容后，会马上解析该log文件中的内容。然后还原成在master端真正执行的那些sql语句，并在自身按顺序依次执行这些sql语句。这样实际上就是master端真正执行的那些sql语句，并在自身按顺序执行这些sql语句。这样，实际上就是master端和slave端执行了同样的sql语句，所以master端和slave端是完全一样的

1.主从间的数据库不是实时同步，就算网络连接正常，也能存在主从数据不一致的情况

2.如果主从的网络断开，则从库会在网络恢复正常后，批量进行同步。

3.如果对从库进行修改数据，那么如果此时从库正在执行主库的binlog时，则会出现错误而停止同步，这是一个很危险的操作，所以一般情况下，我们要非常小心的修改从库上的数据。

57.mysql引擎，索引数据结构，为什么用b+树不用别的（复习）

60.说下mysql的索引结构?b+树和红黑对比下

61.mysql聚簇索引？(复习)联合索引?为什么会有最左匹配原则？

联合索引本质，创建(a,b,c) 的时候，相当于创建了(a)单列索引(a,b)联合索引以及(a,b,c)联合索引，想要索引生效的话，只能使用a和a,b和a,b,c三种组合当然，我们上面测试过，a,c也会走索引但是实际上只用到了a的索引，c并没有用到

但是如果在a相同的情况下，b也是有顺序的

65.mysql索引知道哪些，底层是怎么实现的(复习)

67.mysql的事务隔离级别，mysql acid 回表，普通索引和唯一索引的区别；mysql最左匹配原则

72zookeeper，mysql，redis怎么实现分布式锁，各有什么优缺点，生产中一般用哪个

73mysql查询速度慢如何优化，如何添加索引(覆盖索引/前缀匹配)

75mysql默认使用哪个隔离级别

78mysql把时间戳转化成日常格式时间的函数

80mysql怎么去查询的，什么时候走索引，什么时候不走

86mysql有哪些索引，介绍一下b+树具体的结构

87mysql索引分类分别说一下

92聚簇索引和非聚簇索引有什么区别

96mysql的两个引擎及使用场景

97怎么查看优化mysql语句耗时操作

98mysql的索引，为什么是b+树而不是平衡二叉树

99mysql的io过高怎么优化，分库分表以及分区

101请说一下mysql的事务隔离级别

103什么情况下会导致索引失效

104mysql底层有几种实现方式

107mysql常见引擎的区别，mvvc机制是干嘛的

108索引失效的几个场景

很好理解，就是服务运行过程中发生的严重错误日志。但我们的数据库无法启动时，就可以来这里看看具体不能启动的原因是什么

它有另外一个名字你应该熟悉，叫Binlog，其记录了对数据库所有的更改

记录了来自客户端的所有语句

这里记录了所有响应时间超过阈值的SQL语句，这个阈值我们可以自己设置，参数为long_query_time，其默认值为10s，且默认是关闭的状态，需要手动的打开。

117如何解决mysql高并发的问题

119mysql多事务操作会有哪些问题，具体解释一下，对应的有哪些事务隔离级别，怎么实现的（MVCC，版本链+undo log+read view）

120通过慢查询(explain)哪些字段可以判断优化

121mysql为什么往往以集群提供服务，扩容会有什么问题

122mysql的表级锁和行级锁是悲观锁还是乐观锁

123mysql的分表是怎么处理的

126查看mysql死锁用什么命令

130一亿人中怎么找身份证

它有另外一个名字你应该熟悉，叫Binlog，其记录了对数据库所有的更改

记录了来自客户端的所有语句

这里记录了所有响应时间超过阈值的SQL语句，这个阈值我们可以自己设置，参数为long_query_time，其默认值为10s，且默认是关闭的状态，需要手动的打开。

117如何解决mysql高并发的问题

119mysql多事务操作会有哪些问题，具体解释一下，对应的有哪些事务隔离级别，怎么实现的（MVCC，版本链+undo log+read view）

120通过慢查询(explain)哪些字段可以判断优化

121mysql为什么往往以集群提供服务，扩容会有什么问题

122mysql的表级锁和行级锁是悲观锁还是乐观锁

123mysql的分表是怎么处理的

126查看mysql死锁用什么命令

130一亿人中怎么找身份证