sql

sql语法

数据定义DDL

数据操纵DML

数据查询DQL

数据控制DCL

事务管理TPL

指针控制

mysql -u root -p 

//数据定义DDL

create database database_name default character set utf8；

show databases;

drop database database_name;

use database_name ;

create table tablename(字段名1 字段类型1(字段长度),字段名2 字段类型2(字段长度));

show tables;

desc tablename;  查看表结构

drop table tablename;

alter table tablename xxx(操作) 修改表

修改列名
alter table tablename change 原列名 想改成的列名 列类型;
修改表的名字
alter table tablename rename 新表名 ;
修改列的类型
alter table tablename modify  列名 想改的类型;
增加某列
alter table tablename add 列名 类型;
删除某列
alter table tablename drop 列名;



select * from 表名;

insert into tablename values(值1,值2,...);	#值的个数、顺序要和字段的个数、顺序一样
insert into tablename.列名1,tablename.列名2 values(值1,值2);#给某一列添加数据

update tablename set 字段名 = 值；

delete from tablename;---删除全部表记录(表还在)

防止中文乱码
set name gbk;

字段约束

#### 主键约束

create table tablename(字段名1 字段类型1(字段长度) **primary key auto_increment**,
                字段名2 字段类型2(字段长度));

#### 非空约束

create table tablename(字段名1 字段类型1(字段长度),
                字段名2 字段类型2(字段长度) **not null** );

#### 唯一约束

create table tablename(字段名1 字段类型1(字段长度),
                字段名2 字段类型2(字段长度) **unique** );

#### 默认约束

sex CHAR(2) **DEFAULT** '男'

#### 检查约束

create table tablename(
age INT, 
CHECK (age>0 AND age<=200)
   );

#### 外检约束

FOREIGN KEY (本表(子表)主键) REFERENCES 外表(主表)名(外表主键)

基础函数

全转小写：lower
SELECT lower(ename) FROM emp;
全转大写：upper
SELECT upper(ename) FROM emp;
获取长度：length
一个字母、数字长度为1，一个汉字为3。跟底层编码表有关
SELECT dname,LENGTH(dname) FROM dept;

concat：拼接字符串
SELECT concat(dname,'hello') FROM dept;


substr：截取字符串
substr(1,2) 1:字段名	2:从那个字符开始
	SELECT substr(dname,3) FROM dept;---------从第三个字母后开始截取，直到结束
	substr(1,2,3) 1:字段名	2：从那个字符开始 3：截取长度
	SELECT substr(dname,3,2) FROM dept;-------从第三个字母后开始截取，截取两个字母

replace:替换字符
replace(1,2,3):替换字符 1：字段名  把2替换成3

SELECT dname,REPLACE(dname,'a','666') FROM dept;

ifnull：判断是否为空
ifnull(1,2)----判断1是否为null，为null，替换为2.不为null，不管

SELECT comm,IFNULL(comm,200) FROM emp;
	
round：四舍五入
SELECT comm,ROUND(comm)FROM emp;

ceil 向上取整
SELECT comm,CEIL(comm) FROM emp;

floor 向下取整
	SELECT comm,FLOOR(comm) FROM emp;
	
时间函数：
now()----------------获取当前时间(年月日时分秒)

year(now())--------获取当前时间的年份

month(now())------获取当前时间的月份

day(now())---------获取当前时间的日份

hour(now())--------获取当前时间的时份

minute(now())-----获取当前时间的分份

second(now())-----获取当前时间的秒份

条件查询


distinct:去重
SELECT distinct 字段名 FROM tablename;


where条件：
SELECT * FROM tablename WHERE 字段名1 = 条件1 and 字段名2 = 条件2;
SELECT * FROM tablename WHERE 字段名1 = 条件1 or 字段名2 = 条件2;
SELECT * FROM tablename WHERE 字段名 in (条件1,条件2)

模糊查询：like
SELECT * FROM tablename WHERE 字段名 LIKE '%o%';#低效
SELECT * FROM tablename WHERE 字段名 LIKE 'o%';#最高效
SELECT * FROM tablename WHERE 字段名 LIKE '%o';#高效
SELECT * FROM tablename WHERE 字段名 LIKE'l__';


null操作空数据
SELECT * FROM tablename WHERE 字段名 IS NULL;
SELECT * FROM tablename WHERE 字段名 IS not NULL;

区间范围:between...and...是包含的关系
SELECT * FROM tablename WHERE 字段名 BETWEEN 3000 AND 10000;#等效包含3000、10000


分页:limit
#查询表中前两条信息
	SELECT * FROM tablename limit 2;	
#从第二行,展示两条信息
	SELECT * FROM tablename LIMIT 1,2;  #从n+1行开始展示,要展示的行数


排序:order by
SELECT * FROM tablename ORDER BY  字段名;#默认升序
SELECT * FROM tablename ORDER BY 字段名 DESC;#降序

#查询的是数字---按照数字排序
#查询的是字母---按照字母的顺序
#查询的是生日---按照数值排序
#查询的是汉字---按照汉字对应在utf8编码表中数字进行排序

聚合函数


查最大值：max
SELECT MAX(字段名)  FROM tablename;

查最小值：min
SELECT MIN(字段名)  FROM tablename;

查平均值：avg
SELECT AVG(字段名) 平均工资 FROM tablename;

求和：sum
SELECT SUM(字段名) 求和 FROM tablename;

统计个数count
SELECT COUNT(1) FROM tablename;

分组： group by
查询时，出现了混合列(聚合列跟非聚合列)的现象是不行的，必须分组

#查询每个部门的最高薪---部门编号deptno---薪水sal	
SELECT deptno, MAX(sal) FROM emp GROUP BY deptno;
#		非聚合列,聚合列

having:完成分组后过滤
#查询每个部门的人数，人数>1的部门
SELECT deptno,COUNT(1) FROM emp GROUP BY deptno HAVING COUNT(1) >1;

事务


开始事务
start transaction

结束事务之提交事务
commit

结束事务之回滚事务
rollback

索引
查看索引
show index from 表名;

创建单值索引
create index indexname on 表名(字段名);

创建唯一索引
create unique index indexname on tablename(字段名);

创建复合索引
create index indexname on tablename(字段名1, 字段名2);

删除索引
alter table tablename drop index indexname; 

使用普通索引，唯一索引
explain	select * from tablename where 字段名 = 字段值;

使用复合索引
explain	select * from tablename where 字段名1 = 字段值  and 字段名2 = 字段值;

多表联查

select * from tablename1,tablename2 
				where tablename1.字段名 = tablename2.字段名	#表关系
                and tablename1.字段名2 = 字段值;				#业务关系

连接查询
内连接-----inner join: 取两个表的交集

SELECT * FROM tablename1 INNER JOIN tablename2 
						ON  tablename1.`deptno` = tablename2.`deptno`#表关系
						where tablename1.字段名2 = 字段值;#业务关系

外左连接-----left join :左表的所有和右表满足条件的，不满足是null
SELECT * FROM tablename1 left JOIN tablename2 
						ON  tablename1.`deptno` = tablename2.`deptno`#表关系
						where tablename1.字段名1 = 字段值;#业务关系

外右连接-----right join :右表的所有和左表满足条件的，不满足是null
SELECT * FROM tablename1 right JOIN tablename2 
						ON  tablename1.`deptno` = tablename2.`deptno`#表关系
						where tablename1.字段名2 = 字段值;#业务关系

子查询
SELECT * FROM tablename1 WHERE 字段名1 IN (SELECT 字段名1 FROM tablename2 WHERE 字段名2 = '字段值');

