【mysql基础知识】

mysql数据类型

MySQL数据类型定义了数据的大小范围，因此使用时选择合适的类型，不仅会降低表占用的磁盘空间，

间接减少了磁盘I/O的次数，提高了表的访问效率，而且索引的效率也和数据的类型息息相关。

数值类型

比如说定义年龄，咱们就不用INT类型了因为没有人的年龄那么大就设置TINYINT；

age INT(9) 整形占用内存党的大小是固定的，和具体的类型是强相关的。(M)只是代表整数显示的宽度

字符串类型

BLOB就是二进制；一般文本就用TEXT

char(M) 就是说是它这个字符的宽度，如果是hello那宽度也是12，但是超过12的字符串就会截取

日期和时间类型

日期类型也是做项目过程中，经常使用的类型信息，尤其是TIMESTAMP和DATETIME两个类型，但是注意TIMESTAMP会自动更新时间，非常适合那些需要记录最新更新时间的场景，而DATETIME需要手动更新。

注：一般不会使用数据库的这种时间，因为我们项目最先遇到性能瓶颈的就是mysql因为它设计磁盘的IO

enum和set

这两个类型，都是限制该字段只能取固定的值，但是枚举字段只能取一个唯一的值，而集合字段可以取任意个值。

比如就是我设置一个性别的时候只能选男女不可以选别的，来限制该字段。

MySQL运算符

就是正常的运算

逻辑运算符

 select * from user where sex = 'M'and score>=90.0;//找出是男的而且成绩大于90的

比较运算符

mySQL常用函数

字符串函数

 select * from user where age between 20 and 22;
 select * from user where score in(99.0,100);//找出99到100的学生
 select * from user where name like 'zhang%';//这个就是找到后面所有字符的 比如说zhang san  zhang yao
 select * from user where name like 'zhang_';//找到一个的  zhang x

mysql的完整性约束

主键约束

primary key//主键就是这个字段不能取空值，不能重复

主键和唯一键非空约束是不用写到一起的

自增键约束

auto_increment

//就比如说我加入id这个东西我不需要考虑去加到哪一列会自动按顺序生成

唯一键约束

unique

一个表只能有一个主键，但是可以有很多个唯一键

非空约束

not null

默认值约束

default

外键约束

foregin key

例子：

 学生信息表       父表
 张三 xxx xxx
 学生考试表
 张三id xxx xxx    子表

比如说我这个学生退学了那就是删除张三但是其它表都有它的信息那就应该提示或者有关联的比如说id就都删除

但一般来说我们用不上这些我们使用代码逻辑来控制

实例：

 CREATE TABLE user(
 id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT COMMENT'用户的主键id',
 nickname VARCHAR(50) UNIQUE NOT NULL COMMENT'用户的昵称',
 age TINYINT UNSIGNED NOT NULL DEFAULT 18,
 sex ENUM('m','f')
 );

关系型数据库表设计

一对一（碰到的少）

 用户user
 uid     name    age     sex
 1100    zhang   20      M
 1110    liu     21      W
 1111    wang    22      M
 
 身份信息info
 uid     cardid      addrinfo
 1100    112233      shanghai
 1110    112244      beijing

其实这就是一个外键uid

一对多

比如我现在做一个电商系统

用户User

商品Product

订单Order

用户和商品：没关系

用户和订单：一对多有关系

商品和订单：多对多关系

用户User表

uid name age sex

1000 zhang 20 M

1100 wang 21 W

2010 li 22 M

订单Oredr

ordeird uid pid number money totalprice addrinfo

O1111 1000 1 1 600 海淀区

O1111 1000 2 2 4000 海淀区

O1111 1000 3 4 40 海淀区

O2000 2010 2 1 2000 朝阳

商品Product pid pname price amount

1 手机 600 100

2 笔记本 2000 50

3 电池 10 200

多对多

增加一个中间表因为太冗余了可以看上面的如果修改的话就涉及很多的修改

关系型数据库范式(面试问)

应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：

1）减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）

2）消除异常（插入异常，更新异常，删除异常）

3）让数据组织的更加和谐

但是数据库范式绝对不是越高越好，范式越高，意味着表越多，多表联合查询的机率就越大，SQL的效

率就变低。

第一范式

每一列都保持原子特性

列都是基本数据项，不能够在进行分割，否则设计成一对多的实体关系。例如表中的地址字段，可以再细分为省，市，区，等不可·1再分割（既原子特性）的字段，如下：

上图的表就是把地址字段分成更详细的city，country，street三个字段，注意，不符合第一范式不能称作关系型数据库。

雇员ID,部门名称，名字，地址（addressID），工作，职位描述,技能，部门描述

第二范式

属于完全依赖于主键-主要针对联合主键

非主属性完全依赖于主关键字，如果不是完全依赖主键，应该拆分成新的实体，设计成一对多的实体关系。

例如：选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，（学号，课程名称）是联合主键，但是学分字段只和课程名称有关，和学号无关，相当于只依赖联合主键的其中一个字段，不符合第二范式。

第三范式

属性不依赖于其它非主属性

要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

示例：学生关系表为Student（学号，姓名，年龄，所在学院，学院地点，学院电话），学号是主键，但是学院电话只依赖于所在学院，并不依赖于主键学号，因此该设计不符合第三范式，应该把学院专门设计成一张表，学生表和学院表，两个是一对多的关系。

注意：一般关系型数据库满足第三范式就可以了。

BC范式

每个表中只有一个候选键

简单的说，BC范式是在第三范式的基础上的一种特殊情况，即每个表中只有一个候选键（在一个数据库**中每行的值都不相同，则可称为候选键）**，在上面第三范式的noNF表（上面图3）中可以看出，每一个员工的email都是唯一的（不可能两个人用同一个email），则此表不符合BC范式，对其进行BC范式化后的关系图为: