【成神之路】Mysql相关面试题

Mysql基础：

DDL、DML、DCL分别指什么？数据库常见的命令?

DDL（Data Definition Languages）语句：即数据库定义语句，用来创建数据库中的表、索引、视图、存储过程、触发器等，常用的语句关键字有：CREATE,ALTER,DROP,TRUNCATE,COMMENT,RENAME。

DML（Data Manipulation Language）语句：即数据操纵语句，用来查询、添加、更新、删除等，常用的语句关键字有：SELECT,INSERT,UPDATE,DELETE,MERGE,CALL,EXPLAIN PLAN,LOCK TABLE,包括通用性的增删改查。

DCL（Data Control Language）语句：即数据控制语句，用于授权/撤销数据库及其字段的权限（DCL is short name of Data Control Language which includes commands such as GRANT and mostly concerned with rights, permissions and other controls of the database system.）。常用的语句关键字有：GRANT,REVOKE。

TCL（Transaction Control Language）语句：事务控制语句，用于控制事务，常用的语句关键字有：COMMIT,ROLLBACK,SAVEPOINT,SET TRANSACTION。

数据库的几大范式？

第一范式----数据库中的表(所有字段值)都是不可分割的原子数据项。

第二范式----数据库表中的每一列都和主键相关，而不能只和主键的某一部分相关。也就是说一个表中只能只能包含一个，不能把多种数据保存在同一个表中。

第三范式----数据库表中每一列数据都和主键直接相关，不能间接相关。

左连接、右连接、内连接、外连接、交叉连接/笛卡儿积等?

关系型数据库和非关系型数据库区别；?

drop、truncate、delete的区别？

DROP - delete objects from the database 删除
TRUNCATE - remove all records from a table, including all spaces allocated for the records are removed
Truncate table 表名速度快,而且效率高,因为:
TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。
DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。
TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。
对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。
TRUNCATE TABLE 不能用于参与了索引视图的表。

https://www.cnblogs.com/zhizhao/p/7825469.html

红黑树和平衡树的区别，为什么数据库不用红黑树?

https://www.cnblogs.com/tiancai/p/9024351.html

mysql目前用的版本？

5.7.21；目前最高5.7.*

MySQL 分页查询语句？

select * from table limit (start-1)*limit,limit; 其中start是页码，limit是每页显示的条数

SQL的整个解析、执行过程原理？

https://blog.csdn.net/w372426096/article/details/87919935

sql语句各种条件的执行顺序，如select， where， order by， group by？

写的顺序：select ... from... where.... group by... having... order by..
执行顺序：from... where...group by... having.... select ... order by...

order by 原理？

1.MySQL会为每个线程分配一个内存（sort_buffer）用于排序该内存大小为sort_buffer_size
1>如果排序的数据量小于sort_buffer_size，排序将会在内存中完成
2>如果排序数据量很大，内存中无法存下这么多数据，则会使用磁盘临时文件来辅助排序，也称外部排序
3>在使用外部排序时，MySQL会分成好几份单独的临时文件用来存放排序后的数据，然后在将这些文件合并成一个大文件
2.mysql会通过遍历索引将满足条件的数据读取到sort_buffer，并且按照排序字段进行快速排序
1>如果查询的字段不包含在辅助索引中，需要按照辅助索引记录的主键返回聚集索引取出所需字段
2>该方式会造成随机IO，在MySQL5.6提供了MRR的机制，会将辅助索引匹配记录的主键取出来在内存中进行排序，然后在回表
3>按照情况建立联合索引来避免排序所带来的性能损耗，允许的情况下也可以建立覆盖索引来避免回表
全字段排序
1.通过索引将所需的字段全部读取到sort_buffer中
2.按照排序字段进行排序
3.将结果集返回给客户端
缺点：
1.造成sort_buffer中存放不下很多数据，因为除了排序字段还存放其他字段，对sort_buffer的利用效率不高
2.当所需排序数据量很大时，会有很多的临时文件，排序性能也会很差
优点：MySQL认为内存足够大时会优先选择全字段排序，因为这种方式比rowid 排序避免了一次回表操作
rowid排序
1.通过控制排序的行数据的长度来让sort_buffer中尽可能多的存放数据，max_length_for_sort_data
2.只将需要排序的字段和主键读取到sort_buffer中，并按照排序字段进行排序
3.按照排序后的顺序，取id进行回表取出想要获取的数据
4.将结果集返回给客户端
优点：更好的利用内存的sort_buffer进行排序操作，尽量减少对磁盘的访问
缺点：回表的操作是随机IO，会造成大量的随机读，不一定就比全字段排序减少对磁盘的访问
3.按照排序的结果返回客户所取行数
https://blog.csdn.net/w372426096/article/details/87874281

什么是触发器，MySQL中都有哪些触发器？触发器的作用？

https://www.cnblogs.com/chenpi/p/5130993.html

Mysql表中允许有多少个TRIGGERS？

CREATE TRIGGER trigger_name trigger_time trigger_event ON tb_name FOR EACH ROW trigger_stmt
trigger_name：触发器的名称
tirgger_time：触发时机，为BEFORE或者AFTER
trigger_event：触发事件，为INSERT、DELETE或者UPDATE
tb_name：表示建立触发器的表明，就是在哪张表上建立触发器
trigger_stmt：触发器的程序体，可以是一条SQL语句或者是用BEGIN和END包含的多条语句
所以可以说MySQL创建以下六种触发器：
BEFORE INSERT,BEFORE DELETE,BEFORE UPDATE
AFTER INSERT,AFTER DELETE,AFTER UPDATE

什么是存储过程？用什么来调用？存储过程的优缺点？

存储过程就是一堆sql的合并其中包含一定的逻辑；

优点如下：

1.执行效率高。

2.安全性能好。

3.对于一些场合非常容易实现需求。

缺点如下：

1.可维护性比较差。

2.可读性也差。

存储过程与函数的区别

存储过程：可以使得对的管理、以及显示关于及其用户信息的工作容易得多。存储过程是SQL语句和可选控制流语句的预编译集合，以一个名称存储并作为一个单元处理。存储过程存储在数据库内，可由应用程序通过一个调用执行，而且允许用户声明变量、有条件执行以及其它强大的编程功能。存储过程可包含程序流、逻辑以及对数据库的查询。它们可以接受参数、输出参数、返回单个或多个结果集以及返回值。

可以出于任何使用SQL语句的目的来使用存储过程，它具有以下优点：

(1)功能强大，限制少。

(2)可以在单个存储过程中执行一系列SQL语句。

(3)可以从自己的存储过程内引用其它存储过程，这可以简化一系列复杂语句。

(4)存储过程在创建时即在上进行编译，所以执行起来比单个SQL语句快。

(5)可以有多个返回值，即多个输出参数，并且可以使用SELECT返回结果集。

函数：是由一个或多个SQL语句组成的子程序，可用于封装代码以便重新使用。自定义函数诸多限制，有许多语句不能使用，许多功能不能实现。函数可以直接引用返回值，用表变量返回记录集。但是，用户定义函数不能用于执行一组修改全局数据库状态的操作。

什么叫视图？游标是什么？

视图是一种虚拟的表，具有和物理表相同的功能。可以对视图进行增，改，查，操作，视图通常是有一个表或者多个表的行或列的子集。对视图的修改不影响基本表。它使得我们获取数据更容易，相比多表查询。

游标：是对查询出来的结果集作为一个单元来有效的处理。游标可以定在该单元中的特定行，从结果集的当前行检索一行或多行。可以对结果集当前行做修改。一般不使用游标，但是需要逐条处理数据的时候，游标显得十分重要。

视图的优缺点？

视图，虚拟表，从一个表或多个表中导出来的表，作用和真实表一样，包含一系列带有行和列的数据视图中，用户可以使用SELECT语句查询数据，也可以使用INSERT，UPDATE，DELETE修改记录，视图可以使用户操作方便，并保障数据库系统安全

优点

简单化，数据所见即所得

安全性，用户只能查询或修改他们所能见到得到的数据

逻辑独立性，可以屏蔽真实表结构变化带来的影响

缺点

性能相对较差，简单的查询也会变得稍显复杂

修改不方便，特变是复杂的聚合视图基本无法修改

主键和外键的区别？

一个表只能有一个主键，但可以有多个候选索引。主键常与外键构成参照完整性约束，防止出现数据不一致。主键可以保证记录的唯一和主键域非空,数据库管理系统对于主键自动生成唯一索引。主键一定是唯一性索引，唯一性索引并不一定就是主键。

外键就是另一表的主键，外键将两表联系起来。一般情况下，要删除一张表中的主键必须首先要确保其它表中的没有相同外键（即该表中的主键没有一个外键和它相关联）。

union和union all有什么不同?