视图

创建视图
create view view_name as SQL查询语句
使用视图
select * from view_name;

数据库分页

在MySQL中，SELECT语句默认返回所有匹配的行，它们可能是指定表中的每个行。为了返回第一行或前几行，可使用LIMIT子句，以实现分页查询。LIMIT子句的语法如下：

-- 在所有的查询结果中，返回前5行记录。 
SELECT prod_name FROM products LIMIT 5;

-- 在所有的查询结果中，从第5行开始，返回5行记录。 
SELECT prod_name FROM products LIMIT 5,5;

总之，带一个值的LIMIT总是从第一行开始，给出的数为返回的行数。带两个值的LIMIT可以指定从行号为第一个值的位置开始。

在偏移量非常大的时候，例如 LIMIT 10000,20 这样的查询，这时MySQL需要查询10020条记录然后只返回最后20条，前面的10000条记录都将被抛弃，这样的代价是非常高的。如果所有的页面被访问的频率都相同，那么这样的查询平均需要访问半个表的数据。要优化这种查询，要么是在页面中限制分页的数量，要么是优化大偏移量的性能。

优化此类分页查询的一个最简单的办法就是尽可能地使用索引覆盖扫描，*而不是查询所有的列***，然后根据需要做一次关联操作再返回所需的列。对于偏移量很大的时候，这样做的效率会提升非常大。考虑下面的查询：

SELECT film_id,description FROM sakila.film ORDER BY title LIMIT 50,5;

如果这个表非常大，那么这个查询最好改写成下面的样子：

SELECT film.film_id,film.description  FROM sakila.film INNER JOIN (  SELECT film_id FROM sakila.film ORDER BY title LIMIT 50,5 ) AS lim USING(film_id);

这里的“延迟关联”将大大提升查询效率，它让MySQL扫描尽可能少的页面，获取需要访问的记录后再根据关联列回原表查询需要的所有列。这个技术也可以用于优化关联查询中的LIMIT子句。

有时候也可以将LIMIT查询转换为已知位置的查询，让MySQL通过范围扫描获得对应的结果。例如，如果在一个位置列上有索引，并且预先计算出了边界值，上面的查询就可以改写为：

SELECT film_id,description FROM skila.film WHERE position BETWEEN 50 AND 54 ORDER BY position;

对数据进行排名的问题也与此类似，但往往还会同时和GROUP BY混合使用，在这种情况下通常都需要预先计算并存储排名信息。

LIMIT和OFFSET的问题，其实是OFFSET的问题，它会导致MySQL扫描大量不需要的行然后再抛弃掉。如果可以使用书签记录上次取数的位置，那么下次就可以直接从该书签记录的位置开始扫描，这样就可以避免使用OFFSET。例如，若需要按照租赁记录做翻页，那么可以根据最新一条租赁记录向后追溯，这种做法可行是因为租赁记录的主键是单调增长的。首先使用下面的查询获得第一组结果：

SELECT * FROM sakila.rental ORDER BY rental_id DESC LIMIT 20;

假设上面的查询返回的是主键16049到16030的租赁记录，那么下一页查询就可以从16030这个点开始：

SELECT * FROM sakila.rental  WHERE rental_id < 16030 ORDER BY rental_id DESC LIMIT 20;

该技术的好处是无论翻页到多么后面，其性能都会很好。

介绍一下SQL中的聚合函数

参考答案

常用的聚合函数有COUNT()、AVG()、SUM()、MAX()、MIN()，下面以MySQL为例，说明这些函数的作用。

COUNT()函数：

COUNT()函数统计数据表中包含的记录行的总数，或者根据查询结果返回列中包含的数据行数，它有两种用法：

COUNT(*)计算表中总的行数，不管某列是否有数值或者为空值。
COUNT(字段名)计算指定列下总的行数，计算时将忽略空值的行。

COUNT()函数可以与GROUP BY一起使用来计算每个分组的总和。

AVG()函数()：

AVG()函数通过计算返回的行数和每一行数据的和，求得指定列数据的平均值。

AVG()函数可以与GROUP BY一起使用，来计算每个分组的平均值。

SUM()函数：

SUM()是一个求总和的函数，返回指定列值的总和。

SUM()可以与GROUP BY一起使用，来计算每个分组的总和。

MAX()函数：

MAX()返回指定列中的最大值。

MAX()也可以和GROUP BY关键字一起使用，求每个分组中的最大值。

MAX()函数不仅适用于查找数值类型，也可应用于字符类型。

MIN()函数：

MIN()返回查询列中的最小值。

MIN()也可以和GROUP BY关键字一起使用，求出每个分组中的最小值。

MIN()函数与MAX()函数类似，不仅适用于查找数值类型，也可应用于字符类型。

表跟表是怎么关联的？

参考答案

表与表之间常用的关联方式有两种：内连接、外连接，下面以MySQL为例来说明这两种连接方式。

内连接：

内连接通过INNER JOIN来实现，它将返回两张表中满足连接条件的数据，不满足条件的数据不会查询出来。

外连接：

外连接通过OUTER JOIN来实现，它会返回两张表中满足连接条件的数据，同时返回不满足连接条件的数据。外连接有两种形式：左外连接（LEFT OUTER JOIN）、右外连接（RIGHT OUTER JOIN）。

左外连接：可以简称为左连接（LEFT JOIN），它会返回左表中的所有记录和右表中满足连接条件的记录。
右外连接：可以简称为右连接（RIGHT JOIN），它会返回右表中的所有记录和左表中满足连接条件的记录。

SELECT <字段名> 
FROM <表a> 
JOIN <表b> 
ON a.<字段名> = b.<字段名> ;

SELECT *
FROM Students AS s
JOIN Teachers AS t
ON s.Tid = t.Tid

使用USING
SELECT film.film_id, film.description
FROM sakila.film
INNER JOIN (
    -- 子查询，获取前50部电影的 film_id
    SELECT film_id
    FROM sakila.film
    ORDER BY title
    LIMIT 50, 5
) AS lim
USING (film_id);

使用on
SELECT film.film_id, film.description
FROM sakila.film
INNER JOIN (
    -- 子查询，获取前50部电影的 film_id
    SELECT film_id
    FROM sakila.film
    ORDER BY title
    LIMIT 50, 5
) AS lim
ON film.film_id = lim.film_id;

除此之外，还有一种常见的连接方式：等值连接。这种连接是通过WHERE子句中的条件，将两张表连接在一起，它的实际效果等同于内连接。出于语义清晰的考虑，一般更建议使用内连接，而不是等值连接。

以上是从语法上来说明表与表之间关联的实现方式，而从表的关系上来说，比较常见的关联关系有：一对多关联、多对多关联、自关联。

一对多关联：这种关联形式最为常见，一般是两张表具有主从关系，并且以主表的主键关联从表的外键来实现这种关联关系。另外，以从表的角度来看，它们是具有多对一关系的，所以不再赘述多对一关联了。
多对多关联：这种关联关系比较复杂，如果两张表具有多对多的关系，那么它们之间需要有一张中间表来作为衔接，以实现这种关联关系。这个中间表要设计两列，分别存储那两张表的主键。因此，这两张表中的任何一方，都与中间表形成了一对多关系，从而在这个中间表上建立起了多对多关系。
自关联：自关联就是一张表自己与自己相关联，为了避免表名的冲突，需要在关联时通过别名将它们当做两张表来看待。一般在表中数据具有层级（树状）时，可以采用自关联一次性查询出多层级的数据。

SQL中怎么将行转成列？

