MySQL-约束与事务与索引

存储引擎

概念

存储引擎这个名字只有在mysql中存在。

Oracle中有对应的机制,但不叫做存储引擎,Oracle中称为"表的存储方式"

mysql支持很多存储引擎,每个存储引擎都对应了一种不同的存储方式

每一个存储引擎都有自己的优缺点,需要在合适的时机选择合适的存储引擎

查看当前mysql支持的存储引擎?

show engines \G

常见的存储引擎

  1. MyISAM
    • MyISAM这种存储引擎不支持事务
    • MyISAM是mysql最常用的存储引擎,但是这种存储引擎不是默认的。
    • MyISAM采用三个文件组织一个表:
      • xxx.frm(存储格式的文件)
      • xxx.MYD(存储表中数据的文件)
      • xxx.MYI(存储表中索引的文件)
    • 优点:可被压缩,节省存储空间。并且可以转换为只读表,提高检索效率。
    • 缺点:不支持事务
Engine: MyISAM
Support: YES
Comment: MyISAM storage engine
Transactions: NO
XA: NO
Savepoints: NO
  1. InnoDB

    • 表的结构存储在xxx.frm文件中
    • 数据存储在tablespace这样的表空间中(逻辑概念),无法被压缩,无法转换成只读。
    • 这种InnoDB存储引擎在MySQL数据库崩溃之后提供自动恢复机制。
    • InoDB支持级联删除和级联更新

    优点:支持事务、行级锁、外键等。这种存储引擎数据的安全得到保障

Engine: InnoDB
Support: DEFAULT
Comment: Supports transactions, row-level locking, and foreign keys
Transactions: YES
XA: YES
Savepoints: YES
  1. MEMORY

    • 以前叫做HEPA引擎

    缺点:

    • 不支持事务
    • 数据容易丢失(因为所有数据和索引都是存储在内存当中的)

    优点:查询速度最快,因为数据直接就在运存里面

Engine: MEMORY
Support: YES
Comment: Hash based, stored in memory, useful for temporary tables
Transactions: NO
XA: NO
Savepoints: NO


唯一性约束(unique)

唯一性约束修饰的字段具有唯一性,不能重复,但可以为null

案例一

给某一列添加unique


      drop table if exists t_user;
      create table t_user(
        id int,
    username varchar(255) unique  //列级约束
    );
    insert into t_user values(1,'zhangsan');        
    insert into t_user values(2,'zhangsan');  //出现编译错误,唯一性约束,该字段与上一行字段重复,但可以为null!
    ERROR 1062 (23000) : Duplicate entry 'zhangsan' for key 'username'

    insert into t_user(id) values(2);
        insert into t_user(id) values(3);
    insert into t_user(id) values(4);

案例二

给两个列或者多个列添加unique

drop table if exists t_user;
    create table t_user(
        id int,
        usercode varchar(255),
        username varchar(255),
        unique(usercode,username)  //多个字段联合起来添加一个约束unique 【表级约束】
      );
insert into t_user values(1,'111','zs');
insert into t_user values(2,'111','ls');
insert into t_user values(3,'222','zs');
select * from t_user;
insert into t_user values(4,'111','zs');  //出现编译错误!
ERROR 1062 (23000) : Duplicate entry '111-zs' for key 'usercode'

drop table if exists t_user;
create table t_suer(
    id int,
    usercode varchar(255) unique,
    username varchar(255) unique
  );
insert into t_user values(1,'111','zs');
insert into t_user values(2,'111','ls');
ERROR 1062 (23000) : Duplicate entry '111' for key 'usercode'
  • 注意:not null约束只有列级约束,没有表级约束。

主键约束(primary key)

主键相关术语

  主键约束 :`primary key`
  主键字段 : `id`字段添加`primary key`之后,id叫做主键字段
  主键值 :主键字段中的每一个值都是主键值

添加主键

如何给一张表添加主键约束呢?