UNION和UNION ALL关键字都是将两个结果集合并为一个，但这两者从使用和效率上来说都有所不同。1、对重复结果的处理：UNION在进行表链接后会筛选掉重复的记录，Union All不会去除重复记录。2、对排序的处理：Union将会按照字段的顺序进行排序；UNION ALL只是简单的将两个结果合并后就返回。从效率上说，UNION ALL 要比UNION快很多，所以，如果可以确认合并的两个结果集中不包含重复数据且不需要排序时的话，那么就使用UNION ALL。

mysql中varchar与oracle中varchar2区别

一个汉字占多少长度与编码有关：

UTF-8：一个汉字 = 3个字节，英文是一个字节
GBK：一个汉字 = 2个字节，英文是一个字节

varchar(n) 表示n个字符，无论汉字和英文，MySql都能存入 n 个字符，仅实际字节长度有所区别。

Oracle中varchar2类型代表字节

Oracle和Mysql的区别？

mysql有关权限的表都有哪几个？

user权限表：记录允许连接到服务器的用户帐号信息，里面的权限是全局级的。
db权限表：记录各个帐号在各个数据库上的操作权限。
table_priv权限表：记录数据表级的操作权限。
columns_priv权限表：记录数据列级的操作权限。
host权限表：配合db权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和REVOKE语句的影响。

MYSQL数据表在什么情况下容易损坏？

1、服务器突然断电导致数据文件损坏。
2、强制关机，没有先关闭mysql 服务。
3、 mysqld 进程在写表时被杀掉。
4、使用myisamchk 的同时，mysqld 也在操作表。
5、磁盘故障。
6、服务器死机。
7、 mysql 本身的bug 。
什么样的对象可以使用CREATE语句创建？

以下对象是使用CREATE语句创建的：

　　DATABASE
　　EVENT
　　FUNCTION
　　INDEX
　　PROCEDURE
　　TABLE
　　TRIGGER
　　USER
　　VIEW

NOW（）和CURRENT_DATE（）有什么区别？

NOW（）命令用于显示当前年份，月份，日期，小时，分钟和秒。

　　CURRENT_DATE（）仅显示当前年份，月份和日期。

如何显示前50行？

SELECT * FROM LIMIT 0,50;

如何输入字符为十六进制数字？

如果想输入字符为十六进制数字，可以输入带有单引号的十六进制数字和前缀（X），或者只用（Ox）前缀输入十六进制数字。

如果表达式上下文是字符串，则十六进制数字串将自动转换为字符串。

mysql> SELECT x'4D7953514C'；-> 'MySQL'
mysql> SELECT 0xa+0；-> 10
mysql> SELECT 0x5061756c；-> 'Paul'

MyISAM表格将在哪里存储，并且还提供其存储格式？

　每个MyISAM表格以三种格式存储在磁盘上：

　　·“.frm”文件存储表定义

　　·数据文件具有“.MYD”（MYData）扩展名

　　索引文件具有“.MYI”（MYIndex）扩展名

BLOB和TEXT有什么区别？

BLOB是一个二进制对象，可以容纳可变数量的数据。有四种类型的BLOB -

　　TINYBLOB
　　BLOB
　　MEDIUMBLOB和
　　LONGBLOB

　　它们只能在所能容纳价值的最大长度上有所不同。

　　TEXT是一个不区分大小写的BLOB。四种TEXT类型

　　TINYTEXT
　　TEXT
　　MEDIUMTEXT和
　　LONGTEXT

　　它们对应于四种BLOB类型，并具有相同的最大长度和存储要求。

　　BLOB和TEXT类型之间的唯一区别在于对BLOB值进行排序和比较时区分大小写，对TEXT值不区分大小写。

LIKE和REGEXP操作有什么区别？

regexp是正则匹配

SELECT * FROM employee WHERE emp_name REGEXP "^b";

SELECT * FROM employee WHERE emp_name LIKE "%b";

Mysql查询是否区分大小写？

Mysql不区分大小写

我们如何得到受查询影响的行数？

SELECT COUNT(user_id)FROM users;

列对比运算符是什么？

在SELECT语句的列比较中使用=，<>，<=，<，> =，>，<<，>>，<=>，AND，OR或LIKE运算符

如何在Unix和Mysql时间戳之间进行转换？

UNIX_TIMESTAMP是从Mysql时间戳转换为Unix时间戳的命令
FROM_UNIXTIME是从Unix时间戳转换为Mysql时间戳的命令

你怎么看到为表格定义的所有索引？

SHOW INDEX FROM <tablename>;

怎样才能找出最后一次插入时分配了哪个自动增量？

LAST_INSERT_ID将返回由Auto_increment分配的最后一个值，并且不需要指定表名称。

SELECT LAST_INSERT_ID();

列设置为AUTO INCREMENT时，如果在表中达到最大值，会发生什么情况？

它会停止递增，任何进一步的插入都将产生错误，因为密钥已被使用。

如果一个表有一列定义为TIMESTAMP，将发生什么？

每当行被更改时，时间戳字段将获取当前时间戳.

federated表是什么？

federated表，允许访问位于其他服务器数据库上的表。

Heap表是什么？如何控制HEAP表的最大尺寸？

内存表：Heal表的大小可通过称为max_heap_table_size的Mysql配置变量来控制。

如何使用Unix shell登录Mysql？

　　# [mysql dir]/bin/mysql -h hostname -u <UserName> -p <password>

主键和候选键有什么区别？

表格的每一行都由主键唯一标识,一个表只有一个主键。

主键也是候选键。按照惯例，候选键可以被指定为主键，并且可以用于任何外键引用。

如何获取当前的Mysql版本？

SELECT VERSION();

CHAR和VARCHAR的区别？

char与varchar后面接的数据大小为存储的字符数，而不是字节数

char定义的是固定长度，长度范围为0-255，存储时，如果字符数没有达到定义的位数，会在后面用空格补全存入数据库中；数据库取char的数据时，会把后面的空格全部丢弃掉

varchar是变长长度，长度范围为0-65535，存储时，如果字符没有达到定义的位数，也不会在后面补空格

如何区分FLOAT和DOUBLE？

浮点数以8位精度存储在FLOAT中，并且有四个字节。
浮点数存储在DOUBLE中，精度为18位，有八个字节。

Mysql服务器默认端口是什么？

3306

请写出下面MySQL数据类型表达的意义（int(0)、char(16)、varchar(16)、datetime、text）？

从 -2^31 (-2,147,483,648) 到 2^31 – 1 (2,147,483,647) 的整型数据（所有数字）。存储大小为 4 个字节；括号里的数字是显示长度的意思。

varchar(50)中50的含义？

50标识50个字符，具体多少字节需要根据具体的字节码方式来定。

引擎：

存储引擎的 InnoDB与MyISAM区别，优缺点，使用场景?

区别：

1、InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；

2、InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；

3、InnoDB是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而MyISAM是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

4、InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；

5、Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；

InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。

InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。

MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。

InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效。

如何选择：

1、是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；

2、如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读写也挺频繁，请使用InnoDB。

3、系统奔溃后，MyISAM恢复起来更困难，能否接受；

4、MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。

mysql的存储引擎,区别?

功能	MYISAM	Memory	InnoDB	Archive
存储限制	256TB	RAM	64TB	None
支持事物	No	No	Yes	No
支持全文索引	Yes	No	No	No
支持数索引	Yes	Yes	Yes	No
支持哈希索引	No	Yes	No	No
支持数据缓存	No	N/A	Yes	No
支持外键	No	No	Yes	No

InnoDB的插入缓冲和两次写的概念和意义?

innoDB最重要的特性插入缓存，两次写，自适应缓存

https://www.jb51.net/article/109815.htm

innodb对一行数据的读会加锁吗？

未提交读（read uncommitted）、提交读（read committed）、重复读（repeatable read）、序列化（serializable）

其中mysql默认的隔离级别为重复读（repeatable read），以下简称为rr。

1. select * from my_table where id = 1;

2. select * from my_table where id = 1 lock in share mode;

3. select * from my_table where id = 1 for update;

4. update my_table set address = 'tianjin' where id = 1;

MVCC中，读操作可以分成两类，快照读（Snapshot read）和当前读（current read）。快照读，读取的是记录的可见版本（可能是历史版本，即最新的数据可能正在被当前执行的事务并发修改），不会对返回的记录加锁，如上面的sql语句1；而当前读，读取的是记录的最新版本，并且会对返回的记录加锁，保证其他事务不会并发修改这条记录。如上面的sql语句2,3,4。不同的是2加的是s锁（共享锁），3、4加的是x锁（排它），insert加的也是x锁。
注：MVCC只在RC和RR两个隔离级别下工作，其他两个隔离级别都和MVCC不兼容