在 SQL 中，将行转换为列的操作称为数据透视（Pivot）

1. 使用 CASE 表达式：

SELECT
    MAX(CASE WHEN category = 'A' THEN value END) AS value_A,
    MAX(CASE WHEN category = 'B' THEN value END) AS value_B,
    MAX(CASE WHEN category = 'C' THEN value END) AS value_C
FROM your_table;

在这个示例中，category 是一个列，value 是另一个列。我们使用 CASE 表达式将不同的 category 对应的 value 放在不同的列中，然后使用聚合函数（这里用的是 MAX）来获取每个列的值

2.使用 PIVOT：

某些数据库系统（如 SQL Server 和 Oracle）提供了 PIVOT 关键字，用于更方便地执行数据透视操作。示例如下：

SELECT *
FROM your_table
PIVOT (
    MAX(value) FOR category IN ('A', 'B', 'C')
) AS pivot_table;

这里，category 列的值 (‘A’, ‘B’, ‘C’) 将会成为新表的列名，对应的 value 列的值将填充到相应的列中。

首先，假设我们有一张分数表（tb_score），表中的数据如下图：

然后，我们再来看一下转换之后需要得到的结果，如下图：

使用 CASE…WHEN…THEN 语句实现行转列，参考如下代码：

SELECT userid, 
SUM(CASE `subject` WHEN '语文' THEN score ELSE 0 END) as '语文', 
SUM(CASE `subject` WHEN '数学' THEN score ELSE 0 END) as '数学', 
SUM(CASE `subject` WHEN '英语' THEN score ELSE 0 END) as '英语', 
SUM(CASE `subject` WHEN '政治' THEN score ELSE 0 END) as '政治'  
FROM tb_score  
GROUP BY userid

注意，SUM() 是为了能够使用GROUP BY根据userid进行分组，因为每一个userid对应的subject=”语文”的记录只有一条，所以SUM() 的值就等于对应那一条记录的score的值。假如userid =’001’ and subject=’语文’ 的记录有两条，则此时SUM() 的值将会是这两条记录的和，同理，使用Max()的值将会是这两条记录里面值最大的一个。但是正常情况下，一个user对应一个subject只有一个分数，因此可以使用SUM()、MAX()、MIN()、AVG()等聚合函数都可以达到行转列的效果。

使用 IF() 函数实现行转列，参考如下代码：

SELECT userid, SUM(IF(`subject`='语文',score,0)) as '语文', SUM(IF(`subject`='数学',score,0)) as '数学', SUM(IF(`subject`='英语',score,0)) as '英语', SUM(IF(`subject`='政治',score,0)) as '政治'  FROM tb_score  GROUP BY userid

注意，IF(subject=’语文’,score,0) 作为条件，即对所有subject=’语文’的记录的score字段进行SUM()、MAX()、MIN()、AVG()操作，如果score没有值则默认为0。

谈谈你对SQL注入的理解

SQL注入的原理是将SQL代码伪装到输入参数中，传递到服务器解析并执行的一种攻击手法。也就是说，在一些对SERVER端发起的请求参数中植入一些SQL代码，SERVER端在执行SQL操作时，会拼接对应参数，同时也将一些SQL注入攻击的“SQL”拼接起来，导致会执行一些预期之外的操作。

举个例子：

SELECT * FROM user WHERE username = 'ls' AND password = '123456'

SQL中会将#及–以后的字符串当做注释处理，如果我们使用 ‘ or 1=1 # 作为用户名参数，那么服务端构建的SQL语句就如下：

select * from user where username='' or 1=1 #' and password='123456'

而#会忽略后面的语句，而1=1属于常等型条件，因此这个SQL将查询出所有的登录用户。其实上面的SQL注入只是在参数层面做了些手脚，如果是引入了一些功能性的SQL那就更危险了，比如上面的登录功能，如果用户名使用这个 ‘ or 1=1;delete * from users; #，那么在”;”之后相当于是另外一条新的SQL，这个SQL是删除全表，是非常危险的操作，因此SQL注入这种还是需要特别注意的。

如何解决SQL注入

SQL预编译

sql = "SELECT * FROM users WHERE username = ? AND password = ?"
with sqlite3.connect("mydb.db") as connection:
    cursor = connection.cursor()
    cursor.execute(sql, (enteredUsername, enteredPassword))
    results = cursor.fetchall()

将查询与参数分开，确保输入的参数值不会被解释为 SQL 代码的一部分，不仅提升性能，而且防止SQL注入。

使用参数化查询：使用数据库驱动或框架提供的参数化查询机制，将用户输入作为参数传递给查询，而不是将其拼接到查询字符串中。
数据验证和过滤：对用户输入进行严格的验证和过滤，确保只接受预期的数据类型和格式。
转义字符：对输入进行适当的字符转义，以防止特殊字符被误解为 SQL 代码。
最小权限原则：在数据库配置中，为应用程序使用的数据库账户分配最小必要的权限，避免攻击者通过注入攻击访问不应该访问的数据。
定期更新和维护：保持数据库引擎和应用程序库的更新，以获取最新的安全性修复。
安全开发实践：开发人员需要了解并遵循安全的编程实践，以最大程度地减少安全漏洞。

将一张表的部分数据更新到另一张表，该如何操作呢？

参考答案

可以采用关联更新的方式，将一张表的部分数据，更新到另一张表内。参考如下代码：

UPDATE target_table AS t
JOIN source_table AS s ON t.id = s.id
SET t.name = s.name, t.age = s.age
WHERE t.id = 2;

UPDATE 语句来将 source_table 中 id 为 2 的行的数据更新到 target_table 中。我们使用 JOIN 子句来关联两个表，然后使用 SET 子句指定要更新的列和更新值。最后，使用 WHERE 子句来指定更新的条件


update b set b.col=a.col from a,b where a.id=b.id;
update b set col=a.col from b inner join a on a.id=b.id;
update b set b.col=a.col from b left Join a on b.id = a.id;

WHERE和HAVING有什么区别？

参考答案

WHERE是一个约束声明，使用WHERE约束来自数据库的数据，WHERE是在结果返回之前起作用的，WHERE中不能使用聚合函数。

HAVING是一个过滤声明，是在查询返回结果集以后对查询结果进行的过滤操作，在HAVING中可以使用聚合函数。另一方面，HAVING子句中不能使用除了分组字段和聚合函数之外的其他字段。

从性能的角度来说，HAVING子句中如果使用了分组字段作为过滤条件，应该替换成WHERE子句。因为WHERE可以在执行分组操作和计算聚合函数之前过滤掉不需要的数据，性能会更好。 HAVING 子句只能在 SELECT 查询中使用。

说一说你对MySQL索引的理解

索引是一个单独的、存储在磁盘上的数据库结构，包含着对数据表里所有记录的引用指针。使用索引可以快速找出在某个或多个列中有一特定值的行，所有MySQL列类型都可以被索引，对相关列使用索引是提高查询操作速度的最佳途径。

索引是在存储引擎中实现的，因此，每种存储引擎的索引都不一定完全相同，并且每种存储引擎也不一定支持所有索引类型。MySQL中索引的存储类型有两种，即BTREE和HASH，具体和表的存储引擎相关。MyISAM和InnoDB存储引擎只支持BTREE索引；MEMORY/HEAP存储引擎可以支持HASH和BTREE索引。

索引的优点主要有以下几条：

通过创建唯一索引，可以保证数据库表中每一行数据的唯一性。
可以大大加快数据的查询速度，这也是创建索引的主要原因。
在实现数据的参考完整性方面，可以加速表和表之间的连接。
在使用分组和排序子句进行数据查询时，也可以显著减少查询中分组和排序的时间。

