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运算符
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范式化后的关系图为:
第四范式
消除表中的多值依赖
简单来说，第四范式就是要消除表中的多值依赖，也就是说可以减少维护数据一致性的工作。比如图4中的noNF表中的skill技能这个字段，有的人是“java，mysql”，有的人描述的是“Java，MySQL”，这样数据就不一致了，解决办法就是将多值属性放入一个新表，所以满足第四范式的关系图如下：
从上面对于数据库范式进行分解的过程中不难看出，应用的范式越高，表越多。表多会带来很多问题：
1、 查询时需要连接多个表，增加了**SQL查询的复杂度**
2 、查询时需要连接多个表，降低了数据库查询性能
因此，并不是应用的范式越高越好，视实际情况而定。第三范式已经很大程度上减少了数据冗余，并且基本预防了数据插入异常，更新异常，和删除异常了。