mysql的innodb默认的隔离模式为RR模式，既可重复读，Innodb的RR隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，新的满足查询条件的记录不能够插入 (间隙锁)，因此不存在幻读现象。但是标准的RR只能保证在同一事务中多次读取同样记录的结果是一致的，而无法解决幻读（不保证在事务中出现）问题。Innodb的幻读解决是依靠MVCC的实现机制做到的。

求表的size，或做数据统计可用什么存储引擎?

InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；

count(字段值):如果该字段上有null值.每行的行头有一个标记位,标记该行是否为null.所以多了一层判断。相对更耗时
count(主键id):即便是选择的有null值的二级索引,但是也可以挺快的正确计数。因为null的话字段值虽然为null,但是该行上主键id以及指向聚簇索引该id的指针还是存在的,所以不影响计数,也不用做判断,直接遍历该二级索引,取出id值,按行累加就行。
count(1)和count(*):看官方文档上说是5.7.18版本之前是扫描聚簇索引,之后是二级索引。虽然不取值,只计数。但是二级索引比聚簇索引需要扫描的页数相对来说更少,这应该也是一种优化,不过我做测试percona版本的5.6都是选择了二级索引
如果某表上有count比较多的操作,最好是用count(1)或者count(*),然后选择一列占用字节数最少的建立索引(比如tinyint类型)

读多写少可用什么引擎?

Memory

索引：

索引类别（B+树索引、全文索引、哈希索引）、索引的原理？ B+树索引和哈希索引的区别？哈希索引的优势？哈希索引不适用的场景？

1.索引的作用：提高数据查询效率
2.常见索引模型：哈希表、有序数组、搜索树
3.哈希表：键 - 值(key - value)。
4.哈希思路：把值放在数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置
5.哈希冲突的处理办法：链表，但冲突越多维护的代价越大
6.哈希表适用场景：只有等值查询的场景（NOSQL）
7.有序数组：按顺序存储。查询用二分法就可以快速查询，时间复杂度是：O(log(N))
8.有序数组查询效率高，更新效率低
9.有序数组的适用场景：静态存储引擎。
10.二叉搜索树：每个节点的左儿子小于父节点，父节点又小于右儿子
11.二叉搜索树：查询时间复杂度O(log(N))，更新时间复杂度O(log(N))
12.数据库存储大多不适用二叉树，因为树高过高(会查磁盘比查内存慢)，会适用N叉树
13.InnoDB中的索引模型：B+Tree
14.索引类型：主键索引、非主键索引
主键索引的叶子节点存的是整行的数据(聚簇索引)，非主键索引的叶子节点内容是主键的值(二级索引)
15.主键索引和普通索引的区别：主键索引只要搜索ID这个B+Tree即可拿到数据。普通索引先搜索索引拿到主键值，再到主键索引树搜索一次(回表)
16.一个数据页满了，按照B+Tree算法，新增加一个数据页，叫做页分裂，会导致性能下降。空间利用率降低大概50%。当相邻的两个数据页利用率很低的时候会做数据页合并，合并的过程是分裂过程的逆过程。
17.从性能和存储空间方面考量，自增主键往往是更合理的选择。

普通索引：最基本的索引，没有任何限制
唯一索引：与"普通索引"类似，不同的就是：索引列的值必须唯一，但允许有空值。
主键索引：它是一种特殊的唯一索引，不允许有空值。
全文索引：针对较大的数据，生成全文索引很耗时好空间。
组合索引：为了更多的提高mysql效率可建立组合索引，遵循”最左前缀“原则。

什么是自适应哈希索引（AHI）？

InnodB存储引擎会监控对表上各索引页的查询。如果观察到建立哈希索引可以带来速度提升,则建立哈希索引,称之为自适应哈希索引( Adaptive Hash Index,AHI) AHI是通过缓冲池的B+树页构造而来,因此建立的速度很快,而且不需要对整张表构建哈希索引。 InnoDB存储引擎会自动根据访问的频率和模式来自动地为某些热点页建立哈希索引。
AH有一个要求,即对这个页的连续访问模式必须是一样的。例如对于(a,b)这样的联合索引页,其访问模式可以是以下情况:

WHERE a=xxx
WHERE a= xxx and b=xxx

访问模式一样指的是査询的条件一样,若交替进行上述两种查询,那么 InnoDB存储引擎不会对该页构造AH此外AH还有如下的要求:

以该模式访问了100次
页通过该模式访问了N次,其中=页中记录*1/16

根据 InnoDB存储引擎官方的文档显示,启用AHI后,读取和写入速度可以提高2倍,辅助索引的连接操作性能可以提高5倍。

MySQL索引的原理？B树和B+树的区别？为什么要用 B+tree作为MySQL索引的数据结构？

B+treehttps://www.cnblogs.com/tiancai/p/9024351.html

可以使用多少列创建索引？

mysql中提到,一个表最多16个索引,最大索引长度256字节

什么样的字段适合建索引？

1、表的主键、外键必须有索引；
2、数据量超过300的表应该有索引；
3、经常与其他表进行连接的表，在连接字段上应该建立索引；
4、经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
5、索引应该建在选择性高的字段上；
6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；
7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：

A、正确选择复合索引中的主列字段，一般是选择性较好的字段；

B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？如果是，则可以建立复合索引；否则考虑单字段索引；

C、如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引；

E、如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引；

8、频繁进行数据操作的表，不要建立太多的索引；
9、删除无用的索引，避免对执行计划造成负面影响；

聚集索引与非聚集索引的区别？

根本区别

聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致。
聚集索引

聚集索引表记录的排列顺序和索引的排列顺序一致，所以查询效率快，只要找到第一个索引值记录，其余就连续性的记录在物理也一样连续存放。聚集索引对应的缺点就是修改慢，因为为了保证表中记录的物理和索引顺序一致，在记录插入的时候，会对数据页重新排序。
非聚集索引

非聚集索引制定了表中记录的逻辑顺序，但是记录的物理和索引不一定一致，两种索引都采用B+树结构，非聚集索引的叶子层并不和实际数据页相重叠，而采用叶子层包含一个指向表中的记录在数据页中的指针方式。非聚集索引层次多，不会造成数据重排

MySQL 索引使用的注意事项？

最左原则，不要判断null,不要索引字段上用函数。

遇到过索引失效的情况没，什么时候可能会出现，如何解决？

1.如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)；要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引

2.对于多列索引，不是使用的第一部分，则不会使用索引；最好全值匹配——索引怎么建我怎么用

3.like查询是以%开头

4.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引

5.如果mysql估计使用全表扫描要比使用索引快,则不使用索引

6.不在索引列上做任何操作（计算，函数，（自动或者手动）类型装换），会导致索引失效而导致全表扫描。——MYSQL自带api函数操作，如：left等

7.存储引擎不能使用索引中范围条件右边的列。——范围之后索引失效。（< ,> between and,）

8.is null或者is not null 也会导致无法使用索引。

9.在MYSQL使用不等于（<,>,!=）的时候无法使用索引，会导致索引失效。

什么是全文索引，全文索引中的倒排索引是什么原理？（不太明白，不常用）

https://blog.csdn.net/weigeshikebi/article/details/80342726

什么是组合索引？数据库最佳左前缀原则是什么？

回表：回到主键索引树搜索的过程，称为回表
覆盖索引：某索引已经覆盖了查询需求，称为覆盖索引，例如：select ID from T where k between 3 and 5
在引擎内部使用覆盖索引在索引K上其实读了三个记录，R3~R5(对应的索引k上的记录项)，但对于MySQL的Server层来说，它就是找引擎拿到了两条记录，因此MySQL认为扫描行数是2
最左前缀原则：B+Tree这种索引结构，可以利用索引的"最左前缀"来定位记录
只要满足最左前缀，就可以利用索引来加速检索。
最左前缀可以是联合索引的最左N个字段，也可以是字符串索引的最左M个字符
第一原则是：如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。
索引下推：在MySQL5.6之前，只能从根据最左前缀查询到ID开始一个个回表。到主键索引上找出数据行，再对比字段值。
MySQL5.6引入的索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。

选择普通索引还是唯一索引？

https://blog.csdn.net/w372426096/article/details/88120004