增加索引也有许多不利的方面，主要表现在如下几个方面：

创建索引和维护索引要耗费时间，并且随着数据量的增加所耗费的时间也会增加。
索引需要占磁盘空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果有大量的索引，索引文件可能比数据文件更快达到最大文件尺寸。
当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度。

索引有哪几种？

参考答案

MySQL的索引可以分为以下几类：

普通索引和唯一索引

普通索引是MySQL中的基本索引类型，允许在定义索引的列中插入重复值和空值。

唯一索引要求索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。

主键索引是一种特殊的唯一索引，不允许有空值。
单列索引和组合索引

单列索引即一个索引只包含单个列，一个表可以有多个单列索引。

组合索引是指在表的多个字段组合上创建的索引，只有在查询条件中使用了这些字段的左边字段时，索引才会被使用。使用组合索引时遵循最左前缀集合。
全文索引

全文索引类型为FULLTEXT，在定义索引的列上支持值的全文查找，允许在这些索引列中插入重复值和空值。全文索引可以在CHAR、VARCHAR或者TEXT类型的列上创建。
空间索引

空间索引是对空间数据类型的字段建立的索引，MySQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING和POLYGON。MySQL使用SPATIAL关键字进行扩展，使得能够用创建正规索引类似的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MyISAM的表中创建。

按「数据结构」分类：B+tree索引、Hash索引、Full-text索引。
按「物理存储」分类：聚簇索引（主键索引）、二级索引（辅助索引）。
按「字段特性」分类：主键索引、唯一索引、普通索引、前缀索引。
按「字段个数」分类：单列索引、联合索引

按物理存储分类

从物理存储的角度来看，索引分为聚簇索引（主键索引）、二级索引（辅助索引）。

这两个区别在前面也提到了：

主键索引的 B+Tree 的叶子节点存放的是实际数据，所有完整的用户记录都存放在主键索引的 B+Tree 的叶子节点里；
二级索引的 B+Tree 的叶子节点存放的是主键值，而不是实际数据。

所以，在查询时使用了二级索引，如果查询的数据能在二级索引里查询的到，那么就不需要回表，这个过程就是覆盖索引。如果查询的数据不在二级索引里，就会先检索二级索引，找到对应的叶子节点，获取到主键值后，然后再检索主键索引，就能查询到数据了，这个过程就是回表。

按字段特性分类

从字段特性的角度来看，索引分为主键索引、唯一索引、普通索引、前缀索引。

主键索引

主键索引就是建立在主键字段上的索引，通常在创建表的时候一起创建，一张表最多只有一个主键索引，索引列的值不允许有空值。

唯一索引

唯一索引建立在 UNIQUE 字段上的索引，一张表可以有多个唯一索引，索引列的值必须唯一，但是允许有空值。

普通索引

普通索引就是建立在普通字段上的索引，既不要求字段为主键，也不要求字段为 UNIQUE。

前缀索引

前缀索引是指对字符类型字段的前几个字符建立的索引，而不是在整个字段上建立的索引，前缀索引可以建立在字段类型为 char、 varchar、binary、varbinary 的列上。

使用前缀索引的目的是为了减少索引占用的存储空间，提升查询效率。

按字段个数分类

从字段个数的角度来看，索引分为单列索引、联合索引（复合索引）。

建立在单列上的索引称为单列索引，比如主键索引；
建立在多列上的索引称为联合索引；

如何判断数据库的索引有没有生效？

可以使用EXPLAIN语句查看索引是否正在使用。

举例，假设已经创建了book表，并已经在其year_publication字段上建立了普通索引。执行如下语句：

EXPLAIN SELECT * FROM book WHERE year_publication=1990;

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

EXPLAIN语句将为我们输出详细的SQL执行信息，其中：

possible_keys行给出了MySQL在搜索数据记录时可选用的各个索引。
key行是MySQL实际选用的索引。

如果possible_keys行和key行都包含year_publication字段，则说明在查询时使用了该索引。

如何评估一个索引创建的是否合理？

建议按照如下的原则来设计索引：

避免对经常更新的表进行过多的索引，并且索引中的列要尽可能少。应该经常用于查询的字段创建索引，但要避免添加不必要的字段。
数据量小的表最好不要使用索引，由于数据较少，查询花费的时间可能比遍历索引的时间还要短，索引可能不会产生优化效果。
在条件表达式中经常用到的不同值较多的列上建立索引，在不同值很少的列上不要建立索引。比如在学生表的“性别”字段上只有“男”与“女”两个不同值，因此就无须建立索引，如果建立索引不但不会提高查询效率，反而会严重降低数据更新速度。
当唯一性是某种数据本身的特征时，指定唯一索引。使用唯一索引需能确保定义的列的数据完整性，以提高查询速度。
在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引，如果待排序的列有多个，可以在这些列上建立组合索引。
数据库事务：数据库中一组原子性的SQL操作，彼此状态一致。具有ACID特性。
事务 ACID 特性：
- 原子性：数据库事务是一个整体，其中的SQL操作要么全部提交成功commit要么全部失败回滚rollback，不可分割；
- 一致性：与原子性有联系。事务总是从一个一致状态转换到另一个一致状态；
- 隔离性：事务之间彼此互不影响，一个事务在提交之前，对其他事务是不可见的。
- 持久性：一个事务一旦提交成功，他所做的修改就会永久性的存储在数据库中。
MySQL 4 种隔离级别
- 未提交读READ UNCOMMITTED：一个事务在提交之前，对其他事务是可见的，即事务可以读取未提交的数据。存在“脏读”（读到了脏数据）问题；
- 提交读READ COMMITTED：事务在提交之前，对其它事务是不可见的。存在“不可重复读”（两次查询的得到的结果可能不同，即可能在查询的间隙，有事务提交了修改）问题。解决了“脏读”问题。
- 可重复读REPEATABLE READ：在同一事务中多次读取的数据是一致的。解决了脏读和不可重复读问题，存在“幻读”（在事务两次查询间隙，有其他事务又插入或删除了新的记录）。— MySQL默认隔离级别。
- 可串行化SERIALIZABLE：强制事务串行化执行。即一个事物一个事物挨个来执行，可以解决上述所有问题。
锁及粒度：
- 共享锁/读锁：互不阻塞，优先级低
- 排他锁/写锁：阻塞其他锁，优先级高，即确保在一个事务写入时不受其他事务的影响。
- 锁粒度：锁定的数据量越少（粒度越小），并发程度越高，但相应的加锁、检测锁、释放锁用的系统开销也随之增大。
- 锁策略：锁开销与数据安全性之间的平衡
  - 表锁：锁住整张表，读锁互不阻塞，写锁阻塞其他所有读写锁（同一张表）。开销最小。
  - 行级锁：对每一行数据（记录）加锁，开销大，并发程度高。
