上一篇传送门：点我

Mysql是java知识体系中的一个重难点，本文仅是部分问题，后续会进行修改补充。

SQL语句

创建数据库（如果数据库不存在创建）
create database if not exists db_name;
查看所有数据库
show databases;
查看某个数据库信息
show create database db_name;
删除数据库
drop database db_name;
创建表
create table if not exists 表名 (
列1 数据类型 constraint 约束名 primary key, – 主键约束
列2 数据类型 constraint 约束名 default 默认值, – 添加默认值约束
列3 数据类型 constraint 约束名 not null, – 非空约束
列4 数据类型,
…
constraint 约束名 foreign key (列名)references 另一个表(列名) – 外键约束
);
查看某张表
show create table 表名;
修改表名
alter table 表名 rename to 新的表名;
添加一列
alter table 表名 add 列名 数据类型;
删除某列
alter table 表名 drop 列名;
删除表
drop table if exists 表名 ;
对表指定列增加数据
insert into 表名(列名1,列名2,…列名n) values(值1,值2,…值n);
对表全部列增加数据
insert into 表名 values (值1,值2,…,值n);​
删除表中符合条件数据
delete from 表名 where 列名 = 值;
删除表中所有数据
delete from 表名;
删除表中所有数据
truncate table 表名;（高效方法： 先删除表，然后再创建一张一样的表。和delete的区别是，而truncate操作后可以设置为自动增长的Id可以从0开始，而delete不可以，truncate的操作速度会比delete更快）
不带条件的修改(会修改所有行)
update 表名 set 列名 = 值;
带条件的修改
update 表名 set 列名 = 值 where 列名=值;
一般的条件查询
select * from 表名 where 条件
升序/降序查
语句末尾加上 order by 列名 asc/desc;
表示区间的查询条件
between … and …
表示集合
in(值列表)
表示单个任意字符（例如查询姓王的名字为两个字的人）
select * from student WHERE NAME LIKE ‘王_’;
表示多个任意字符（例如查询姓王的人）
select * from student WHERE NAME LIKE ‘王%’;
聚合函数
count（计算个数）、max（计算最大值）、min（计算最小值）、sum（计算和）、avg（计算平均数）
分组（与聚合函数配合使用）
group by 列名
左（外）连接
左连接：select * from a left join b on a.id =b.id;
以左表为基础，根据on后给出的两表的条件将两表连接起来。结果会将左表所有的查询信息列出，而右表只列出on后条件与左表满足的部分。
右（外）连接
右连接：select * from a right join b on a.id=b.id;
以右表为基础，根据on后给出的两表的条件将两表连接起来。结果会将右表所有的查询信息列出，而左表只列出on后条件与右表满足的部分。
内连接
内连接：select * from a inner join b on a.id=b.id;
同时将两表作为参考对象，根据on后给出的两表的条件将两表连接起来，结果则是两表同时满足on后的条件的部分才会列出，这和where效果基本一致。

where由于要先把两张表（笛卡尔积，n*m条记录）都加载到内存中创建一个临时表，所以比较占用资源。join 会先判断数据行是否符合on语句后面的条件，再决定是否join,不创建临时表，所以占用的资源相比where更少。
创建简单索引
//在表上创建一个简单的索引，允许使用重复的值
create index index_name
on table_name (column_name); //“column_name” 规定需要索引的列
创建唯一索引
//在表上创建一个唯一的索引，唯一的索引意味着两个行不能拥有相同的索引值。
create unique index index_name
on table_name (column_name);
在表中的多个列上创建联合索引
create index index_name
on table_name (column_name1, column_name2, …);

为什么SQL语句不要用过多的join？

SQL语句不要用过多的join，原因主要有以下两方面：
1.性能问题：每个join操作都需要对两个或多个表进行连接操作，这些操作需要消耗大量的计算资源和时间，如果join操作过多或是操作的表涉及大量的数据，会导致SQL的执行效率变低，从而影响整个系统的性能；
2.可读性和维护性问题：join操作会使得SQL语句变得复杂，难以理解和维护，特别是当join操作涉及到多个表的时候，SQL语句的复杂度会呈现指数的增长。这会给代码的可读性和维护性带来挑战。

为什么SQL语句要尽量避免使用select *？