对于查询过程来说：
a、普通索引，查到满足条件的第一个记录后，继续查找下一个记录，知道第一个不满足条件的记录
b、唯一索引，由于索引唯一性，查到第一个满足条件的记录后，停止检索
但是，两者的性能差距微乎其微。因为InnoDB根据数据页来读写的。
对于更新过程来说：
概念：change buffer
当需要更新一个数据页，如果数据页在内存中就直接更新，如果不在内存中，在不影响数据一致性的前提下，InnoDB会将这些更新操作缓存在change buffer中。下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中的与这个页有关的操作。
change buffer是可以持久化的数据。在内存中有拷贝，也会被写入到磁盘上
purge:将change buffer中的操作应用到原数据页上，得到最新结果的过程，成为purge
访问这个数据页会触发purge，系统有后台线程定期purge，在数据库正常关闭的过程中，也会执行purge
唯一索引的更新不能使用change buffer
change buffer用的是buffer pool里的内存，change buffer的大小，可以通过参数innodb_change_buffer_max_size来动态设置。这个参数设置为50的时候，表示change buffer的大小最多只能占用buffer pool的50%。
将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一。
change buffer 因为减少了随机磁盘访问，所以对更新性能的提升很明显。
change buffer使用场景
在一个数据页做purge之前，change buffer记录的变更越多，收益就越大。
对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。
反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在change buffer,但之后由于马上要访问这个数据页，会立即触发purge过程。
这样随机访问IO的次数不会减少，反而增加了change buffer的维护代价。所以，对于这种业务模式来说，change buffer反而起到了副作用。
索引的选择和实践：
尽可能使用普通索引。
redo log主要节省的是随机写磁盘的IO消耗(转成顺序写)，而change buffer主要节省的则是随机读磁盘的IO消耗。

监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill；
    Percona 的 pt-kill 这个工具不错，推荐使用；
    在业务功能测试阶段要求输出所有的 general_log，分析日志行为提前发现问题；
    如果使用的是 MySQL 5.6 或者更新版本，把 innodb_undo_tablespaces 设置成 2（或更大的值）。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。

如果某次写入使用了 change buffer 机制，之后主机异常重启，是否会丢失 change buffer 和数据。

不会丢失。虽然是只更新内存，但是在事务提交的时候，把 change buffer 的操作也记录到 redo log 里了，所以崩溃恢复的时候，change buffer 也能找回来。

merge 的过程是否会把数据直接写回磁盘。

merge 的执行流程是这样的：

从磁盘读入数据页到内存（老版本的数据页）；

从 change buffer 里找出这个数据页的 change buffer 记录 (可能有多个），依次应用，得到新版数据页；

写 redo log。这个 redo log 包含了数据的变更和 change buffer 的变更。

到这里 merge 过程就结束了。这时候，数据页和内存中 change buffer 对应的磁盘位置都还没有修改，属于脏页，之后各自刷回自己的物理数据，就是另外一个过程了。

为什么用自增列作为主键？

如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页

如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置，此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。

综上总结，如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的，也就是下面这几种情况的存取效率最高：

1、使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的，和B+数叶子节点分裂顺序一致；

2、该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这时候InnoDB会选择内置的ROWID作为主键，写入顺序和ROWID增长顺序一致；
除此以外，如果一个InnoDB表又没有显示主键，又有可以被选择为主键的唯一索引，但该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况)，该表的存取效率就会比较差。

什么情况下应不建或少建索引？

1. 表记录太少

2. 经常插入、删除、修改的表

3. 数据重复且分布平均的表字段

key和index的区别？

1).key 是数据库的物理结构，它包含两层意义，一是约束（偏重于约束和规范数据库的结构完整性），二是索引（辅助查询用的）。包括primary key, unique key, foreign key 等。
primary key 有两个作用，一是约束作用（constraint），用来规范一个存储主键和唯一性，但同时也在此key上建立了一个index；
unique key 也有两个作用，一是约束作用（constraint），规范数据的唯一性，但同时也在这个key上建立了一个index；
foreign key也有两个作用，一是约束作用（constraint），规范数据的引用完整性，但同时也在这个key上建立了一个index；
可见，mysql的key是同时具有constraint和index的意义，这点和其他数据库表现的可能有区别。（至少在Oracle上建立外键，不会自动建立index），因此创建key也有如下几种方式：
（1）在字段级以key方式建立，如 create table t (id int not null primary key);
（2）在表级以constraint方式建立，如create table t(id int, CONSTRAINT pk_t_id PRIMARY key (id));
（3）在表级以key方式建立，如create table t(id int, primary key (id));
其它key创建类似，但不管那种方式，既建立了constraint，又建立了index，只不过index使用的就是这个constraint或key。
2).index是数据库的物理结构，它只是辅助查询的，它创建时会在另外的表空间（mysql中的innodb表空间）以一个类似目录的结构存储。索引要分类的话，分为前缀索引、全文本索引等；
因此，索引只是索引，它不会去约束索引的字段的行为（那是key要做的事情）。
如，create table t(id int, index inx_tx_id (id));
3).最后的释疑：
(1).我们说索引分类，分为主键索引、唯一索引、普通索引(这才是纯粹的index)等，也是基于是不是把index看作了key。
比如 create table t(id int, unique index inx_tx_id (id)); --index当作了key使用
(2).最重要的也就是，不管如何描述，理解index是纯粹的index，还是被当作key，当作key时则会有两种意义或起两种作用。

列值为NULL时，查询是否会用到索引？

不会

MyISAM索引实现？

MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。

1）主键索引：

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。

2）辅助索引（Secondary key）

在MyISAM中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。

MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。

事务：

数据一致性问题目前来说主要分为三类
1.主从不一致
解决办法:半同步复制after_commit,after_sync,MGR(after_prepare)。但是都不能完成满足完全实时一致,由于等待的ack点不同,相对来说一致性的强度是递增.
2.数据库与缓存的不一致
解决办法:读操作直接读缓存,写操作先更新到数据库,淘汰缓存(程序需要保证两个操作的原子性).由于该key的缓存已经清理掉,那么下次读的时候需要先读数据库,在重建缓存.
由于redis是单线程,保证了一个操作的原子性.可以通过设置appendfsync always来保证每次操作都把该操作记录并落盘到aof文件里(不过一般redis该值为everysec),毕竟使用redis的目的不是为了保证acid.还是要根据业务来选择
3.一个事务跨多个节点或者多种数据库(分库分表和银行转账这种例子)
目前好像都是通过2pc,3pc来保证的。

分布式事务的理解，常见的解决方案有哪些，什么是两阶段提交、三阶段提交；

两阶段提交

数据库事务ACID（原子性、一致性、隔离性、持久性）?

原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性

⑴ 原子性（Atomicity）

一个事物内所有操作共同组成一个原子包，要么全部成功，要么全部失败。这是最基本的特性，保证了因为一些其他因素导致数据库异常，或者宕机。

⑵ 一致性（Consistency）

原子性只保证了一个事物内的所有操作同一性，大家同生死。但是，原子性并没有保证大家同一时刻一起生，一起死。计算机指令是有先后顺序的，这样就决定了一个事物的提交，会经历一个时间过程，那么如果事物提交进行到了一半，我读取了数据库，会不会读到中间结果？

为了防止这样的情况，数据库事物的一致性就规定了事物提交前后，永远只可能存在事物提交前的状态和事物提交后的状态，从一个一致性的状态到另一个一致性状态，而不可能出现中间的过程态。也就是说事物的执行结果是量子化状态，而不是线性状态。

数据库提交事物会有一个过程，如果提交的时候，存在一个时间差，在提交的第一秒，一个删除过程还没完成到了第三秒才完成，会不会第一秒访问的人和第三秒访问的人得到不同的结果？出现不一致，状态的混沌？这就是一致性得保证的只会有前状态和后状态，绝不会出现中间态。

⑶ 隔离性（Isolation）

因为事物是原子化，量子化的，所以，事物可以有多个原子包的形式并发执行，但是，每个事物互不干扰。

但是，由于多个事物可能操作同一个资源，不同的事物为了保证隔离性，会有很多锁方案，当然这是数据库的实现。

⑷ 持久性（Durability）

持久性，当一个事物提交之后，数据库状态永远的发生了改变，这个事物只要提交了，哪怕提交后宕机，他也确确实实的提交了，不会出现因为刚刚宕机了而让提交不生效，是要事物提交，他就像洗不掉的纹身，永远的固化了，除非你毁了硬盘。

事务的隔离级别（读未提交、读以提交、可重复读、可序列化读）?

1、事务的特性：原子性、一致性、隔离性、持久性
2、多事务同时执行的时候，可能会出现的问题：脏读、不可重复读、幻读
3、事务隔离级别：读未提交、读提交（Oracle默认）、可重复读（Mysql默认）、串行化
4、不同事务隔离级别的区别：
读未提交：一个事务还未提交，它所做的变更就可以被别的事务看到
读提交：一个事务提交之后，它所做的变更才可以被别的事务看到
可重复读：一个事务执行过程中看到的数据是一致的。未提交的更改对其他事务是不可见的
串行化：对应一个记录会加读写锁，出现冲突的时候，后访问的事务必须等前一个事务执行完成才能继续执行

脏读、幻读、不可重复读 ?

不考虑隔离性会出现的读问题
脏读:在一个事务中读取到另一个事务没有提交的数据
不可重复读:在一个事务中,两次查询的结果不一致(针对的update操作)
虚读(幻读):在一个事务中,两次查询的结果不一致(针对的insert操作)
通过设置数据库的隔离级别来避免上面的问题(理解)
read uncommitted 读未提交上面的三个问题都会出现
read committed 读已提交可以避免脏读的发生
repeatable read 可重复读可以避免脏读和不可重复读的发生
serializable 串行化可以避免所有的问题