InnoDB对死锁的处理：此处死锁与OS死锁类似，多个事务互相持有对方所有要申请资源的锁不释放，造成环路死锁。MySQL InnoDB引擎检测到死锁循环依赖后，回滚持有最少行级锁的事务。
索引及其作用和实现方法：
- 概念：对数据库表列进行增加恰当索引，可以快速的找到匹配的记录行数，相比于默认的全表扫描，可以大大加快查找的速度。
- 作用：加快查找速度；
- 实现方法：一般分为B+树索引和哈希索引。
  - B+树索引：在B-tree上改进得到，其非叶子节点均为key值，叶子节点是key-data键值对。叶子节点前后相连且有序。
  - 哈希索引：通过对key进行hash(crc/MD5/sha1/sha256…)而将记录存储在不同的bucket种，可以做到常数时间的查找，但要注意哈希冲突的避免（链表法、线性探测、二次探测、公共溢出区的方法）。其中MD5 128位，和sha1/256码都较长不太适合作为hash函数。默认无序。
  - 为什么有了B+树索引还要hash索引？
    1. B+树默认有序，hash默认无序，所以哈希索引无法用于排序；
    2. 哈希索引O(1)在速度上毋庸置疑要快于B+树近似O(logn);
    3. 哈希索引只能进行等值查询（因为他要计算hash(key)再去匹配）而B+树索引可以进行等值、部分前缀、范围查询；
    4. 底层实现结构不同：B+树是非线性结构，hash桶是线性结构。
    5. 对于某些场景如热点页/活跃查询页，需要借助哈希索引来实现快速查询。
- 索引越多越快？
  此言差矣，索引并非是虚无缥缈的，是实实在在的一种数据结构（B+树/hash桶）要占内存、维护它要系统开销，一般的插入删除都要进行结构的调整，这要消耗时间，所以索引太多反而拖慢查找时间。有时候，见数据量不多时，建立索引还不如全表查询。索引加快了检索的速度，但是插入删除修改都需要DBMS动态更新内部索引结构，要耗费开销。
InnoDB MVCC
MVCC 的核心思想是在数据库中为每个事务创建一个独立的“版本”，这个版本包含了在该事务开始时数据库中的数据快照。每个事务都只能看到自己开始时的数据快照，而不受其他事务的影响。这种机制避免了读-写冲突以及脏读等并发问题。
多版本并发控制，是为了避免加锁而实现的。一般的实现方法是存储快照来实现的。InnoDB实现方式是在记录后添加两个隐藏列（表项），分别是事务创建时间、过期时间，存储的实际上是系统版本号（系统版本号随着事务的创建而递增）。
这样一来，INSERT 时加上开始版本号，UPDATE/DELETE时加上过期版本号，这样一来在SELETE时，就只访问开始系统版本号小于当前的事务的版本号、过期时间要么未定义要么在当前版本号之后的记录，这样就可以保证：访问的记录是在本事务开始前就存在而且在本事务期间没有过期（被删除或被修改过的）。可以避免脏读、不可重复读、幻读的问题。（个人觉得）
MySQL存储引擎简介

InnoDB,最为通用/推荐的一种引擎，支持事务、行级锁、甚至间隙锁（避免幻读）、支持热备份，MVCC，在并发上占优势，系统资源占用多。
MyISAM,默认的存储引擎，不支持事务和行级锁，只支持表锁，某些场景性能很好：占用存储上优，查询速度上完胜（大概是InnoDB的3倍）系统资源占用少。
InnoDB支持事务, MyISAM不支持；
InnoDB支持行级锁、表锁；MyISAM只支持表锁；
InnoDB支持MVCC，MyISAM不支持；
InnoDB不支持全文索引，MyISAM支持；
InnoDB支持外键，MyISAM不支持外键；
InnoDB和MyISAM都支持B+树索引，InnoDB还支持自适应哈希索引
MyISAM实现了前缀压缩技术，占用存储空间更小（但会影响查找），InnoDB是原始数据存储，占用存储更大。

PS：大部分情况下，InnoDB都是正确的选择。—《高性能MySQL》

SQL优化
- 在经常性的检索列上，建立必要索引，以加快搜索速率，避免全表扫描（索引覆盖扫描）；
- 多次查询同样的数据，可以考虑缓存该组数据；
- 审视select * form tables, 你需要所有列数据吗？
- 切分查询（大查询切分成为小查询，避免一次性锁住大量数据）
- 分解关联查询（单表查询，结果在应用程序中进行关联，可以减少处理过程中的锁争用）
- 尽量先做单表查询；
- …
profile 的作用和用法
用于保存SQL语句执行状态，需要手动开启，才可以查看。

set profiling = 1; 开启
show profiles; 显示SQL查询的profiles概况
show profile all for query X; 查看第X条语句的所有执行情况。
show profile cpu, block io, memory for query X; 查看部分profile信息。
MySQL查询的步骤
- 客户端发送查询到服务器；
- 服务器检查查询缓存query ***（大小写敏感的哈希查找，常数时间）。如果命中，返回缓存中的结果，否则下一步；
- 解析语句，生成执行计划；（SQL解析，预处理，优化器生成执行计划）；
- 根据执行计划，根据存储引擎的不同调用API，执行查询（一棵指令树）；
- 结果返回客户端。

为什么 MySQL InnoDB 选择 B+tree 作为索引的数据结构？

B+Tree vs B Tree

B+Tree 只在叶子节点存储数据，而 B 树的非叶子节点也要存储数据，所以 B+Tree 的单个节点的数据量更小，在相同的磁盘 I/O 次数下，就能查询更多的节点。

另外，B+Tree 叶子节点采用的是双链表连接，适合 MySQL 中常见的基于范围的顺序查找，而 B 树无法做到这一点。

2、B+Tree vs 二叉树

对于有 N 个叶子节点的 B+Tree，其搜索复杂度为O(logdN)，其中 d 表示节点允许的最大子节点个数为 d 个。

在实际的应用当中， d 值是大于100的，这样就保证了，即使数据达到千万级别时，B+Tree 的高度依然维持在 3~~4 层左右，也就是说一次数据查询操作**只需要做 3~~4 次的磁盘 I/O 操作就能查询到目标数据**。

而二叉树的每个父节点的儿子节点个数只能是 2 个，意味着其搜索复杂度为 O(logN)，这已经比 B+Tree 高出不少，因此二叉树检索到目标数据所经历的磁盘 I/O 次数要更多。

3、B+Tree vs Hash

Hash 在做等值查询的时候效率贼快，搜索复杂度为 O(1)。

但是 Hash 表不适合做范围查询，它更适合做等值的查询，这也是 B+Tree 索引要比 Hash 表索引有着更广泛的适用场景的原因

防止索引失效

用上了索引并不意味着查询的时候会使用到索引，所以我们心里要清楚有哪些情况会导致索引失效，从而避免写出索引失效的查询语句，否则这样的查询效率是很低的。

我之前写过索引失效的文章，想详细了解的可以去看这篇文章：谁还没碰过索引失效呢?(opens new window)

这里简单说一下，发生索引失效的情况：

当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx%这两种方式都会造成索引失效；
当我们在查询条件中对索引列做了计算、函数、类型转换操作，这些情况下都会造成索引失效；
联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效。
在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

这次主要介绍了索引的原理、分类和使用。我把重点总结在了下面这个表格

InnoDB 是如何存储数据的？

MySQL 支持多种存储引擎，不同的存储引擎，存储数据的方式也是不同的，我们最常使用的是 InnoDB 存储引擎，所以就跟大家图解下InnoDB 是如何存储数据的。

记录是按照行来存储的，但是数据库的读取并不以「行」为单位，否则一次读取（也就是一次 I/O 操作）只能处理一行数据，效率会非常低。

因此，InnoDB 的数据是按「数据页」为单位来读写的，也就是说，当需要读一条记录的时候，并不是将这个记录本身从磁盘读出来，而是以页为单位，将其整体读入内存。

数据库的 I/O 操作的最小单位是页，InnoDB 数据页的默认大小是 16KB，意味着数据库每次读写都是以 16KB 为单位的，一次最少从磁盘中读取 16K 的内容到内存中，一次最少把内存中的 16K 内容刷新到磁盘中。