这个问题个人理解是在当需要查询的表存在大字段时，例如tinytext、text、mediumtext、longtext、tinybob、blob、mediumblob、longblob等，如果是一个比较多字段的表，例如意见反馈表，这里的内容需要不定长，所以用了text。这时候如果对该表的查询用了select*，这个查询可能不需要查出这些大字段，这个时候的造成的不必要磁盘IO开销就会变得非常大。
如果本来只查询某1，2个比较常用的字段的，可以给这些字段建单个索引或者组合索引 ，这时候查询就避免使用select*，因为使用select*无法触发覆盖索引，而尽量触发覆盖索引可以极大程度加快查询速度。

为什么Mysql不建议用delete删除数据？

在实际场景中，使用delete操作可能会有一些潜在的风险，需要谨慎操作。一些情况下，使用delete可能会对数据的完整性和安全性产生影响。例如，在使用delete时忘记加上where条件子句，将会直接删除整个表的数据，导致数据的丢失，这将是无法忍受的重大操作失误，并且在使用delete删除数据时，如果没有提前做好数据备份，一旦误操作，删除的数据就再也无法恢复，同时如果删除的数据存在外键关联，使用delete操作可能会导致其他表中数据不一致。
在实际开发中，可以设置is_delete字段来删除数据，从而实现数据的逻辑删除，以提高数据的安全性。

explain用过吗，里面主要有哪些字段？

explain 是 SQL 中的一个关键字，它用于描述一个 SQL 查询语句的执行计划。当对一个 SQL 查询使用explain时，数据库会返回一个表格，描述了查询是如何被优化和执行的。这对于性能调优非常有用，因为它可以帮助你理解查询是如何与数据库的索引、表等结构进行交互的。

explain 的输出通常包含以下字段：

1.id: 查询的标识符，用于区分查询中的多个子查询或联接操作。
2.select_type: 查询的类型，如 SIMPLE（简单查询）、PRIMARY（主要查询）、UNION（联合查询的一部分） 等。
3.table: 查询涉及的表名。
4.partitions: 查询涉及的分区（如果表是分区的）。
5.type: 访问类型，描述了数据库如何检索表中的行。常见的类型包括 ALL（全表扫描）、index（索引扫描）、range（范围查找）、ref（非唯一索引扫描或唯一索引的非唯一前缀扫描）、eq_ref（唯一索引扫描）、const（常量查找，如主键查找）等。
6.possible_keys: 可能使用的索引列表。
7.key: 实际使用的索引。
8.key_len: 使用的索引的长度。
9.ref: 哪些列或常量被用作索引查找的参考。
10.rows: 估计需要检查的行数。
11.filtered: 表示返回的行的百分比，即经过条件过滤后剩余的行数的百分比。
12.Extra: 额外的信息，如是否使用了文件排序、是否使用了临时表等。

数据库三大范式是什么？

第一范式：每个字段都不可以再被拆分；
第二范式：在第一范式的基础上，有主键，并且主键之外的其他字段完全依赖于主键，不能是依赖于主键的一部分；
第三范式：在第二范式的基础上，非主键的字段只能依赖于主键，不能依赖于其他的非主键。

说说PostgreSQL和MySQL之间的对比

MySQL和PostgreSQL都是非常优秀的数据库系统，以下是二者之间的一些区别：
1.PostgreSQL提供了一些高级特性，比如物化视图、公共表表达式和窗口函数等等，而MySQL在一些Web开发中表现会更加优秀；
2.总体来说，MySQL的性能更加突出，特别是在读密集的场景中，而PostgreSQL在处理复杂查询和写密集操作的时候更有优势；
3.PostgreSQL严格遵循SQL标准提供了全面的ACID支持，而MySQL虽然也支持ACID，但是会受存储引擎的影响；
4.PostgreSQL支持多种自定义扩展，比如说自定义数据类型、操作符等等，而MySQL则是在分区等方面表现更好。
对于二者的选择，有几个方面的考虑因素：
1.从应用范围来说，PostgreSQL更适合具有频繁写入操作和复杂查询的企业级应用程序，但是如果想要创建用户较少的内部应用程序，或者创建具有更多读取次数和较少数据更新的信息存储引擎，那么就可以使用MySQL；
2.从学习难易程度来说，MySQL更加适合初学者，而PostgreSQL对于新手来说会更具有挑战性，因为它需要更加复杂的基础设置和问题排查经验；
3.从性能方面来说，如果应用程序需要频繁更新数据，则PostgreSQL是一个相对更好的选择，但是如果需要频繁读取数据，则首选MySQL。
在数据写入层面，MySQL使用写锁定来实现真正的并发性，而PostgreSQL内置了多版本并发控制支持，没有读写锁定，所以如果要进行频繁的并发写入操作，PostgreSQL数据库的表现会更加优异。
在数据库读取层面，PostgreSQL会创建一个新的系统进程，为每个连接到数据库的用户分配大量内存，而MySQL是为多个用户创建一个单一进程，因此对于主要向用户读取和显示数据的应用程序，MySQL数据库要比PostgreSQL更好一些。