MySQL并发情况下怎么解决（通过事务、隔离级别、锁）?怎么解决幻读

多版本并发控制（MVCC）；可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。

MVCC实现是不同的，典型的有乐观（optimistic）并发控制控制和悲观（pessimistic）并发控制。

InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号（systemversionnumber）。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。下面看一下在可重复读隔离级别下，MVCC具体是如何操作的。

SELECT InnoDB会根据以下两个条件检查每行记录：InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。只有符合上述两个条件的记录，才能返回作为查询结果。

INSERT InnoDB为新插入的每一行保存当前系统版本号作为行版本号。

DELETE InnoDB为删除的每一行保存当前系统版本号作为行删除标识。

UPDATE InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。MVCC只在可重复读和读提交两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容(4)，因为读未提交总是读取最新的数据行，而不是符合当前事务版本的数据行。而串行化则会对所有读取的行都加锁。

数据库中的隔离性是怎样实现的；原子性、一致性、持久性又是如何实现的?

MVCC（Multi-Versioning Concurrency Control）和锁的复合实现的。

读未提交：

读提交：MVCC

可重复读：MVCC

在RR级别下，如果WHERE的条件列上有唯一索引，那么MySQL只加行级锁；如果是普通索引，会加间隙锁来防止幻读；如果没有索引，就会首先锁表的所有记录、再释放不符合条件的行的锁，因此会大大降低并发写的能力。

串行化：

读写均加表级的读写锁即可，直接读主键索引B+树的叶子节点的最新数据。该级别下，数据一致性很强，但是并发写的能力非常差。

所有的读不加锁，读到的都是叶子节点上最新的值，性能最好。
所有的写（更新、插入、删除）加行级排斥锁，不存在脏写的问题，写完就释放锁。
先说RC级别的写操作，MySQL依然加行级排斥锁。事务开始时会往UNDO日志中写入当前的有效记录值，B+树叶子节点的隐藏列DATA_ROLL_PTR会存储指向该UNDO记录的指针。顺着行的DATA_ROLL_PTR的指针形成一个链表，记录该行数据的有效的历史记录。
再说不加锁的读操作，如果叶子节点正被其他事务锁定，那么MySQL顺着叶子节点的DATA_ROLL_PTR指针找到上一个有效的历史记录即可。

MySQL中的MVCC机制是什么意思，根据具体场景，MVCC是否有问题?

多版本并发控制（MVCC）

1)每个事务都有一个事务ID,叫做transaction id(严格递增)
(2)事务在启动时,找到已提交的最大事务ID记为up_limit_id。
(3)事务在更新一条语句时,比如id=1改为了id=2.会把id=1和该行之前的row trx_id写到undo log里,
并且在数据页上把id的值改为2,并且把修改这条语句的transaction id记在该行行头
(4)再定一个规矩,一个事务要查看一条数据时,必须先用该事务的up_limit_id与该行的transaction id做比对,
如果up_limit_id>=transaction id,那么可以看.如果up_limit_id<transaction id,则只能去undo log里去取。去undo log查找数据的时候,也需要做比对,必须up_limit_id>transaction id,才返回数据

在MVCC并发控制中，读操作可以分成两类?

读提交，可重复读

如何避免长事务对业务的影响？

分解小批量事务处理

首先，从应用开发端来看：

确认是否使用了 set autocommit=0。这个确认工作可以在测试环境中开展，把 MySQL 的 general_log 开起来，然后随便跑一个业务逻辑，通过 general_log 的日志来确认。一般框架如果会设置这个值，也就会提供参数来控制行为，你的目标就是把它改成 1。
确认是否有不必要的只读事务。有些框架会习惯不管什么语句先用 begin/commit 框起来。我见过有些是业务并没有这个需要，但是也把好几个 select 语句放到了事务中。这种只读事务可以去掉。
业务连接数据库的时候，根据业务本身的预估，通过 SET MAX_EXECUTION_TIME 命令，来控制每个语句执行的最长时间，避免单个语句意外执行太长时间。（为什么会意外？在后续的文章中会提到这类案例）

其次，从数据库端来看：(事务隔离相关)

1.innodb支持RC和RR隔离级别实现是用的一致性视图(consistent read view)

2.事务在启动时会拍一个快照,这个快照是基于整个库的.
基于整个库的意思就是说一个事务内,整个库的修改对于该事务都是不可见的(对于快照读的情况)
如果在事务内select t表,另外的事务执行了DDL t表,根据发生时间,要嘛锁住要嘛报错

什么是事务？什么是锁？

事务（Transaction）是并发控制的基本单位。

所谓的事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。

数据库锁的基本类型：

X锁：exclusive 用于写操作
    - 某数据对象在没有加任何锁的情况下，一个事务可以对其加X锁，而其他事务就不能对其再加任何锁
    S锁：share 用于读操作
    - 一个事务对某数据对象加了S 锁后，其他事务就不能对其加X锁，但可以加S锁
    U锁：update
    - 事务要更新数据对象时，先申请该对象的U 锁。对象加了U锁，允许其他事务对它加S锁。在最后写入时，再申请将U锁升级为X锁。不必在全过程中加X

不同级别的加锁协议

一级封锁协议（脏数据、不可重复读）
        任一事务在写某数据前，必须对其加上X锁，该事务结束后才释放。不采用S锁，读数据不用加锁。
        事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。
    二级封锁协议（不可重复读）
        满足一级封锁协议，且任一事务在读取某数据前，必须对其加上S锁，读完后就释放
    三级封锁协议（）
        满足一级封锁协议，且任一事务在读取某数据前，必须对其加上S锁，事务结束后释放锁

对应的我们便可以看到隔离级别和加锁协议之间的关系：
    一级封锁协议 -> READ UNCOMMITTED
    二级封锁协议 -> READ COMMITTED
    三级封锁协议 -> REPEATABLE READ

其他加锁协议

两阶段加锁协议：
整个事务分为两个阶段，前一个阶段为加锁，后一个阶段为解锁。在加锁阶段，事务只能加锁，也可以操作数据，但不能解锁，直到事务释放第一个锁，就进入解锁阶段，此过程中事务只能解锁，也可以操作数据，不能再加锁。两阶段锁协议使得事务具有较高的并发度，因为解锁不必发生在事务结尾。它的不足是没有解决死锁的问题，因为它在加锁阶段没有顺序要求。如两个事务分别申请了A, B锁，接着又申请对方的锁，此时进入死锁状态。
定理：若所有事务均遵守两段锁协议，则这些事务的所有交叉调度都是可串行化的。

多粒度加锁协议
        行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。只在存储引擎层实现
        页级锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
        表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

日志：

https://mp.weixin.qq.com/s/aXF78FpZdQieAfzuyVYCyg

https://blog.csdn.net/w372426096/article/details/87856608

什么是redo日志、什么是undo日志?

mysql的binlog?

redolog是物理的，binlog是逻辑的；现在由于redo是属于InnoDB引擎，所以必须要有binlog，因为你可以使用别的引擎
保证数据库的一致性，必须要保证2份日志一致，使用的2阶段式提交；其实感觉像事务，不是成功就是失败，不能让中间环节出现，也就是一个成功，一个失败
如果有一天mysql只有InnoDB引擎了，有redo来实现复制，那么感觉oracle的DG就诞生了，物理的速度也将远超逻辑的，毕竟只记录了改动向量

MySQL记录binlog的方式主要包括三种模式？每种模式的优缺点是什么？

binlog几大模式，一般采用row，因为遇到时间，从库可能会出现不一致的情况，但是row更新前后都有，会导致日志变大
最后2个参数，保证事务成功，日志必须落盘，这样，数据库crash后，就不会丢失某个事务的数据了
备份时间问题：
备份时间周期的长短，感觉有2个方便
首先，是恢复数据丢失的时间，既然需要恢复，肯定是数据丢失了。如果一天一备份的话，只要找到这天的全备，加入这天某段时间的binlog来恢复，如果一周一备份，假设是周一，而你要恢复的数据是周日某个时间点，那就，需要全备+周一到周日某个时间点的全部binlog用来恢复，时间相比前者需要增加很多；看业务能忍受的程度
其次，是数据库丢失，如果一周一备份的话，需要确保整个一周的binlog都完好无损，否则将无法恢复；而一天一备，只要保证这天的binlog都完好无损；当然这个可以通过校验，或者冗余等技术来实现，相比之下，上面那点更重要

① STATEMENT模式（SBR）

每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)

② ROW模式（RBR）

不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。

③ MIXED模式（MBR）

以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。

SBR 的优点：