数据页中的记录按照「主键」顺序组成单向链表，单向链表的特点就是插入、删除非常方便，但是检索效率不高，最差的情况下需要遍历链表上的所有节点才能完成检索。

因此，数据页中有一个页目录，起到记录的索引作用，就像我们书那样，针对书中内容的每个章节设立了一个目录，想看某个章节的时候，可以查看目录，快速找到对应的章节的页数，而数据页中的页目录就是为了能快速找到记录。

如果某个查询语句使用了二级索引，但是查询的数据不是主键值，这时在二级索引找到主键值后，需要去聚簇索引中获得数据行，这个过程就叫作「回表」，也就是说要查两个 B+ 树才能查到数据。不过，当查询的数据是主键值时，因为只在二级索引就能查询到，不用再去聚簇索引查，这个过程就叫作「索引覆盖」，也就是只需要查一个 B+ 树就能找到数据

总结

InnoDB 的数据是按「数据页」为单位来读写的，默认数据页大小为 16 KB。每个数据页之间通过双向链表的形式组织起来，物理上不连续，但是逻辑上连续。

数据页内包含用户记录，每个记录之间用单向链表的方式组织起来，为了加快在数据页内高效查询记录，设计了一个页目录，页目录存储各个槽（分组），且主键值是有序的，于是可以通过二分查找法的方式进行检索从而提高效率。

为了高效查询记录所在的数据页，InnoDB 采用 b+ 树作为索引，每个节点都是一个数据页。

如果叶子节点存储的是实际数据的就是聚簇索引，一个表只能有一个聚簇索引；如果叶子节点存储的不是实际数据，而是主键值则就是二级索引，一个表中可以有多个二级索引。

在使用二级索引进行查找数据时，如果查询的数据能在二级索引找到，那么就是「索引覆盖」操作，如果查询的数据不在二级索引里，就需要先在二级索引找到主键值，需要去聚簇索引中获得数据行，这个过程就叫作「回表」。

MySQL 的表数据是以页的形式存放的，页在磁盘中不一定是连续的。
页的空间是 16K, 并不是所有的空间都是用来存放数据的，会有一些固定的信息，如，页头，页尾，页码，校验码等等。
在 B+ 树中，叶子节点和非叶子节点的数据结构是一样的，区别在于，叶子节点存放的是实际的行数据，而非叶子节点存放的是主键和页号。
索引结构不会影响单表最大行数，2000W 也只是推荐值，超过了这个值可能会导致 B + 树层级更高，影响查询性能

索引失效有哪些

当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。

因为索引 B+ 树是按照「索引值」有序排列存储的，只能根据前缀进行比较。

有时候我们会用一些 MySQL 自带的函数来得到我们想要的结果，这时候要注意了，如果查询条件中对索引字段使用函数，就会导致索引失效。在查询条件中对索引进行表达式计算，也是无法走索引的。

如果索引字段是字符串类型，但是在条件查询中，输入的参数是整型的话，你会在执行计划的结果发现这条语句会走全表扫描。

这是因为 phone 字段为字符串，所以 MySQL 要会自动把字符串转为数字，所以这条语句相当于：

select * from t_user where CAST(phone AS signed int) = 1300000001;

可以看到，CAST 函数是作用在了 phone 字段，而 phone 字段是索引，也就是对索引使用了函数！而前面我们也说了，对索引使用函数是会导致索引失效的。

联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配

在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

这是因为 OR 的含义就是两个只要满足一个即可，因此只有一个条件列是索引列是没有意义的，只要有条件列不是索引列，就会进行全表扫描。

总结

今天给大家介绍了 6 种会发生索引失效的情况：

当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx%这两种方式都会造成索引失效；
当我们在查询条件中对索引列使用函数，就会导致索引失效。
当我们在查询条件中对索引列进行表达式计算，也是无法走索引的。
MySQL 在遇到字符串和数字比较的时候，会自动把字符串转为数字，然后再进行比较。如果字符串是索引列，而条件语句中的输入参数是数字的话，那么索引列会发生隐式类型转换，由于隐式类型转换是通过 CAST 函数实现的，等同于对索引列使用了函数，所以就会导致索引失效。
联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效。
在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

count(*) 和 count(1) 有什么区别？哪个性能最好？

统计符合查询条件的记录中，函数指定的参数不为 NULL 的记录有多少个。

**count(*) 其实等于 count(0)**，也就是说，当你使用 count(*) 时，MySQL 会将 * 参数转化为参数 0 来处理

count(1)、 count(*)、 count(主键字段)在执行的时候，如果表里存在二级索引，优化器就会选择二级索引进行扫描。

所以，如果要执行 count(1)、 count(*)、 count(主键字段) 时，尽量在数据表上建立二级索引，这样优化器会自动采用 key_len 最小的二级索引进行扫描，相比于扫描主键索引效率会高一些。

再来，就是不要使用 count(字段) 来统计记录个数，因为它的效率是最差的，会采用全表扫描的方式来统计。如果你非要统计表中该字段不为 NULL 的记录个数，建议给这个字段建立一个二级索引。

count(*)包括了所有的列，相当于行数，在统计结果的时候，不会忽略为NULL的值。
count(1)包括了忽略所有列，用1代表代码行，在统计结果的时候，不会忽略为NULL的值。
count(列名)只包括列名那一列，在统计结果的时候，会忽略列值为空（这里的空不是指空字符串或者0，而是表示null）的计数，即某个字段值为NULL时，不统计。

如何优化 count(*)？

近似值

我们就可以使用 show table status 或者 explain 命令来表进行估算。

额外表保存计数值

如果是想精确的获取表的记录总数，我们可以将这个计数值保存到单独的一张计数表中。

当我们在数据表插入一条记录的同时，将计数表中的计数字段 + 1。也就是说，在新增和删除操作时，我们需要额外维护这个计数表

执行一条 select 语句，期间发生了什么？

先来一个上帝视角图，下面就是 MySQL 执行一条 SQL 查询语句的流程，也从图中可以看到 MySQL 内部架构里的各个功能模块。

查询语句执行流程

可以看到， MySQL 的架构共分为两层：Server 层和存储引擎层，

Server 层负责建立连接、分析和执行 SQL。MySQL 大多数的核心功能模块都在这实现，主要包括连接器，查询缓存、解析器、预处理器、优化器、执行器等。另外，所有的内置函数（如日期、时间、数学和加密函数等）和所有跨存储引擎的功能（如存储过程、触发器、视图等。）都在 Server 层实现。
存储引擎层负责数据的存储和提取。支持 InnoDB、MyISAM、Memory 等多个存储引擎，不同的存储引擎共用一个 Server 层。现在最常用的存储引擎是 InnoDB，从 MySQL 5.5 版本开始， InnoDB 成为了 MySQL 的默认存储引擎。我们常说的索引数据结构，就是由存储引擎层实现的，不同的存储引擎支持的索引类型也不相同，比如 InnoDB 支持索引类型是 B+树，且是默认使用，也就是说在数据表中创建的主键索引和二级索引默认使用的是 B+ 树索引。

好了，现在我们对 Server 层和存储引擎层有了一个简单认识，接下来，就详细说一条 SQL 查询语句的执行流程，依次看看每一个功能模块的作用。

连接器

如果你在 Linux 操作系统里要使用 MySQL，那你第一步肯定是要先连接 MySQL 服务，然后才能执行 SQL 语句，连接的过程需要先经过 TCP 三次握手，因为 MySQL 是基于 TCP 协议进行传输的。