什么是索引？说说索引的优缺点

索引是关系数据库中的一种数据结构，它将数据提前按照一定的规则进行排序和组织，能够帮助快速定位到数据记录的数据，从而加快数据库表中数据的查找和访问速度，它的核心思想是以空间换时间。
索引的优点：
1.在大部分场景下，能够提高检索效率；
2.降低排序成本，索引对应的字段是会有一个自动排序功能的，默认是升序。
索引的缺点：
1.创建索引和维护索引需要耗费时间，这种时间随着数据量的增加而增加；
2.索引需要占用物理空间，数据量越大，占用空间就会越大；
3.会降低表的增删改效率，因为每次增删改索引，都需要进行动态维护（因为B+树需要平衡，所以需要自动计算索引的数据结构，这会导致耗时）。

什么时候需要创建索引，什么时候不需要？

适合：
较频繁的作为查询条件的字段应该创建索引，以加快查询的速度和效率
不适合：
1.字段值的唯一性太差（数据太多重复）不适合单独地做索引；
2.更新非常频繁的字段不适合做索引，因为动态维护耗时；
3.不会出现在where语句中的字段不适合做索引（不会作为查询条件，当然也就没有必要作为索引了）。

Mysql中索引失效的场景有哪些？

1.在where子句中使用一些逻辑操作符，比如说NOT IN或是 ！= 这样的一些操作，因为这些操作会导致Mysql无法进行索引查找；
2.对索引字段进行计算或函数操作，比如说对一个日期字段做一个year()函数的操作，那么Mysql就无法使用索引；
3.使用LIKE操作符进行模糊查询时，如果通配符在前面（如LIKE “%明”），就会导致索引失效，这是因为Mysql无法确定查找的起始点；
4.如果Mysql 估计全表扫描会比索引速度更快，就会选择全表扫描，比如数据量小，或者大部分行都满足where子句的时候；
5.在联合索引中，没有按照索引的最左前缀顺序来查询，也可能会导致索引失效。

在Mysql中默认的存储引擎和索引的数据结构分别是什么？

Mysql中默认的存储引擎是InnoDB，默认的索引数据结构是B+树（在Mysql中，当为某一个表创建一个ID主键的时候，mysql就会为一个主键维护一个索引，这个索引的数据结构就是一颗B+树）。

InnoDB和MyISAM的区别

InnoDB和MyISAM是两种不同的数据存储引擎，它们的区别如下：
1.InnoDB支持 ACID的事务，支持事务的四种隔离级别，而MyISAM不支持事务，每次操作都是原子的；
2.InnoDB支持行级锁，因此可以支持写并发，而MyISAM支持的是表级锁，即每次操作是对整个表加锁；
3.InnoDB是把索引和数据存储在同一个文件中，而MyISAM里的数据和索引是分开存储的；
4.InnoDB支持外键，而MyISAM不支持外键。

说说B树和B+树，它们之间的区别是什么？

B树是一种自平衡的树，能够保持数据有序。在B树中，所有值都出现在叶子节点和内部节点，且内部节点作为索引使用。B树的每个节点通常包含多个子节点，这些子节点的数量受到一定的限制。当进行数据插入或删除时，B树会通过分裂和合并节点来保持平衡。
B+树是B树的一种变种，它也具有平衡和有序的特性。与B树不同的是，B+树的所有值都出现在叶子节点，内部节点仅作为索引使用。此外，B+树的叶子节点通过指针顺序连接在一起，形成一个链表结构，这有利于进行范围查询和顺序访问。
区别：
1.B树的每个索引节点上都会存储对应索引的值，数据和索引节点绑在了一起，而B+树只把数据放在了叶子节点上。
2.B树的叶子节点之间没有连接关系，而B+树的两两叶子节点之间采用了双向链表连接，从而能够使相邻节点快速定位。
3.B树的叶子节点中不会包含内部节点，而B+树的叶子节点中会包含内部节点在内的所有数据。