历史悠久，技术成熟
binlog文件较小
binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
binlog可以用于实时的还原，而不仅仅用于复制
主从版本可以不一样，从服务器版本可以比主服务器版本高
SBR 的缺点：

不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
调用具有不确定因素的 UDF 时复制也可能出问题
使用以下函数的语句也无法被复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
INSERT ... SELECT 会产生比 RBR 更多的行级锁
复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁
对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句
对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响
存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事
确定了的 UDF 也需要在从服务器上执行
数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错
执行复杂语句如果出错的话，会消耗更多资源

RBR 的优点：

任何情况都可以被复制，这对复制来说是最安全可靠的
和其他大多数数据库系统的复制技术一样
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
复制以下几种语句时的行锁更少：
* INSERT ... SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
执行 INSERT，UPDATE，DELETE 语句时锁更少
从服务器上采用多线程来执行复制成为可能

RBR 的缺点：

binlog 大了很多
复杂的回滚时 binlog 中会包含大量的数据
主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题
UDF 产生的大 BLOB 值会导致复制变慢
无法从 binlog 中看到都复制了写什么语句
当在非事务表上执行一段堆积的SQL语句时，最好采用 SBR 模式，否则很容易导致主从服务器的数据不一致情况发生

binlog主从复制?

https://blog.csdn.net/w372426096/article/details/88173152

锁：

https://blog.csdn.net/xts5701046/article/details/81395958

Mysql中有哪几种锁？

MySQL各存储引擎使用了三种类型（级别）的锁定机制：表级锁定，行级锁定和页级锁定。

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高；
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

https://www.cnblogs.com/sessionbest/articles/8689071.html

悲观锁和乐观锁的原理和应用场景？

悲观锁和乐观锁，也并不是 MySQL 或者数据库中独有的概念，而是并发编程的基本概念。主要区别在于，操作共享数据时，“悲观锁”即认为数据出现冲突的可能性更大，而“乐观锁”则是认为大部分情况不会出现冲突，进而决定是否采取排他性措施。

反映到 MySQL 数据库应用开发中，悲观锁一般就是利用类似 SELECT … FOR UPDATE 这样的语句，对数据加锁，避免其他事务意外修改数据。乐观锁则与 Java 并发包中的 AtomicFieldUpdater 类似，也是利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，来实现乐观锁需要的版本判断。

我认为前面提到的 MVCC，其本质就可以看作是种乐观锁机制，而排他性的读写锁、双阶段锁等则是悲观锁的实现。

意向锁有什么用？

（1）申请意向锁的动作是数据库完成的，就是说，事务A申请一行的行锁的时候，数据库会自动先开始申请表的意向锁，不需要我们程序员使用代码来申请。

（2）IX，IS是表级锁，不会和行级的X，S锁发生冲突。只会和表级的X，S发生冲突行级别的X和S按照普通的共享、排他规则即可。

备注: IX 意向排它锁，IS 意向读锁，X 排它锁，S 共享锁

MySQL遇到的死锁问题、如何排查与解决？

https://mp.weixin.qq.com/s/bRKcuUo3Pbfv6CPK82Y01A

全局锁，表级锁？

全局锁就是对整个数据库实例加锁。MySQL 提供了一个加全局锁的方法，命令是 Flush tables with read lock(FTWRL)。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。

全局锁的典型使用场景是：做全库逻辑备份。也就是把整库每个表都 select 出来存成文本。

表锁的语法是：lock tables ... read/write。与 FTWRL 类似，可以使用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。需要注意的是，lock tables 语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。

元数据锁：MDL

另一类表级别的是 MDL （metadata lock）。MDL 不需要显示使用，在访问一个表的时候会被自动加上。MDL 的作用是：保证读写的正确性。你可以想象下，如果一个查询正在遍历一个表的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询线程拿到的结果是和表结构对不上的，肯定是不行的。

因此，在 MySQL5.5 版本中引入 MDL，当对一个表做增删该查操作时，加 MDL 读锁；当对表结构变更操作的时候，加 MDL 写锁。

读锁之间不互斥，因此你可以有多个线程同时对一张表增删该查；
读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完后才能开始执行。

行级锁定的优点？行级锁定的缺点？

MySQL 的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如 MyISAM 引擎就不支持行锁。不支持行锁意味着并发控制使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行。这就会影响到业务的并发度。InnoDB 是支持行锁的，这也是 MyISAM 被 InnoDB 替代的重要原因之一。

行锁的劣势：开销大；加锁慢；会出现死锁

行锁的优势：锁的粒度小，发生锁冲突的概率低；处理并发的能力强

加锁的方式：自动加锁。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；对于普通SELECT语句，InnoDB不会加任何锁；当然我们也可以显示的加锁：

共享锁：select * from tableName where … + lock in share more

排他锁：select * from tableName where … + for update

InnoDB和MyISAM的最大不同点有两个：一，InnoDB支持事务(transaction)；二，默认采用行级锁。加锁可以保证事务的一致性，可谓是有人(锁)的地方，就有江湖(事务)；我们先简单了解一下事务知识。

行锁优化

1 尽可能让所有数据检索都通过索引来完成，避免无索引行或索引失效导致行锁升级为表锁。

2 尽可能避免间隙锁带来的性能下降，减少或使用合理的检索范围。

3 尽可能减少事务的粒度，比如控制事务大小，而从减少锁定资源量和时间长度，从而减少锁的竞争等，提供性能。

4 尽可能低级别事务隔离，隔离级别越高，并发的处理能力越低。

好文：https://www.cnblogs.com/wintersoft/p/10787474.html

分表，分库：

说说分库与分表设计？

https://blog.csdn.net/qq_28289405/article/details/80576614

分库与分表带来的分布式困境与应对之策（如何解决分布式下的分库分表，全局表）？

还需要补充

https://blog.csdn.net/xiao__jia__jia/article/details/81150112

如何判断当前MySQL是否支持分区？

https://www.cnblogs.com/yuzhoushenqi/p/7079616.html

MySQL支持的分区类型有哪些？

https://www.cnblogs.com/mliudong/p/3625522.html

数据库需要扩容，原来分50个库扩容到100个，怎么在不影响用户使用的情况下做扩容

https://m.w3cschool.cn/architectroad/architectroad-database-smooth-expansion.html

优化：

聊下优化过的索引，怎么优化?

https://blog.csdn.net/w372426096/article/details/88734787

explain命令 ?

https://blog.csdn.net/w372426096/article/details/82421378

常见的数据库优化方案，在你的项目中数据库如何进行优化的 ?

慢sql优化，缓存，读写分离，设计表时候垂直拆分，终极水平拆分

第一阶段优化sql和索引

这一步成本最低啊，不需要加什么中间件。你没经过索引优化和SQL优化。

步骤大概

用慢查询日志定位执行效率低的 SQL语句

用 explain分析 SQL的执行计划

确定问题，采取相应的优化措施，建立索引啊，等

第二阶段搭建缓存

在优化sql无法解决问题的情况下，才考虑搭建缓存。毕竟你使用缓存的目的，就是将复杂的、耗时的、不常变的执行结果缓存起来，降低数据库的资源消耗。

这里需要注意的是:搭建缓存后，系统的复杂性增加了。你需要考虑很多问题，比如:

缓存和数据库一致性问题？(比如是更缓存，还是删缓存),这点可以看我的一篇文章《数据库和缓存双写一致性方案解析》。

缓存击穿、缓存穿透、缓存雪崩问题如何解决？是否有做缓存预热的必要。不过我猜，大部分中小公司应该都没考虑。这点可以看我的另一篇《分布式之redis复习精讲》

第三阶段读写分离

缓存也搞不定的情况下，搞主从复制，上读写分离。在应用层，区分读写请求。或者利用现成的中间件 mycat或者 altas等做读写分离。

需要注意的是,只要你敢说你用了主从架构，有三个问题，你要准备:

1.主从的好处？

回答:实现数据库备份，实现数据库负载均衡，提高数据库可用性

2.主从的原理?

回答:如图所示（图片不是自己画的，偷懒了）

主库有一个 logdump线程，将 binlog传给从库

从库有两个线程，一个I/O线程，一个SQL线程，I/O线程读取主库传过来的 binlog内容并写入到 relay log,SQL线程从 relay log里面读取内容，写入从库的数据库。

3.如何解决主从一致性?

回答:这个问题，我不建议在数据库层面解决该问题。根据 CAP 定理，主从架构本来就是一种高可用架构，是无法满足一致性的。哪怕你采用同步复制模式或者半同步复制模式，都是弱一致性，并不是强一致性。所以，推荐还是利用缓存，来解决该问题。

步骤如下:

自己通过测试，计算主从延迟时间，建议mysql版本为5.7以后，因为mysql自5.7开始，多线程复制功能比较完善，一般能保证延迟在1s内。不过话说回来，mysql现在都出到8.x了，还有人用5.x的版本么。