查询缓存

连接器得工作完成后，客户端就可以向 MySQL 服务发送 SQL 语句了，MySQL 服务收到 SQL 语句后，就会解析出 SQL 语句的第一个字段，看看是什么类型的语句。

如果 SQL 是查询语句（select 语句），MySQL 就会先去查询缓存（ Query Cache ）里查找缓存数据，看看之前有没有执行过这一条命令，这个查询缓存是以 key-value 形式保存在内存中的，key 为 SQL 查询语句，value 为 SQL 语句查询的结果。

对于更新比较频繁的表，查询缓存的命中率很低的，因为只要一个表有更新操作，那么这个表的查询缓存就会被清空。如果刚缓存了一个查询结果很大的数据，还没被使用的时候，刚好这个表有更新操作，查询缓冲就被清空了，相当于缓存了个寂寞。

所以，MySQL 8.0 版本直接将查询缓存删掉了，也就是说 MySQL 8.0 开始，执行一条 SQL 查询语句，不会再走到查询缓存这个阶段了。

对于 MySQL 8.0 之前的版本，如果想关闭查询缓存，我们可以通过将参数 query_cache_type 设置成 DEMAND。

解析 SQL

在正式执行 SQL 查询语句之前， MySQL 会先对 SQL 语句做解析，这个工作交由「解析器」来完成

执行 SQL

经过解析器后，接着就要进入执行 SQL 查询语句的流程了，每条SELECT 查询语句流程主要可以分为下面这三个阶段：

prepare 阶段，也就是预处理阶段；
optimize 阶段，也就是优化阶段；
execute 阶段，也就是执行阶段；

MySQL 一行记录是怎么存储的

db.opt，用来存储当前数据库的默认字符集和字符校验规则。
t_order.frm ，t_order 的表结构会保存在这个文件。在 MySQL 中建立一张表都会生成一个.frm 文件，该文件是用来保存每个表的元数据信息的，主要包含表结构定义。
t_order.ibd，t_order 的表数据会保存在这个文件。表数据既可以存在共享表空间文件（文件名：ibdata1）里，也可以存放在独占表空间文件（文件名：表名字.ibd）。这个行为是由参数 innodb_file_per_table 控制的，若设置了参数 innodb_file_per_table 为 1，则会将存储的数据、索引等信息单独存储在一个独占表空间，从 MySQL 5.6.6 版本开始，它的默认值就是 1 了，因此从这个版本之后， MySQL 中每一张表的数据都存放在一个独立的 .ibd 文件。

表空间由段（segment）、区（extent）、页（page）、行（row）组成，InnoDB存储引擎的逻辑存储结构大致如下图：

在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照区（extent）为单位分配。每个区的大小为 1MB，对于 16KB 的页来说，连续的 64 个页会被划为一个区，这样就使得链表中相邻的页的物理位置也相邻，就能使用顺序 I/O 了。

段（segment）

表空间是由各个段（segment）组成的，段是由多个区（extent）组成的。段一般分为数据段、索引段和回滚段等。

索引段：存放 B + 树的非叶子节点的区的集合；
数据段：存放 B + 树的叶子节点的区的集合；
回滚段：存放的是回滚数据的区的集合，之前讲事务隔离 (opens new window)的时候就介绍到了 MVCC 利用了回滚段实现了多版本查询数据。

「变长字段长度列表」中的信息之所以要逆序存放，是因为这样可以使得位置靠前的记录的真实数据和数据对应的字段长度信息可以同时在一个 CPU Cache Line 中，这样就可以提高 CPU Cache 的命中率

如果存在允许 NULL 值的列，则每个列对应一个二进制位（bit），二进制位按照列的顺序逆序排列。

二进制位的值为1时，代表该列的值为NULL。
二进制位的值为0时，代表该列的值不为NULL。

当数据表的字段都定义成 NOT NULL 的时候，这时候表里的行格式就不会有 NULL 值列表了。

所以在设计数据库表的时候，通常都是建议将字段设置为 NOT NULL，这样可以至少节省 1 字节的空间（NULL 值列表至少占用 1 字节空间）。

MySQL 的 NULL 值是怎么存放的？

MySQL 的 Compact 行格式中会用「NULL值列表」来标记值为 NULL 的列，NULL 值并不会存储在行格式中的真实数据部分。

NULL值列表会占用 1 字节空间，当表中所有字段都定义成 NOT NULL，行格式中就不会有 NULL值列表，这样可节省 1 字节的空间。

MySQL 怎么知道 varchar(n) 实际占用数据的大小？

MySQL 的 Compact 行格式中会用「变长字段长度列表」存储变长字段实际占用的数据大小。

如果变长字段允许存储的最大字节数小于等于 255 字节，就会用 1 字节表示「变长字段长度」；
条件二：如果变长字段允许存储的最大字节数大于 255 字节，就会用 2 字节表示「变长字段长度」；
我们这里字段类型是 varchar(65535) ，字符集是 ascii，所以代表着变长字段允许存储的最大字节数是 65535，符合条件二，所以会用 2 字节来表示「变长字段长度」

varchar(n) 中 n 最大取值为多少？

一行记录最大能存储 65535 字节的数据，但是这个是包含「变长字段字节数列表所占用的字节数」和「NULL值列表所占用的字节数」。所以，我们在算 varchar(n) 中 n 最大值时，需要减去这两个列表所占用的字节数。

如果一张表只有一个 varchar(n) 字段，且允许为 NULL，字符集为 ascii。varchar(n) 中 n 最大取值为 65532。

计算公式：65535 - 变长字段字节数列表所占用的字节数 - NULL值列表所占用的字节数 = 65535 - 2 - 1 = 65532。

如果有多个字段的话，要保证所有字段的长度 + 变长字段字节数列表所占用的字节数 + NULL值列表所占用的字节数 <= 65535。

在 UTF-8 字符集下，一个字符最多需要三个字节，varchar(n) 的 n 最大取值就是 65532/3 = 21844。

行溢出后，MySQL 是怎么处理的？

如果一个数据页存不了一条记录，InnoDB 存储引擎会自动将溢出的数据存放到「溢出页」中。

Compact 行格式针对行溢出的处理是这样的：当发生行溢出时，在记录的真实数据处只会保存该列的一部分数据，而把剩余的数据放在「溢出页」中，然后真实数据处用 20 字节存储指向溢出页的地址，从而可以找到剩余数据所在的页。

Compressed 和 Dynamic 这两种格式采用完全的行溢出方式，记录的真实数据处不会存储该列的一部分数据，只存储 20 个字节的指针来指向溢出页。而实际的数据都存储在溢出页中。

MySQL 有哪些锁

全局锁

在 MySQL 里，根据加锁的范围，可以分为全局锁、表级锁和行锁三类。

全局锁是怎么用的？

要使用全局锁，则要执行这条命令：

flush tables with read lock

执行后，整个数据库就处于只读状态了，这时其他线程执行以下操作，都会被阻塞：

对数据的增删改操作，比如 insert、delete、update等语句；
对表结构的更改操作，比如 alter table、drop table 等语句。

如果要释放全局锁，则要执行这条命令：

unlock tables

当然，当会话断开了，全局锁会被自动释放。

全局锁主要应用于做全库逻辑备份，这样在备份数据库期间，不会因为数据或表结构的更新，而出现备份文件的数据与预期的不一样。

表级锁

MySQL 表级锁有哪些？具体怎么用的。

MySQL 里面表级别的锁有这几种：

表锁；
元数据锁（MDL）;
意向锁；
AUTO-INC 锁