为什么Mysql要选择B+树作为默认的索引数据结构？

1.非叶子节点上能够存储更多键值，相应的树的阶数（节点的子节点树）就会更大，树也就会变得更矮更胖。这样一来执行检索操作进行的磁盘I/O次数就会大大地减少，数据查询的效率也会更快。
2.B+树的叶子节点采用了双向链表，当查询一些范围条件的时候，相比B树查询效率会得到大大提升。
3.由于B+树的所有数据已经通过叶子节点的双向链表排好了顺序，进行排序查询操作时，相比B树性能会快速非常多。

什么是聚集（聚簇）索引和非聚集索引？谈谈它们的区别

此处参考：https://www.cnblogs.com/xiaomaomao/p/16196006.html
聚集索引是指数据库表行中数据的物理顺序与键值的索引顺序相同，对于聚集索引，数据库数据和索引将设计到一个文件中，叶子节点包含了所有数据记录。
Innodb的主键索引就是通过聚集索引实现的。
例如数据库中有一张 id 为主键的user 表如下：

那么基于这张表的主键 id 建立的聚集索引如下图所示，可以看出，叶子节点包含了完整的表数据。

因为表中存储的数据是通过聚集索引组织在一起的,所以聚集索引必须要有,否则我们无法获取到表中的行数据,并且聚集索引还只能存在一个。
由于聚集索引必须存在，所以对于聚集索引有以下规则：

• 如果存在主键,那么主键索引就是聚集索引
• 如果不存在主键,将会使用第一个唯一(UNIQUE)、非空的索引作为聚集索引
• 如果表中既没有主键索引,又没有合适的唯一索引,那么 Innodb 会自动维护一个 row_id(默认大小为 6B)来作为隐藏的聚集索引

非聚集索引是指数据库表行中数据的物理顺序与键值的索引排列顺序无关，它把索引和行数据分开维护,叶子节点并没有包含完整的数据记录。（个人理解：当主键存在时，可以把它看作非主键索引）
Innodb 以 age 建立的非聚集索引如下图：

重点：当通过非聚集索引来查询数据时,存储引擎会根据索引字段定位到最底层的叶子节点,并通过叶子节点获得指向主键索引的主键 id,然后通过主键 id 去主键索引(聚集索引)上找到一个完整的行记录.这个过程被称为回表。

聚集索引与非聚集索引的区别有以下几点：

1.一个表中只能拥有一个聚集索引，而非聚集索引一个表可以存在多个。

2.聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。

3.索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。

4.聚集索引：物理存储按照索引排序；非聚集索引：物理存储不按照索引排序；

什么是联合索引？

联合索引就是好几个字段组成的索引。它遵循“最左匹配原则”，没有最左边的索引值，就没办法使用这个索引。在MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配，顺序不对时引擎会自动优化为匹配联合索引的顺序，这样是能够命中索引的。可以说创建的idx_abc(a,b,c)索引，相当于创建了(a)、（a,b）（a,b,c）三个索引。由于构建一棵B+树只能根据一个值来确定索引关系，所以数据库依赖联合索引最左的字段来构建。

什么是最左前缀原则？

最左前缀原则（也称最左匹配原则）指的是在查询过程中，索引的利用是从联合索引的最左边开始，并逐列进行匹配。在创建联合索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。
例如，创建一个组合索引(a1,a2,a3)，相当于创建了（a1）、(a1,a2)和(a1,a2,a3)三个索引，这就是最左匹配原则。

什么是覆盖索引？

需要注意，覆盖索引是一种数据查询方式，不是索引类型。覆盖索引也叫索引覆盖，它是一种查询优化技术，在某些情况下可以避免执行回表操作，以提高查询性能。
当使用非聚集索引查询时，如果查询语句中只使用了索引列，而没有查询表中的其他列，那么可以使用索引覆盖来避免回表操作。在这种情况下，查询可以直接从索引中获取所需的数据，而不需要再回到表中查找数据。这可以减少IO操作，提高查询性能。

