存储引擎
· MySQL体系结构
> 连接层
最上层是一些客户端和链接服务，主要完成一些类似于连接处理、授权认证、及相关的安全 方案。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
> 服务层
第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析 和优化，部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如过程、函数等。
> 引擎层
存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API和存储引擎进行通信。 不同的存储引擎具有不同的功能，这样我们可以根据自己的需要，来选取合适的存储引擎。
> 存储层
主要是将数据存储在文件系统之上，并完成与存储引擎的交互。
· 存储引擎简介
存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的，而不是基于库的，所以存储引擎也可被称为表类型。
> 在创建表时，指定存储引擎
CREATE TABLE 表名(
字段1 字段1类型 [ COMMENT 字段1 注释],
......
字段n 字段n类型 [ COMMENT 字段n 注释],
)ENGINE = INNODB [ COMMENT 表注释];
> 查看当前数据库支持的存储引擎
SHOW ENGINES;
· 存储引擎特点
· InnoDB
> 介绍
InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，在MySQL5.5之后，InnoDB是 默认的MySQL存储引擎。
> 特点
DML操作遵从ACID模型，支持事务;
行级锁，提高并发访问性能;
支持外键FOREIGN KEY约束，保证数据的完整性和正确性;
> 文件
xxx.ibd: xxx代表的是表名，innoDB引擎的每张表都会对应这样一个表空间文件，存储 该表的表结构（frm、sdi）、数据和索引。参数：innodb_file_per_table
· MyISAM
> 介绍
MyISAM是MySQL早期的默认存储引擎。
> 特点
不支持事务，不支持外键
支持表锁，不支持行锁
访问速度快
> 文件
xxx.sdi: 存储表结构信息
xxx.MYD: 存储数据
xxx.MYI: 存储索引
· Memory
> 介绍
Memory引擎的表数据时存储在内存中，由于受到硬件问题、或断电问题的影响，只能 将这些表作为临时表或缓存使用。
> 特点
内存存放
hash索引(默认)
> 文件
xxx.sdi: 存储表结构信息
· 存储引擎选择
在选择存储引擎时，应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统，还可以根据实际情况选择多种存储引擎进行组合。
> InnoDB：是MySQL的默认存储引擎，支持事务、外键。如果应用对事务的完整性有比较 高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询之外，还包含很多 的更新、删除操作，那么InnDB存储引擎是比较合适的选择。
> MyISAM: 如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事物 的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。
> MEMORY: 将所有数据保存在内存中，访问速度快，通常用于临时表及缓存。MEMORY的 缺陷就是对表的大小有限制，太大的表无法缓存在内存中，而且无法保障数据的安全性。
索引
· 索引概述
> 介绍
索引(index)是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维 护着满足特定查找算法的数据结构，这些数据结构以某种方式引用(指向)数据，这样就可以 在这些数据结构上实现高级查找算法，这种数据结构就是索引。
> 优缺点 
· 索引结构
MySQL的索引是在存储引擎层实现的，不同的存储引擎有不同的结构，主要包含以下几种：
我们平常所说的索引，如果没有特别指明，都是指B+树结构组织的索引
> 二叉树
二叉树缺点：顺序插入时，会形成一个链表，查询性能大大降低。大数据量情况下，层级较深，检索速度慢。
红黑树：大数据量情况下，层级较深，检索速度慢。
> B-Tree(多路平衡查找树)
> B+Tree
> Hash 
· 特点：
1. Hash索引只能用于对等比较(=,in)，不支持范围查询(between,>,<,...)
2. 无法利用索引完成排序操作
3. 查询效率高，通常只需要一次检索就可以了，效率通常要高于B+Tree索引
· 存储引擎支持
在MySQL种，支持hash索引的是Memory引擎，而InnoDB中具有自适应hash功能，hash索引是存储引擎根据B+Tree索引在指定条件下自动构建的。
· 索引分类
在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：
> 聚集索引选取规则：
· 如果存在主键，主键索引就算聚集索引。
· 如果不存在主键，将使用第一个唯一(UNIQUE)索引作为聚集索引。
· 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏 的聚集索引。
· 索引语法
> 创建索引
CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name,...);
> 查看索引
SHOW INDEX FROM table_name;
> 删除索引
DROP INDEX index_name ON table_name;
· SQL性能分析
> SQL执行频率
MySQL客户端连接成功后，通过show [session | global] status 命令可以提供服务器状态 信息。通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访 问频次：
SHOW GLOBAL STATUS LIKE 'Com____';
> 慢查询日志
慢查询日志记录了所有执行时间超过指定参数(long_query_time,单位:秒，默认10秒)的所有 SQL语句的日志。MySQL的慢查询日志默认没有开启，需要在MySQL的配置文件 (/etc/my.cnf)中配置如下信息:
#开启MySQL慢日志查询开关
slow_query_log=1
#设置慢日志的时间为2秒，SQL语句执行时间超过2秒，就会视为慢查询，记录慢查询日志
long_query_time=2
配置完毕之后，通过以下指令重新启动MySQL服务器进行测试，查看慢日志文件中记录的信息/var/lib/mysql/localhost-slow.log。
> profile详情
show profiles能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。通用 have_profiling参数，能够看到当前MySQL是否支持profile操作：
SELECT @@have_profiling;
默认profiling是关闭的，可以通过set语句在session/global级别开启profiling：
SET profiling=1;
执行一系列的业务SQL的操作，然后通过如下指令查看指令的执行耗时：
#查看每一条SQL的耗时基本情况
show profiles;
#查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
#查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query query_id;
> explain执行计划
EXPLAIN或者DESC命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执 行过程中表如何连接和连接的顺序。
语法：
#直接在select语句之前加上关键字explain/desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件;
EXPLAIN执行计划各字段含义：
> id
select查询的序列号，表示查询中执行select子句或者是操作表的顺序(id相同，执行顺 序从上到下;id不同，值越大，越先执行)。
> select_type
表示SELECT的类型，常见的取值又SIMPLE（简单表，即不使用表连接或者子查 询）、 PRIMARY（主查询、即外层的查询）、UNION（UNION中的第二个或者后面 的查询语句）、SUBQUERY（SELECT/WHERE之后包含了子查询）等
> type
表示连接类型，性能由好到差的连接类型为NULL、system、const、eq_ref、 range、index、all。
> possible_key
显示可能应用在这张表上的索引，一个或多个。
> Key
实际使用的索引，如果为NULL，则没有使用索引。
>Key_len
表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损 失精确性的前提下，长度越短越好。
> rows
MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个估计值，可能并不 总是准确的。
> filtered
表示返回结果的行数占需读取行数的百分比，filtered的值越大越好。
· 索引使用
> 验证索引效率
在未建立索引之前，执行如下SQL语句，查看SQL的耗时。
SELECT *FROM tb_sku WHERE sn = '100000003145001';
针对字段创建索引
create index idx_sku_sn on tb_sku(sn);
然后再次执行相同的SQL语句，再次查看SQL的耗时
SELECT *FROM tb_sku WHERE sn = '100000003145001';
> 最左前缀法则
如果索引了多列(联合索引)，要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左 列开始，并且不跳过索引中的列。如果跳跃某一列，索引将部分失效(后面的字段索引失 效)。
> 范围查询
联合索引中，出现范围查询(>,<)，范围查询右侧的列索引失效
> 索引列运算
不要在索引列上进行运算操作，索引将失效
> 字符串不加引号
字符串类型字段使用时，不加引号，索引将失效
> 模糊查询
如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效
> or连接的条件
用or分割开的条件，如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索 引都不会被用到
> 数据分布影响
如果MySQL评估使用索引比全表更慢，则不使用索引
> SQL提示
SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提 示来达到优化操作的目的
use index
ignore index
force index
> 覆盖索引
尽量使用覆盖索引(查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到)， 减少select *。
> 前缀索引
当字段类型为字符串(varchar，text等)时，有时候需要索引很长的字符串，这会让索引变得 很大，查询时，浪费大量的磁盘IO，影响查询效率。此时可以只将字符串的一部分前缀，建 立索引，这样可以大大节约索引空间，从而提高索引效率。
· 语法
create index idx_xxxx on table_name(column(n));
· 前缀长度
可以根据索引的选择性来决定，而选择性是指不重复的索引值(基数)和数据表的记录总数的 比值，索引选择性越高则查询效率越高，唯一索引的选择性是1，这是最好的索引选择性，性 能也是最好的。 
> 单列索引和联合索引
单列索引：即一个索引只包含单个列
联合索引：即一个索引包含了多个列
在业务场景中，如果存在多个查询条件，考虑针对于查询字段建立索引时，建议建立联合索 引，而非单列索引。
> 索引设计原则
SQL优化
· insert优化
insert into tb_test values(1,'tom');
insert into tb_test values(2,'cat');
insert into tb_test values(3,'jerry');
....
> 批量插入
insert into tb_test values(1,'tom'),(2,'cat'),(3,'jerry');
> 手动提交事务
start transaction;
insert into tb_test values(1,'tom'),(2,'cat'),(3,'jerry');
insert into tb_test values(4,'tom'),(5,'cat'),(6,'jerry');
insert into tb_test values(7,'tom'),(8,'cat'),(9,'jerry');
commit;
> 主键顺序插入
主键乱序插入：8 1 9 21 88 2 4 15 89 5 7 3
主键顺序插入：1 2 3 4 5 7 8 9 15 21 88 89
· 大批量插入数据
如果一次性需要插入大批量数据，使用insert语句插入性能较低，此时可以使用MySQL数据库提供的load指令进行插入。操作如下：
#客户端连接服务器时，加上参数--local-infile
mysql--local-infile -u root -p
#设置全局参数local-infile为1，开启从本地加载文件导入数据的开关
set global local_inflie = 1;
#执行load指令将准备好的数据，加载到表结构中
load data local inflie '/root/sql1.log' into table `tb_user` fields terminated by ',' lines terminated by '\n';
主键顺序插入性能高于乱序插入
· 数据组织方式
在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表(index organized table IOT)
· 页分裂
页可以为空，也可以填充一半，也可以填充100%。每个页包含了2-N行数据(如果一行数据多大，会行溢出)，根据主键排列。
· 页合并
当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记(flaged)为删除并且它的空间变得允许被其他记录声明使用
当页中删除的记录达到MERGE_THRESHOLD(默认为页的50%)，InnoDB会开始寻找最靠近的页(前或后)看看是否可以将两个页合并以优化空间使用
· 主键设计原则
> 满足业务需求的情况下，尽量降低主键的长度
> 插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键
> 尽量不要使用UUID做主键或者是其他自然主键，如身份证号
> 业务操作时，避免对主键的修改
· order by优化
①. Using filesort: 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓存区sort buffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫FileSort排序
②. Using index: 通过有序索引顺序扫描直接返回有序数据，这种情况即为using index,不需要额外排序，操作效率高
#没有创建索引时，根据age，phone进行排序
explain select id,age,phone from tb_user order by age,phone;
#创建索引
create index idx_user_age_phone_aa on tb_user(age,phone);
#创建索引后，根据age，phone进行升序排序
explain select id,age,phone from tb_user order by age,phone;
#创建索引后，根据age，phone进行降序排序
explain select id,age,phone from tb_user order by age desc,phone desc;
#根据age，phone进行降序一个升序，一个降序
explain select id,age,phone from tb_user order by age asc,phone desc;
#创建索引
create index idx_user_age_phone_aa on tb_user(age asc,phone desc);
#根据age，phone进行降序一个升序，一个降序
explain select id,age,phone from tb_user order by age asc,phone desc;
> 根据排序字段建立合适的索引，多字段排序，也遵循最左前缀法则
> 尽量使用覆盖索引
> 多字段排序，一个升序一个降序，此时需要注意联合索引在创建时的规则(ASC/DESC)
> 如果不可避免的出现了filesort，大数据量排序时，可以适当增大排序缓冲区大小 sort_buffer_size(默认256k)
· group by优化
#删除目前的联合索引idx_user_pro_age_sta
drop index idx_user_pro_age_sta ob tb_user;
#执行分组操作，根据profession字段分组
explain select profession,count(*) from tb_user group by profession;
#创建索引
Create index idx_user_pro_age_sta on tb_user(profession,age,status);
#执行分组操作，根据profession字段分组
explain select profession,count(*) from tb_user group by profession;
#自行分组操作，根据profession字段分组
explain select profession,count(*) from tb_user group by profession,age;
> 在分组操作时，可以通过索引来提高效率
> 分组操作时，索引的使用也是满足最左前缀法则的
· limit优化
一个常见又非常头疼的问题就是limit 2000000,10，此时需要MySQL排序前2000010记录，仅仅返回2000000 - 2000010的记录，其他记录丢弃，查询排序的代价非常大
优化思路：一般分页查询时，通过创建覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化
· count优化
explain select count(*) from tb_user;
> MyISAM引擎把一个表的总行数存在了磁盘上，因此执行count(*)的时候会直接返回这个 数，效率很高
> InnoDB引擎就麻烦了，它执行count(*)的时候，需要把数据一行一行地从引擎里面读出 来，然后累计计数
优化思路：自己计数
· count的几种用法
> count()是一个聚合函数，对于返回的结果集，如果count函数的参数不是NULL，累 计值就加1，否则不加，最后返回累计值
> 用法：count(*)、count(主键)、count(字段)、count(1)
> count(主键)
InnDB引擎会遍历整张表，把每一行的主键id值都取出来，返回给服务层。服务层拿到 主键后，直接按行进行累加(主键不可能为null)
> count(字段)
没有not null约束：InnoDB引擎会遍历整张表把每一行的字段值都取出来，返回给服务 层，服务层判断是否为null，不为null，计数累加
有not null约束：InnDB引擎会遍历整张表把每一行的字段值都取出来，返回给服务 层，直接按行进行累加
> count(1)
InnoDB引擎遍历整张表，但不取值。服务层对于返回的每一行，放一个数字"1"进去， 直接按行进行累加
> count(*)
InnoDB引擎并不会把全部字段取出来，而是专门做了优化，不取值，服务层直接按行 进行累加
按照效率排序的话，count(字段) < count(主键id) < count(1) = count(*)，所以尽量使 用count(*)
· update优化
update student set no = '2000100100' where id = 1;
update student set no = '2000100105' where name = '韦一笑';
InnoDB的行锁是针对索引加的锁，不是针对记录加的锁，并且该索引不能失效，否则会从行锁升级为表锁
视图
· 介绍
视图(View)是一种虚拟存在的表。视图中的数据并不在数据库中实际存在，行和列数据来自定义视图的查询中使用的表，并且是在使用视图时动态生成的
通俗的讲，视图只保存了查询的SQL逻辑，不保存查询结果。所以我们在创建视图的时候，主要的工作就落在创建这条SQL查询语句上
· 创建
CREATE [ OR REPLACE] VIEW 视图名称[(列名列表)] AS SELECT语句 [ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
· 查询
查询创建视图语句：SHOW CREATE VIEW 视图名称;
查看视图数据：SELECT * FROM 视图名称.....;
· 修改
方式1：CREATE [OR REPLACE] VIEW 视图名称[(列名列表)] AS SELECT语句 [WITH [ CASCADED | LOCAL] CHECK OPTION]
方式2：ALTER VIEW 视图名称[(列名列表)] AS SELECT语句 [WITH [ CASCADED | LOCAL] CHECK OPTION]
· 删除
DROP VIEW [IF EXISTS] 视图名称 [视图名称]...
· 视图的检查选项
当使用WITH CHECK OPTION子句创建视图时，MySQL会通过试图检查正在更改的每个行，例如 插入，更新，删除，以及其符合视图的定义。MySQL允许基于另一个视图创建视图，它还会检查依赖视图中的规则以保持一致性。为了确定检查的范围，MySQL提供了两个选项：CASCADED 和 LOCAL ，默认值为CASCADED
· 视图的更新
要使视图可更新，视图中的行与基础表中的行之间必须存在一对一的关系。如果视图包含以下任何一项，则该视图不可更新：
1. 集合函数或窗口函数(SUM()、MIN()、MAX()、COUNT()等)
2. DISTINCT
3. GROUP BY
4. HAVING
5. UNION 或者 UNION ALL
· 作用
> 简单
视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以 被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件
> 安全
数据库可以授权，但不能授权到数据库特定行和特定的列上。通过视图用户只能查询和修改 他们所能见到的数据
存储过程
· 介绍
存储过程是事先经过编译并存储在数据库中的一段SQL语句的集合，调用存储过程可以简化应用开发人员的很多工作，减少数据在数据库和应用服务器之间的传输，对于提高数据处理的效率是有好处的
存储规程思想上很简单，就是数据库SQL语言层面的代码封装与重用
· 特点
封装，复用
可以接收参数，也可以返回数据，减少网络交互，效率提升
· 创建
CREATE PROCEDURE 存储过程名称([参数列表])
BEGIN
--SQL语句
END;
· 调用
CALL 名称([参数]);
· 查看
#查询指定数据库的存储过程及状态信息
SELECT *FROM INFORMATION_SCHEMA.ROUTINES WHERE
ROUTINE_SCHEMA='xxx';
#查询某个存储过程的定义
SHOW CREATE PROCEDURE 存储过程名称;
· 删除
DROP PROCEDURE [IF EXISTS] 存储过程名称;
注意：在命令行中，执行创建存储过程的SQL时，需要通过关键字delimited指定SQL语句的结束符
· 变量
系统变量是MySQL服务器提供，不是用户定于的，属于服务器层面。分为全局变量(GLOBAL)、会话变量(SESSION)。
> 查看系统变量
SHOW [ SESSION | GLOBAL] VARIABLES; --查看所有系统变量
SHOW [ SESSION | GLOBAL] VARIABLES LIKE '..' -可以通过LIKE模糊匹配方式查找变量
SELECT @@[ SESSION | GLOBAL] 系统变量名; --查看指定变量的值
> 设置系统变量
SET [ SESSION | GLOBAL] 系统变量名 = 值;
SET @@[ SESSION | GLOBAL] 系统变量名 = 值;
注意：
如果没有指定SESSION/GLOBAL，默认是SESSION，会话变量
mysql服务重新启动之后，所设置的全局参数会失效，要想不失效，可以在/etc/my.cnf中 配置
用户定义变量是用户根据需要自己定义的变量，用户变量不用提前声明，在用的时候直接用“@变量名”使用就可以了。其作用域为当前连接
> 赋值
SET @var_name = expr [,@var_name = expr]...;
SET @var_name := expr [,@var_name := expr]...;
SELECT @var_name := expr [,@var_name := expr]...;
SELECT 字段名 INTO @var_name FROM 表名;
> 使用
SELECT @var_name;
注意：
用户定义的变量无需对其进行声明或初始化，只不过获取到的值为NULL
局部变量是根据 需要定义的在局部生效的变量，访问之前，需要DECLARE声明。可用作存储过程内的局部变量和输入参数，局部变量的范围是在其内声明的BEGIN...END块
> 声明
DECLARE 变量名 变量类型 [DEFAULT ...];
变量类型就是数据库字段类型：INT、BIGINT、CHAR、VARCHAR、DATE、TIME等
>赋值
SET 变量名 = 值;
SET 变量名 := 值;
SELECT 字段名 INTO 变量名 FROM 表名...;
· if
IF 条件1 THEN
......
ELSEIF 条件2 THEN --可选
......
ELSE --可选
......
END IF;
· 参数
用法：
CREATE PROCEDURE 存储过程名称 ([IN/OUT/INOUT 参数名 参数类型])
BEGIN
--SQL语句
END;
· case
> 语法一
CASE case_value
WHEN when_value1 THEN statement_list1
[WHEN when_value2 THEN statement_list 2]...
[ELSE statement_list ]
END CASE;
> 语法二
CASE
WHEN search_condition1 THEN statement_list1
[WHEN search_condition2 THEN statement_list 2]...
[ELSE statement_list ]
END CASE;
· while
while循环是有条件的循环控制语句。满足条件后，再执行循环体中的SQL语句。具体语法为：
#先判定条件，如果条件为true，则执行逻辑，否则，不执行逻辑
WHILE 条件 DO
SQL逻辑...
END WHILE;
· repeat
repeat是有条件的循环控制语句，当满足条件的时候退出循环。具体语法为：
#先执行一次逻辑，然后判定逻辑是否满足，如果满足，则退出。如果不满足，则进行下一次循环
REPEAT
SQL逻辑...
UNTIL 条件
END REPEAT;
· loop
LOOP实现简单的循环，如果不在SQL逻辑中增加退出循环的条件，可以用其来实现简单的死循环。LOOP可以配合一下两个语句使用：
· LEAVE：配合循环使用，退出循环
· ITERATE：必须用在循环中，作用是跳过当前循环剩下的语句，直接进入下一次循环
[begin_label:] LOOP
SQL逻辑...
END LOOP [end_label];
LEAVE label; --退出指定标记的循环体
ITERATE label; --直接进入下一次循环
· 游标
游标(CURSOR)是用来存储查询结果集的数据类型，在存储过程和函数中可以使用游标对结果集进行循环的处理。游标的使用包括游标的声明、OPEN、FETCH和CLOSE，其语法分比如下：
> 声明游标
DECLARE 游标名称 CURSOR FOR 查询语句;
> 打开游标
OPEN 游标名称;
> 获取游标记录
FETCH 游标名称 INTO 变量 [,变量 ];
> 关闭游标
CLOSE 游标名称;
· 条件处理程序
条件处理程序(Handler)可以用来定义在流程控制结构执行过程中遇到问题时相应的处理步骤。具体语法为：
DECLARE handler_action HANDLER FOR condition_value [,condition_value]... statement;
handler_action
CONTINUE: 继续执行当前程序
EXIT: 终止执行当前程序
condition_value
SQLSTATE sqlstate_value: 状态码，如02000
SQLWARNING: 所有以01开头的SQLSTATE代码的简写
NOT FOUND: 所有以02开头的SQLSTATE代码的简写
SQLEXCEPTION: 所有没有被SQLWARNING或NOT FOUND 捕获的SQLSTATE 代码的简写
存储函数
存储函数是有返回值的存储过程，存储函数的参数只能是INT类型的。具体语法如下：
CREATE FUNCTION 存储函数名称([参数列表])
RETURNS type [characteristic...]
BEGIN
--SQL语句
RETURN...;
END;
characteristic说明：
· DETERMINSTIC: 相同的输入参数总是产生相同的结果
· NOT SQL: 不包含SQL语句
· READS SQL DATA: 包含读取数据的语句，但不包含写入数据的语句
触发器
· 介绍
触发器是与表有关的数据库对象，指在insert/update/delete之前或之后，触发并执行触发器中定义的SQL语句集合。触发器的这种特性可以协助应用在数据库端确保数据的完整性，日志记录，数据效验的操作
使用别名OLD和NEW来引用触发器中发生变化的记录内容，这与其他的数据库是相类似的。现在触发器还只支持行级触发，不支持语句级触发
· 语法
> 创建
CREATE TRIGGER trigger_name
BEFORE/AFTER INSERT/UPDATE/DELETE
ON tbl_name FOR EACH ROW --行级触发器
BEGIN
trigger_stmt;
END;
> 查看
SHOW TRIGGERS;
> 删除
#如果没有指定schema_name,默认为当前数据库
DROP TRIGGER [schema_name.]trigger_name;
锁
· 介绍
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源(CPU、RAM、I/O)的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
· 分类
MySQL中的锁，按照锁的粒度分，分为以下三类：
1. 全局锁：锁定数据库中的所有表
2. 表级锁：每次操作锁住整张表
3. 行级锁：每次操锁住对应的行数据
· 全局锁
> 介绍
全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语 句，DDL语句，已经更新操作的事务提交语句都将被阻塞
其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证 数据的完整性
· 演示
> 特点
数据库中加全局锁，是一个比较重的操作，存在以下问题：
1. 如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆
2. 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志(binlog)， 会导致主从延迟
在InnoDB引擎中，我们可以在备份时加上参数--single--transaction参数来完成不加锁的一致性数据备份
mysqldump --single-transaction -uroot -p123456 itcast > itcast.sql
· 表级锁
> 介绍
表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在 MyISAM、InnoDB、BDB等存储引擎中
对于表级锁，主要分为以下三类：
1. 表锁
2. 元数据锁(meta data lock, MDL)
3. 意向锁
> 表锁
对于表锁，分为两类：
1. 表共享读锁(read lock)
2. 表独占写锁(write lock)
语法：
1. 加锁：lock tables 表名... read/write
2. 释放锁： unlock tables /客户端断开连接
读锁不会阻塞其他客户端的读，但是会阻塞写，写锁既会阻塞其他客户端的读，又会阻塞其他客户端的写
> 元数据锁
MDL加锁过程是系统自动控制，无需显示使用，在访问一张表的时候会自动加上。MDL锁主 要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入 操作。为了避免DML与DDL冲突，保证读写的正确性
在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁(共享)；当对表 结构进行变更操作的时候，加MDL写锁(排他)
查看元数据锁：
select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks;
> 意向锁
为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不 用检查每行数据是否加锁，使用意向锁来减少表锁的检查
1. 意向共享锁(IS): 由语句select...lock in share mode添加，与表锁共享锁(read)兼容，与 表锁排它锁(write)互斥
2. 意向排他锁(IX): 由insert、update、delete、select...for update添加，与表锁共享锁 (read)及排它锁(write)都互斥。意向锁之间不会互斥
可以通过以下SQL，查看意向锁及行锁的加锁情况:
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks;
扫一扫
1095
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