drop table if exists t_user;
      create table t_user(
          id int primary key,  //列级约束
      username varchar(255),
      email varchar(255)
      );
      insert into t_user(id,username,email) values(1,'zs','zs@123.com');
      insert into t_user(id,username,email) values(2,'ls','ls@123.com');
      insert into t_user(id,username,email) values(3,'ww','ww@123.com');
      select * from t_user;
      +-----------------------------+
      | id | username | email       |
      +-----------------------------+
      |  1 | zs       | zs@123.com  |
      |  2 | ls       | ls@123.com  |
      |  3 | ww       | ww@123.com  |
      +----+----------+-------------+

注意:主键约束,不能为null也不能重复

insert into t_user(id,username,email) values(1,'jack','jack@123.com'); 
ERROR 1364 (HY000) : Field 'id' doesn't have a default value

主键作用

根据主键字段的字段数量来划分:

  • 单一主键 (推荐的,常用的)
  • 复合主键(多个字段联合起来添加一个主键约束)
  • 复合主键不建议使用,因为复合主键违背三范式

根据主键性质来划分:

  • 自然主键 :主键值最好就是一个和业务没有任何关系的自然数。(这种方式是推荐的)
  • 业务主键 : 主键值和系统的业务挂钩,例如:拿着银行卡的卡号做主键、拿着身份证号做为主键。(不推荐使用)

最好不要拿着和业务挂钩的字段做为主键

因为以后的业务一旦发生改变的时候,主键也可能需要随着发生变化,但有的时候没有办法变化,因为变化可能会导致主键重复。

注意:一张表的主键约束只能有1个

主键值自增

mysql提供主键值自增:auto_increment

drop table if exists t_user;
create table t_user(
    id int primary key auto_increment,  //id字段自动维护一个自增的数字,从1开始,以1递增。
    username varchar(255)
);

提示:Oracle当中也提供了一个自增机制,叫做:序列(sequence)对象

外键约束

相关术语

外键约束:foreign key
外键字段:添加有外键约束的字段
外键值:外键字段中的每一个值

使用外键约束的业务背景

外键,说简单点,就是在已有一张表的基础上,选择该表的一个字段的内容约束下一张表的某一字段的输入内容

外键可以为null

外键字段引用其他表的某个字段的时候,被引用的字段不一定是主键,但至少是具有unique约束,具有唯一性,不可重复!

事务(Transaction)

什么是事务?

一个事务就是一个不可再分,完整的业务逻辑单元

比如:银行账户,从A账户向B账户转账10000元,需要执行两条update语句。

update t_act set balance = balance - 10000 where actno = 'act-001';
update t_act set balance = balance + 10000 where actno = 'act-002';

以上两条DML语句必须同时成功,或者同时失败,不允许出现一条成功,一条失败。

想要保证以上的两条DML语句同时成功或者同时失败,那么就要使用数据库的"事务机制"

事务相关的语句

只有DML语句

  • insert
  • delete
  • update

为什么?因为他们这三个语句都是和数据库表当中的"数据"相关的,而事务的存在是为了保证数据的完整性,安全性。

事务的特性

事务包括四大特性:ACID

  • A:原子性:事务是最小的工作单元,不可再分。
  • B:一致性:事务必须保证多条DML语句同时成功或者同时失败。
  • C:隔离性:事务A与事务B之间具有隔离。
  • D:持久性:持久性说的是最终数据必须持久化到硬盘中,事务才算成功结束。

事务之间的隔离性

事务隔离性存在隔离级别,理论上隔离级别包括4个:

  • 第一级别:读未提交(read uncommitted)
    • 对方事务还没有提交,我们当前事务可以读取到对方未提交的数据。
    • 读未提交存在脏读(Dirty Read) 现象:表示读到了脏数据。
  • 第二级别:读已提交(read committed)
    • 对方事务提交之后的数据我方可以读取到。
    • 读已提交存在的问题是:不可重复读。
  • 第三级别:可重复读(repeatable read)
  • 这种隔离级别解决了:不可重复读问题。
  • 这种隔离级别存在的问题是:读取到的数据是幻象。
  • 第四级别:序列化读/串行化读(serialized)
    • 解决了以上所有问题。
    • 但效率低,因为需要事务排队。

开启事务

  1. MySQL事务默认情况下是自动提交的

  2. 只要执行任意一条DML语句则提交一次

开启事务采用如下语句:

start transaction;

回滚事务

rollback;   

提交事务

commit


索引

索引的概念与作用