数据库的写操作，先写数据库，再写cache，但是有效期很短，就比主从延时的时间稍微长一点。

读请求的时候，先读缓存，缓存存在则直接返回。如果缓存不存在(这时主从同步已经完成)，再读数据库。

第四阶段利用分区表

说句实在话，你们面试的时候，其实可以略过这个阶段。因为很多互联网公司都不建议用分区表，我自己也不太建议用分区表，采用这个分区表，坑太多。

这里引用一下其他文章的回答:

什么是mysql的分区表？

回答：所有数据还在一个表中，但物理存储根据一定的规则放在不同的文件中。这个是mysql支持的功能，业务代码不需要改动，但是sql语句需要改动，sql条件需要带上分区的列。

缺点

分区键设计不太灵活，如果不走分区键，很容易出现全表锁

在分区表使用 ALTER TABLE … ORDER BY，只能在每个分区内进行 orderby。

分区表的分区键创建索引，那么这个索引也将被分区。分区键没有全局索引一说。

自己分库分表，自己掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不确定该去哪个分区查，不太可控。 …不列举了，不推荐

第五阶段垂直拆分

上面四个阶段都没搞定，就来垂直拆分了。垂直拆分的复杂度还是比水平拆分小的。将你的表，按模块拆分为不同的小表。大家应该都看过《大型网站架构演变之路》，这种类型的文章或者书籍，基本都有提到这一阶段。

如果你有幸能够在什么运营商、银行等公司上班，你会发现他们一个表，几百个字段都是很常见的事情。所以，应该要进行拆分，拆分原则一般是如下三点:

把不常用的字段单独放在一张表。

把常用的字段单独放一张表

经常组合查询的列放在一张表中（联合索引）。

第六阶段水平拆分

OK,水平拆分是最麻烦的一个阶段，拆分后会有很多的问题，我再强调一次，水平拆分一定是最最最最后的选择。从某种意义上，我觉得还不如垂直拆分。因为你用垂直拆分，分成不同模块后，发现单模块的压力过大，你完全可以给该模块单独做优化，例如提高该模块的机器配置等。如果是水平拆分，拆成两张表，代码需要变动，然后发现两张表还不行，再变代码，再拆成三张表的？水平拆分后，各模块间耦合性太强，成本太大，慎重。

一条SQL语句执行得很慢的原因有哪些？对于SQL慢查询的优化？平时你们是怎么监控数据库的? 慢SQL是怎么排查的？（慢查询日志）

Mycat

https://www.cnblogs.com/qmfsun/p/4844472.html

其实，这个问题可以涉及到 MySQL 的很多核心知识，可以扯出一大堆，就像要考你计算机网络的知识时，问你“输入URL回车之后，究竟发生了什么”一样，看看你能说出多少了。

本文的作者就是这道面试题的亲历者，他尝试总结了一下：

一、开始装逼：分类讨论

一条 SQL 语句执行的很慢，那是每次执行都很慢呢？还是大多数情况下是正常的，偶尔出现很慢呢？所以我觉得，我们还得分以下两种情况来讨论。

1、大多数情况是正常的，只是偶尔会出现很慢的情况。

2、在数据量不变的情况下，这条SQL语句一直以来都执行的很慢。

针对这两种情况，我们来分析下可能是哪些原因导致的。

二、针对偶尔很慢的情况

一条 SQL 大多数情况正常，偶尔才能出现很慢的情况，针对这种情况，我觉得这条SQL语句的书写本身是没什么问题的，而是其他原因导致的，那会是什么原因呢？

1、数据库在刷新脏页（flush）我也无奈啊

当我们要往数据库插入一条数据、或者要更新一条数据的时候，我们知道数据库会在内存中把对应字段的数据更新了，但是更新之后，这些更新的字段并不会马上同步持久化到磁盘中去，而是把这些更新的记录写入到 redo log 日记中去，等到空闲的时候，在通过 redo log 里的日记把最新的数据同步到磁盘中去。

当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。

刷脏页有下面4种场景（后两种不用太关注“性能”问题）：

redolog写满了：redo log 里的容量是有限的，如果数据库一直很忙，更新又很频繁，这个时候 redo log 很快就会被写满了，这个时候就没办法等到空闲的时候再把数据同步到磁盘的，只能暂停其他操作，全身心来把数据同步到磁盘中去的，而这个时候，就会导致我们平时正常的SQL语句突然执行的很慢，所以说，数据库在在同步数据到磁盘的时候，就有可能导致我们的SQL语句执行的很慢了。
内存不够用了：如果一次查询较多的数据，恰好碰到所查数据页不在内存中时，需要申请内存，而此时恰好内存不足的时候就需要淘汰一部分内存数据页，如果是干净页，就直接释放，如果恰好是脏页就需要刷脏页。
MySQL 认为系统“空闲”的时候：这时系统没什么压力。
MySQL 正常关闭的时候：这时候，MySQL 会把内存的脏页都 flush 到磁盘上，这样下次 MySQL 启动的时候，就可以直接从磁盘上读数据，启动速度会很快。

2、拿不到锁我能怎么办

这个就比较容易想到了，我们要执行的这条语句，刚好这条语句涉及到的表，别人在用，并且加锁了，我们拿不到锁，只能慢慢等待别人释放锁了。或者，表没有加锁，但要使用到的某个一行被加锁了，这个时候，我也没办法啊。

如果要判断是否真的在等待锁，我们可以用show processlist这个命令来查看当前的状态哦，这里我要提醒一下，有些命令最好记录一下，反正，我被问了好几个命令，都不知道怎么写，呵呵。

下来我们来访分析下第二种情况，我觉得第二种情况的分析才是最重要的

三、针对一直都这么慢的情况

如果在数据量一样大的情况下，这条 SQL 语句每次都执行的这么慢，那就就要好好考虑下你的 SQL 书写了，下面我们来分析下哪些原因会导致我们的 SQL 语句执行的很不理想。

我们先来假设我们有一个表，表里有下面两个字段,分别是主键 id，和两个普通字段 c 和 d。