Mysql锁有哪些？有哪几种分类方式？

MySQL锁是实现数据库并发控制的重要手段，它可以让多个用户同时访问数据库而不会产生数据冲突或不一致性。根据不同的分类方式，MySQL锁可以分为以下几类：
按锁粒度分类：

1. 全局锁：锁住整个数据库，全局锁将整个数据库实例作为锁定的对象，当一个事务对数据库加全局锁后，其他的事务将无法对该数据库进行任何的写操作，这种锁的锁粒度最大，并发度最低，但开销也最小。通常在进行数据库的维护或备份操作时，会使用全局锁来保证数据的一致性。
2. 表级锁：锁住整张表的数据，MyISAM引擎使用表级锁（只支持），这种锁的优点是开销小、加锁快、没有死锁，缺点是并发度最低，一次只允许一个事务进行写操作；
3. 行级锁：锁住某行的数据，这种锁的锁粒度最小，InnoDB引擎默认使用行级锁来实现对数据的并发控制，这种锁的好处是锁定的数据量小，并发度高，但管理锁的开销相对较大。
   按锁的属性还可以分为：
4. 共享锁：也就是读锁，⼀个事务给某行数据加了读锁，其他事务也可以读，但是不能写；
5. 排它锁：也就是写锁，⼀个事务给某行数据加了写锁，其他事务不能读，也不能写。
   从实现模式的角度还可以分为：
6. 乐观锁：假设多个事务在并发执行时不会彼此冲突，直到提交数据时才会检查是否有冲突发生。如果有冲突，则事务回滚。在mysql中，乐观锁并没有内置的实现，可以使用版本号（或时间戳）字段来实现；
7. 悲观锁：在数据处理过程中，总是假设最坏的情况，即认为会发生并发冲突，所以锁定操作过程中所涉及的数据，避免其他事务的干扰。前面所提到的行锁、表锁等都是悲观锁。

数据库事务是什么？

数据库事务是访问并可能操作各种数据项的一个数据库操作序列，它是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么全部执行,要么全部不执行，是一个不可分割的工作单位。一个事务由该事务开始与该事务结束之间所执行的全部数据库操作组成。

谈谈数据库事务的基本特性

数据库事务的基本特性为 “ACID”。

1.原子性（atomicity）： 事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做。
2.一致性（consistency）： 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。
3.隔离性（Isolation）： 一个事务的执行不能其它事务干扰。即一个事务的修改在最终提交前，对其他事务是不可见的。
4.持久性（Durability）： 一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

什么是MVCC？

MVCC的中文是多版本并发控制器，是为了在读取数据时不加锁的情况下实现读写不冲突来提高读取效率和并发性的一种手段。它的基本思想是：为每个数据记录维护多个版本，允许并发事务在不相互阻塞的情况下读取不同版本的数据。

MVCC会为每个修改保存⼀个版本，版本与事务的时间戳关联，当事务开始时，会记录当前的最新版本号。在事务执行过程中，只能读取到版本号小于等于事务开始时的版本。读操作只读该事务开始前的数据库版本的快照。当进行写操作时，会生成新的版本并更新到数据行中。旧的版本仍然存在，不会被删除。这样可以使得其他正在进行的事务可以继续读取到旧的版本，不会被阻塞。

数据库事务的四大特性都是如何保证的？

原子性是通过undo log日志和回滚来保证的，在开启事务时，会将事务开始时的原始数据保存在undo log中，如果事务失败，将通过回滚撤销该事务已做的所有修改，并通过undo log将数据库恢复到事务开始前的状态；

一致性是通过强制执行完整性约束（如主键约束、外键约束等）和使用触发器等技术来保证；

隔离性是由MVCC来保证的，由于不同的事务在版本控制下会属于不同的版本，因此可以实现不同事务的相互隔离；

持久性由内存和redo log来保证，事务提交的同时，mysql会在内存和redo log中记录这次修改操作，系统发生故障的时候可以从redo log恢复已提交的修改。

数据库事务的隔离级别