//表级别的共享锁，也就是读锁；
lock tables t_student read;

//表级别的独占锁，也就是写锁；
lock tables t_stuent write;

unlock tables

行级锁

InnoDB 引擎是支持行级锁的，而 MyISAM 引擎并不支持行级锁。

//对读取的记录加共享锁
select ... lock in share mode;

//对读取的记录加独占锁
select ... for update;

上面这两条语句必须在一个事务中，因为当事务提交了，锁就会被释放，所以在使用这两条语句的时候，要加上 begin、start transaction 或者 set autocommit = 0。

update 没加索引会锁全表？

当我们执行 update 语句时，实际上是会对记录加独占锁（X 锁）的，如果其他事务对持有独占锁的记录进行修改时是会被阻塞的。另外，这个锁并不是执行完 update 语句就会释放的，而是会等事务结束时才会释放。

在 InnoDB 事务中，对记录加锁带基本单位是 next-key 锁，但是会因为一些条件会退化成间隙锁，或者记录锁。加锁的位置准确的说，锁是加在索引上的而非行上。

比如，在 update 语句的 where 条件使用了唯一索引，那么 next-key 锁会退化成记录锁，也就是只会给一行记录加锁。

这里举个例子，这里有一张数据库表，其中 id 为主键索引。

假设有两个事务的执行顺序如下：

在这里插入图片描述

可以看到，事务 A 的 update 语句中 where 是等值查询，并且 id 是唯一索引，所以只会对 id = 1 这条记录加锁，因此，事务 B 的更新操作并不会阻塞。

但是，在 update 语句的 where 条件没有使用索引，就会全表扫描，于是就会对所有记录加上 next-key 锁（记录锁 + 间隙锁），相当于把整个表锁住了

假设有两个事务的执行顺序如下：

可以看到，这次事务 B 的 update 语句被阻塞了。

这是因为事务 A的 update 语句中 where 条件没有索引列，触发了全表扫描，在扫描过程中会对索引加锁，所以全表扫描的场景下，所有记录都会被加锁，也就是这条 update 语句产生了 4 个记录锁和 5 个间隙锁，相当于锁住了全表。

因此，当在数据量非常大的数据库表执行 update 语句时，如果没有使用索引，就会给全表的加上 next-key 锁，那么锁就会持续很长一段时间，直到事务结束，而这期间除了 select ... from语句，其他语句都会被锁住不能执行，业务会因此停滞，接下来等着你的，就是老板的挨骂。

那 update 语句的 where 带上索引就能避免全表记录加锁了吗？

并不是。

关键还得看这条语句在执行过程种，优化器最终选择的是索引扫描，还是全表扫描，如果走了全表扫描，就会对全表的记录加锁了。

TIP

网上很多资料说，update 没加锁索引会加表锁，这是不对的。

Innodb 源码里面在扫描记录的时候，都是针对索引项这个单位去加锁的， update 不带索引就是全表扫扫描，也就是表里的索引项都加锁，相当于锁了整张表，所以大家误以为加了表锁。

如何避免这种事故的发生？

我们可以将 MySQL 里的 sql_safe_updates 参数设置为 1，开启安全更新模式。

大致的意思是，当 sql_safe_updates 设置为 1 时。

update 语句必须满足如下条件之一才能执行成功：

使用 where，并且 where 条件中必须有索引列；
使用 limit；
同时使用 where 和 limit，此时 where 条件中可以没有索引列；

delete 语句必须满足以下条件能执行成功：

同时使用 where 和 limit，此时 where 条件中可以没有索引列；

如果 where 条件带上了索引列，但是优化器最终扫描选择的是全表，而不是索引的话，我们可以使用 force index([index_name]) 可以告诉优化器使用哪个索引，以此避免有几率锁全表带来的隐患。

当我们要执行 update 语句的时候，确保 where 条件中带上了索引列，并且在测试机确认该语句是否走的是索引扫描，防止因为扫描全表，而对表中的所有记录加上锁。

我们可以打开 MySQL sql_safe_updates 参数，这样可以预防 update 操作时 where 条件没有带上索引列。

如果发现即使在 where 条件中带上了列索引列，优化器走的还是全标扫描，这时我们就要使用 force index([index_name]) 可以告诉优化器使用哪个索引。

为什么要有 Buffer Pool？

虽然说 MySQL 的数据是存储在磁盘里的，但是也不能每次都从磁盘里面读取数据，这样性能是极差的。

要想提升查询性能，加个缓存就行了嘛。所以，当数据从磁盘中取出后，缓存内存中，下次查询同样的数据的时候，直接从内存中读取。

为此，Innodb 存储引擎设计了一个缓冲池（*Buffer Pool*），来提高数据库的读写性能

有了缓冲池后：

当读取数据时，如果数据存在于 Buffer Pool 中，客户端就会直接读取 Buffer Pool 中的数据，否则再去磁盘中读取。
当修改数据时，首先是修改 Buffer Pool 中数据所在的页，然后将其页设置为脏页，最后由后台线程将脏页写入到磁盘。

Buffer Pool 有多大？

Buffer Pool 是在 MySQL 启动的时候，向操作系统申请的一片连续的内存空间，默认配置下 Buffer Pool 只有 128MB 。

可以通过调整 innodb_buffer_pool_size 参数来设置 Buffer Pool 的大小，一般建议设置成可用物理内存的 60%~80%。

MySQL 日志：undo log、redo log、binlog 有什么用？

undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。
redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复；
binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制；

undo log 是一种用于撤销回退的日志。在事务没提交之前，MySQL 会先记录更新前的数据到 undo log 日志文件里面，当事务回滚时，可以利用 undo log 来进行回滚。如下图：

回滚事务

每当 InnoDB 引擎对一条记录进行操作（修改、删除、新增）时，要把回滚时需要的信息都记录到 undo log 里，比如：

在插入一条记录时，要把这条记录的主键值记下来，这样之后回滚时只需要把这个主键值对应的记录删掉就好了；
在删除一条记录时，要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了；
在更新一条记录时，要把被更新的列的旧值记下来，这样之后回滚时再把这些列更新为旧值就好了。

在发生回滚时，就读取 undo log 里的数据，然后做原先相反操作。比如当 delete 一条记录时，undo log 中会把记录中的内容都记下来，然后执行回滚操作的时候，就读取 undo log 里的数据，然后进行 insert 操作。

实现事务回滚，保障事务的原子性。事务处理过程中，如果出现了错误或者用户执行了 ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
实现 MVCC（多版本并发控制）关键因素之一。MVCC 是通过 ReadView + undo log 实现的。undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，会根据事务的 Read View 里的信息，顺着 undo log 的版本链找到满足其可见性的记录。

具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:

执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
- 如果 id=1 这一行所在的数据页本来就在 buffer pool 中，就直接返回给执行器更新；
- 如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。
执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
- 如果一样的话就不进行后续更新流程；
- 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；
开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
InnoDB 层开始更新记录，会先更新内存（同时标记为脏页），然后将记录写到 redo log 里面，这个时候更新就算完成了。为了减少磁盘I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
至此，一条记录更新完了。
在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。
事务提交（为了方便说明，这里不说组提交的过程，只说两阶段提交）：
- prepare 阶段：将 redo log 对应的事务状态设置为 prepare，然后将 redo log 刷新到硬盘；
- commit 阶段：将 binlog 刷新到磁盘，接着调用引擎的提交事务接口，将 redo log 状态设置为 commit（将事务设置为 commit 状态后，刷入到磁盘 redo log 文件）；
至此，一条更新语句执行完成。