mysql> CREATE TABLE `t` (`id` int(11) NOT NULL,`c` int(11) DEFAULT NULL,`d` int(11) DEFAULT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB;

1、扎心了，没用到索引

没有用上索引，我觉得这个原因是很多人都能想到的，例如你要查询这条语句

select * from t where 100 <c and c < 100000;

（1）、字段没有索引

刚好你的 c 字段上没有索引，那么抱歉，只能走全表扫描了，你就体验不会索引带来的乐趣了，所以，这回导致这条查询语句很慢。

（2）、字段有索引，但却没有用索引

好吧，这个时候你给 c 这个字段加上了索引，然后又查询了一条语句

select * from t where c - 1 = 1000;

我想问大家一个问题，这样子在查询的时候会用索引查询吗？

答是不会，如果我们在字段的左边做了运算，那么很抱歉，在查询的时候，就不会用上索引了，所以呢，大家要注意这种字段上有索引，但由于自己的疏忽，导致系统没有使用索引的情况了。

正确的查询应该如下

select * from t where c = 1000 + 1;

有人可能会说，右边有运算就能用上索引？难道数据库就不会自动帮我们优化一下，自动把 c - 1=1000 自动转换为 c = 1000+1。

不好意思，确实不会帮你，所以，你要注意了。

（3）、函数操作导致没有用上索引

如果我们在查询的时候，对字段进行了函数操作，也是会导致没有用上索引的，例如

select * from t where pow(c,2) = 1000;

这里我只是做一个例子，假设函数 pow 是求 c 的 n 次方，实际上可能并没有 pow(c,2)这个函数。其实这个和上面在左边做运算也是很类似的。

所以呢，一条语句执行都很慢的时候，可能是该语句没有用上索引了，不过具体是啥原因导致没有用上索引的呢，你就要会分析了，我上面列举的三个原因，应该是出现的比较多的吧。

2、呵呵，数据库自己选错索引了

我们在进行查询操作的时候，例如

select * from t where 100 < c and c < 100000;

我们知道，主键索引和非主键索引是有区别的，主键索引存放的值是整行字段的数据，而非主键索引上存放的值不是整行字段的数据，而且存放主键字段的值。

也就是说，我们如果走 c 这个字段的索引的话，最后会查询到对应主键的值，然后，再根据主键的值走主键索引，查询到整行数据返回。

好吧扯了这么多，其实我就是想告诉你，就算你在 c 字段上有索引，系统也并不一定会走 c 这个字段上的索引，而是有可能会直接扫描扫描全表，找出所有符合 100 < c and c < 100000 的数据。

为什么会这样呢？

其实是这样的，系统在执行这条语句的时候，会进行预测：究竟是走 c 索引扫描的行数少，还是直接扫描全表扫描的行数少呢？显然，扫描行数越少当然越好了，因为扫描行数越少，意味着I/O操作的次数越少。

如果是扫描全表的话，那么扫描的次数就是这个表的总行数了，假设为 n；而如果走索引 c 的话，我们通过索引 c 找到主键之后，还得再通过主键索引来找我们整行的数据，也就是说，需要走两次索引。而且，我们也不知道符合 100 c < and c < 10000 这个条件的数据有多少行，万一这个表是全部数据都符合呢？这个时候意味着，走 c 索引不仅扫描的行数是 n，同时还得每行数据走两次索引。

所以呢，系统是有可能走全表扫描而不走索引的。那系统是怎么判断呢？

判断来源于系统的预测，也就是说，如果要走 c 字段索引的话，系统会预测走 c 字段索引大概需要扫描多少行。如果预测到要扫描的行数很多，它可能就不走索引而直接扫描全表了。

那么问题来了，系统是怎么预测判断的呢？这里我给你讲下系统是怎么判断的吧，虽然这个时候我已经写到脖子有点酸了。

系统是通过索引的区分度来判断的，一个索引上不同的值越多，意味着出现相同数值的索引越少，意味着索引的区分度越高。我们也把区分度称之为基数，即区分度越高，基数越大。所以呢，基数越大，意味着符合 100 < c and c < 10000 这个条件的行数越少。

所以呢，一个索引的基数越大，意味着走索引查询越有优势。

那么问题来了，怎么知道这个索引的基数呢？

系统当然是不会遍历全部来获得一个索引的基数的，代价太大了，索引系统是通过遍历部分数据，也就是通过采样的方式，来预测索引的基数的。

扯了这么多，重点的来了，居然是采样，那就有可能出现失误的情况，也就是说，c 这个索引的基数实际上是很大的，但是采样的时候，却很不幸，把这个索引的基数预测成很小。例如你采样的那一部分数据刚好基数很小，然后就误以为索引的基数很小。然后就呵呵，系统就不走 c 索引了，直接走全部扫描了。

所以呢，说了这么多，得出结论：由于统计的失误，导致系统没有走索引，而是走了全表扫描，而这，也是导致我们 SQL 语句执行的很慢的原因。

这里我声明一下，系统判断是否走索引，扫描行数的预测其实只是原因之一，这条查询语句是否需要使用使用临时表、是否需要排序等也是会影响系统的选择的。

不过呢，我们有时候也可以通过强制走索引的方式来查询，例如

select * from t force index(a) where c < 100 and c < 100000;

我们也可以通过

show index from t;

来查询索引的基数和实际是否符合，如果和实际很不符合的话，我们可以重新来统计索引的基数，可以用这条命令

analyze table t;

来重新统计分析。

既然会预测错索引的基数，这也意味着，当我们的查询语句有多个索引的时候，系统有可能也会选错索引哦，这也可能是 SQL 执行的很慢的一个原因。

好吧，就先扯这么多了，你到时候能扯出这么多，我觉得已经很棒了，下面做一个总结。

四、总结

以上是我的总结与理解，最后一个部分，我怕很多人不大懂数据库居然会选错索引，所以我详细解释了一下，下面我对以上做一个总结。

一个 SQL 执行的很慢，我们要分两种情况讨论：

1、大多数情况下很正常，偶尔很慢，则有如下原因

(1)、数据库在刷新脏页，例如 redo log 写满了需要同步到磁盘。

(2)、执行的时候，遇到锁，如表锁、行锁。

2、这条 SQL 语句一直执行的很慢，则有如下原因。

(1)、没有用上索引：例如该字段没有索引；由于对字段进行运算、函数操作导致无法用索引。

(2)、数据库选错了索引。

MySQL有多少个参数可调，除了最大连接数。全部列出来，一个个分析?

MYSQL数据库服务器性能分析的方法命令有哪些?

https://www.cnblogs.com/star91/p/5052206.html

讲下MySQL的集群？集群遇到过什么问题？

数据库高并发下的优化思路?

Mysql如何优化DISTINCT？

https://www.cnblogs.com/akeyf/p/7826004.html

案例场景：

给10万条数据，有重复和不重复的，如何查出前20条

SELECT keyword, count( * ) AS count
FROM article_keyword
GROUP BY keyword
ORDER BY count DESC
LIMIT 20

此段查询语句返回 article_keyword 表中 keyword 重复次数（count）最多的20条记录。

SELECT DISTINCT count( * ) AS count
FROM article_keyword
GROUP BY keyword
ORDER BY count DESC
LIMIT 6

limit 20000 加载很慢怎么解决

https://uule.iteye.com/blog/2422189

如何选择合适的分布式主键方案，常见的几种分布式ID的设计方案

选择合适的数据存储方案

一般情况下数据库宕机了如何进行恢复（什么是Write Ahead Log机制，什么是Double Write机制，什么是Check Point）；

数据库是否⽀持emoji表情，如果不⽀持，如何操作?选择什么编码方式？如果支持一个表情占几个字节?(utf8mb4)；如果查询很慢，你会想到的第⼀个⽅式是什么？（数据库索引）

https://blog.csdn.net/u013145194/article/details/51527389

你目前为止遇到的最大数据量是多少？知道100万时候怎么设计吗？1000万呢？过几十亿呢？

如何解决主从一致性?

根据 CAP 定理，主从架构本来就是一种高可用架构，是无法满足一致性的。哪怕你采用同步复制模式或者半同步复制模式，都是弱一致性，并不是强一致性。所以，推荐还是利用缓存，来解决该问题。

步骤如下:

数据库的写操作，先写数据库，再写cache，但是有效期很短，就比主从延时的时间稍微长一点。

读请求的时候，先读缓存，缓存存在则直接返回。如果缓存不存在(这时主从同步已经完成)，再读数据库。

读写分离何时强制要读主库，读哪个从库是通过什么方式决定的，从库的同步mysql用的什么方式

主从复制

对表做统计时可直接看schema info信息，即查看表的系统信息

统计100G的ip文件中出现ip次数最多的100个ip

https://blog.csdn.net/Iloveyougirls/article/details/81814524

项目 MySQL 的数据量和并发量有多大？

select * from table where a=1 and b=1; select * from table where b=1; select * from table where a=1; 你会如何创建索引？

ab;b

5万条数据怎么实现删除

第一种，直接执行 delete from T limit 50000;

第二种，在一个连接中循环执行 20 次delete from T limit 2500;

第三种，在20 个连接中同时执行 delete from T limit 2500.

第二种好，第一种单个语句占用时间长，锁的时间长，大事务导致主从延迟；第三种会认为造成锁冲突。

1.delete操作会生成插入相同记录的记录复用和page复用
2.delete会产生page空洞，随机insert也会产生page空洞(页分裂)，索引update分解为delete和insert也会产生空洞
3.重建表可以使数据在page上更紧凑
4.alter table tb_name engine=innodb 在非online ddl 时server层生成临时表且mdl写锁，阻塞其他会话dml操作，锁阻塞时间久。在online ddl时，时innodb引擎操作步骤：
a.扫描表页，获取表的dml读锁;
b.将表页复制到一个临时文件，以b+树格式存储;
c.在扫描和复制page的过程生成row.log日志记录ddl复制过程的dml操作;
d.将row.log操作日志应用到临时文件;
e.获取dml的写锁，临时文件与表文件替换

5.ddl online时，innodb表加全文索引时，会阻塞dml操作，其实效果与非online ddl一样的。ddl online一定是inplace;inplace 的ddl不一定是online,例如:添加fulltext索引和spatial索引
6.optimize table 重建表及索引，收集统计信息
alter table tb engine=innodb 重建表其实也收集统计信息
analyze table tb 重新收集统计信息

一张表，里面有ID自增主键，当insert了17条记录之后，删除了第15,16,17条记录，再把Mysql重启，再insert一条记录，这条记录的ID是18还是15 ？

一般情况下，我们创建的表的类型是InnoDB，如果新增一条记录（不重启mysql的情况下），这条记录的id是18；但是如果重启（文中提到的）MySQL的话，这条记录的ID是15。因为InnoDB表只把自增主键的最大ID记录到内存中，所以重启数据库或者对表OPTIMIZE操作，都会使最大ID丢失。

但是，如果我们使用表的类型是MylSAM，那么这条记录的ID就是18。因为MylSAM表会把自增主键的最大ID记录到数据文件里面，重启MYSQL后，自增主键的最大ID也不会丢失。

注:如果在这17条记录里面删除的是中间的几个记录（比如删除的是10,11,12三条记录），重启MySQL数据库后，insert一条记录后，ID都是18。因为内存或者数据库文件存储都是自增主键最大ID

如何查询第n高的工资？

 select discintct salary from employee order by Salary desc limit N,1

其他面试题补充：

https://blog.csdn.net/w372426096/article/details/80968221