首先，先来介绍一下数据库事务的常见并发问题，数据库事务的并发问题主要有以下几种：
1.脏读： 一个事务读取到另一个事务未提交的数据。
2.不可重复读： 一个事务对同一行数据重复读取两次，但得到的结果不同。
3.幻读： 一个事务执行两次查询，但第二次查询的结果包含了第一次查询中未出现的数据。
4.丢失更新： 两个事务同时更新一行数据，后提交（或撤销）的事务将之前事务提交的数据覆盖了。

数据库事务的隔离级别有4个，由低到高依次为读未提交、读已提交、可重复读、可串行化四个级别，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。
读未提交： 一个事务在执行过程中，既可以访问其他事务未提交的新插入的数据，又可以访问未提交的修改数据。如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据。此隔离级别可防止丢失更新，但是会出现脏读，不可重复读，幻读问题。

读已提交： 一个事务在执行过程中，既可以访问其他事务成功提交的新插入的数据，又可以访问成功修改的数据。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行数据。此隔离级别可有效防止脏读问题，但是会出现不可重复读，幻读问题。

可重复读取： 这是mysql事务的默认隔离级别。一个事务在执行过程中，可以访问其他事务成功提交的新插入的数据，但不可以访问成功修改的数据。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。此隔离级别可有效防止不可重复读和脏读问题，但是会出现幻读问题。

可串行化： 提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。此隔离级别可有效防止脏读、不可重复读和幻读。但这个级别可能导致大量的超时现象和锁竞争，在实际应用中很少使用。

Mysql慢查询该如何优化？

1. 检查查询是否走了索引，如果没有则优化SQL利用索引；
2. 检查所利用的索引，是否是最优索引；
3. 检查所查字段是否都是必须的，是否查询了过多字段，查出了多余数据；
4. 检查表中数据是否过多，是否应该进行分库分表；
5. 检查数据库实例所在机器的性能配置，是否太低，是否可以适当增加资源。

谈谈什么是Mysql主从复制？

简单来说，Mysql的主从复制就是一个MySQL服务器（我们叫它主服务器）把它的数据变更操作，通过记录日志的方式记下来，然后另一个或多个Mysql服务器（也就是从服务器）会拿这些记录来更新自己的数据，保持和主服务器一致。这就像是我们平时做的备份，但不仅仅是备份，它还能让读取操作更快、系统更稳定。
主服务器会把它所有的变更操作，比如插入、更新、删除等，都记录在一个叫做二进制日志(Binlog)的文件里。而从服务器会有一个专门的进程去主服务器那里拿这些日志，然后另一个进程来执行这些日志里的操作。这样，从服务器就能实时地更新自己的数据，和主服务器保持同步。
这种复制方式有很多好处。如果主服务器突然坏了，可以很快地切换到从服务器，继续提供服务，减少停机时间。

还有，如果有很多读取请求，可以让写操作全部在主数据库上进行，读操作全在从数据库上进行，从而可以减轻主服务器的压力，这就是Mysql的读写分离。

当然，因为复制是异步进行的，所以从服务器可能会稍微慢一点，但这通常不会影响到正常使用。

Mysql里有哪些日志？

1.错误日志 (Error Log): 记录Mysql服务器启动、运行或停止时出现的问题，包括警告信息。这对于诊断数据库问题和监视系统的健康状况非常有用。
2.查询日志 (General Query Log): 记录已执行的SQL语句，包括客户端连接和执行的所有SQL查询。这有助于分析数据库的性能问题，优化慢查询，以及进行数据库操作的审计。
3.慢查询日志 (Slow Query Log): 记录执行时间超过预定义阈值（例如，超过long_query_time设置的值）的SQL查询。管理员可以根据需要设置这个阈值，以便找出需要优化的查询。
4.二进制日志 (Binlog): 记录所有对数据库进行修改的操作（如INSERT、UPDATE、DELETE等）。这些日志对于数据复制（主从复制）和数据恢复非常有用。
5.中继日志 (Relay Log): 在主从服务器架构中，从服务器使用这个日志来存放从主服务器的二进制日志中复制过来的事件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。
6.重做日志 (Redo Log): 这是InnoDB存储引擎特有的日志，记录了物理级别上的页修改操作。它提供了崩溃恢复的能力，并确保了事务的持久性。
7.回滚日志 (Undo Log): 也是InnoDB存储引擎使用的，记录了如何撤销对数据的修改。当事务需要回滚时，或者当多个事务需要读取同一数据行的不同版本时（多版本并发控制，MVCC），就会使用这个日志。