索引就相当于一本书的目录,通过目录可以快速的找到对应的资源。

在数据库方面,查询一张表的时候有两种检索方式:

  • 第一种方式:全表扫描
  • 第二种方式:根据索引检索(效率很高)

索引为什么可以提高检索效率呢?
其实最根本的原理是缩小了扫描的范围

索引虽然可以提高检索效率,但是不能随意的添加索引,因为索引也是数据库当中的对象,也需要数据库不断的维护。是有维护成本的。

比如:表中的数据经常被修改,这样就不适合添加索引,因为数据一旦修改,索引需要重新排序,进行维护。

添加索引是给某一个字段,或者说某些字段添加索引。

select ename,sal from emp where ename = 'SMITH';
当ename字段没有添加索引的时候,以上sql语句会进行全表扫描,扫描ename字段中所有的值。
当ename字段添加索引的时候,以上sql语句会根据索引扫描,快速定位。

创建与删除索引

创建索引对象:

create index 索引名称 on 表名(字段名);

删除索引对象:

drop index 索引名称 on 表名;

什么时候需要索引?

  1. 数据量庞大。(根据客户的需求,根据线上的环境)
  2. 该字段很少的DML操作。(因为字段进行修改操作,索引也需要维护)
  3. 该字段经常出现在where子句中。(经常根据哪个字段维护)

索引底层实现原理

通过B Tree缩小扫描范围,底层索引进行了排序,分区,索引会携带数据在表中的"物理地址",最终通过索引检索到数据之后,获取到关联的物理地址。

而通过物理索引检索到数据之后,获取到关联的物理地址,通过物理地址定位表中的数据,效率是最高的。

索引分类

  • 单一索引:给单个字段添加索引
  • 复合索引:给多个字段联合起来添加一个索引
  • 主键索引:主键上会自动添加索引
  • 唯一索引:有unique约束的字段会自动添加索引

索引失效

模糊查询的时候,第一个通配符使用的是%,这个时候索引是是失效的。

select ename from emp where ename like ' %A% ';


数据库设计三范式

  1. 第一范式:任何一张表都应该有主键,并且每一个字段原子性不可再分。
  2. 第二范式:建立在第一范式的基础上,所有非主键字段完全依赖主键,不能产生部份依赖。
  3. 第三范式:建立在第二范式的基础上,所有非主键字段直接依赖主键,不能产生传递依赖。

数据库设计小技巧

多对多?三张表,关系表两个外键


        t_student学生表
        sno(pk)       sname
        ---------------------
         1             张三
         2             李四 
         3             王五

         t_teacher 讲师表
         tno(pk)            tname
         ----------------------
          1         王老师
          2         张老师
          3         李老师

          t_student_teacher_relation 学生讲师关系表
          id(pk)        sno(fk)          tno(fk)
          -------------------------------------------
           1          1                 3
           2          1         1
           3          2         2
           4          2         3
           5          3         1
           6          3         3

一对多?两张表,多的表加外键。

        班级t_class
        cno(pk)          cname
        --------------------------
          1              班级1
          2              班级2

        学生t_student
        sno(pk)         sname         classno(fk)
        --------------------------------------------
         101         张1       1
         102         张2       2
         103         张3       2
         104         张4       1
         105         张5       2

一对一怎么设计?

  1. 主键共享

    _user_login 用户登陆表
        id(pk)       username        password
        ----------------------------------------
         1             zs                123
         2             ls                456
         
         t_user_detail 用户详细信息表
          id(pk+fk)         realname          tel          ...
         ----------------------------------------------------
            1              张三            11111111112234
     2          李四            12112523432412
    
  2. 外键唯一

    t_user_login 用户登陆表
        id(pk)       username        password
        ----------------------------------------
         1             zs                123
         2             ls                456
         
         t_user_detail 用户详细信息表
          id(pk)         realname          tel            userid(fk+unique)      
         ----------------------------------------------------
           1                张三         111111114          2
           2         李四         121432412          1
    
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,839评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,543评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,116评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,371评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,384评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,111评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,416评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,053评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,558评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,007评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,117评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,756评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,324评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,315评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,539评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,578评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,877评论 2 345

推荐阅读更多精彩内容