说说MySQL二阶段提交的原理

Mysql二阶段提交发生在redo log和bin log的日志写入阶段，也就是把日志的写入和提交拆分成两个阶段，从而确保redo log和bin log写入的数据一致性。
第一阶段是prepare阶段，在这个阶段中，mysql会把事务操作记录到redo log中，并标记为prepare状态；
第二阶段是commit阶段，当事务提交的时候，mysql会将事务操作记录到bin log里面，然后把redo log中的日志设置为commit状态。
所以InnoDB在写redo log的时候并不是一次写完的，而是有两个阶段：prepare和commit。
在这个设计中，如果在写入redo log之前崩溃，那么此时redo log和bin log中是没有数据的，那么数据是满足一致性的；如果在写入redo log prepare阶段后立马崩溃，那么之后在崩溃恢复的时候，由于redo log中没有标记为commit，于是拿着redo log中的事务ID去bin log中查找，此时肯定是找不到的，那么这时候就执行回滚操作；如果在写入bin log后立马崩溃，在数据恢复的时候，由于redo log中的事务ID可以找到对应的bin log，那么这个时候可以直接将事务设置为commit状态。

Mysql自增ID用完了会怎么样？

Mysql的自增ID用完了后，后续插入数据的时候，ID不会再递增，从而导致出现主键冲突，使得后续新增的数据无法正常保存，这类问题一般不会出现，因为即便是int类型的主键，也能存储20多个亿的数据量，假设针对存在这样的问题，可以有以下几个解决思路：
1.可以在设计前期就考虑到这个点，把id的数据长度设置到更大，比如用bigint类型来存id；
2.可以不使用自增id，而是采用业务主键，这样在后期如果需要做分表的话会更加方便；
3.假设已经存在了这样的瓶颈了，可以考虑把数据迁移到一个新的表或者数据库上，然后重置自增id的范围，这个过程需要谨慎处理，从而确保数据的一致性以及业务的逻辑性。

Mysql表设计时间列采用的是datetime还是timestamp？

首先，datetime和timestamp的区别有以下几点：
1.在存储空间方面，timestamp占用4个字节，而datetime占用8个字节，所以如果对存储空间有严格要求，那timestamp是一个更好的选择；
2.在时区支持方面，timestamp存储的是一个UTC时间，它会根据系统的时区进行一个自动转化，而datetime不会做时区的转化，存储的就是字面值的时间。如果应用程序需要在不同的时区之间进行工作，那timestamp就是一个更合适的选择；
3.在时间范围方面，datetime的时间范围是从1000年到9999年，而timestamp的时间范围是1970年到2038年，在实际开发中需要根据表述的时间范围来选择合适的类型。
通过以上区别可以知道，如果需要存储的时间超出了timestamp所能表示的范围，或者说不想让时区影响存储的时间值，就可以使用datetime。如果需要考虑不同地区的时区问题，或者希望节省存储空间，那么可以使用timestamp。在实际开发中，无论是选择哪种时间类型，都需要在代码中统一时间的处理方式，从而避免时区转换等问题的发生。

如何防止SQL注入攻击？

SQL注入是一种常见的Web安全漏洞，攻击者可通过输入框或者其他方式输入非法的SQL代码，从而去操作数据库，这样一来，攻击者就可以获得敏感数据，甚至会拥有操控整个数据库的能力。
要防止SQL注入，可以采用以下几种预防和解决办法：
1.使用参数化查询：参数化查询是指先定义SQL语句的格式，然后将输入的参数作为参数传入，避免了直接将输入作为SQL执行的情况；
2.过滤特殊字符：对于输入的数据需要进行特殊处理，去掉或是转义特殊字符，如单引号、反斜杠等。
3.对于输入参数进行验证：对于用户输入的参数，去掉一些异常数据，以减少注入攻击的可能性；
4.对于访问数据库的账户进行权限分离：将数据访问按不同的用途分别创建不同的账户，并为其分配不同的权限，从而避免恶意用户以非法账户对数据库进行操作。

下一篇传送门：点我