目录字段类型(数据类型)整形浮点型字符类型char()与varchar()研究数字在数字类型与类型中的区别char()与varchar()数字的差异char与varchar到底那个好呢
字段类型(数据类型)
整形
# 在mysql中不同类型的int能够存储的数字范围不一样
tinyint : 1bytes
smallint : 2bytes
int : 4bytes
bigint : 8bytes
# 验证不同类型的int是否会空出一位存储正负号：
create table t6(id tinyint);
insert into t6 values(256),(-129);
# 得出结论：tinyint默认会空出一位存储正负号
其实所有的int类型默认都会空出一位存储正负号
去除正负号
添加参数：unsigned
create table t7(id tinyint unsigned);
insert into t7 values(256),(-1);
浮点型
float(255,30) ： 总共255位，小数占30位。
double(255,30) ： 总共255位，小数站30位。
decimal(65,30) ： 总共65位，小数站30位。
# 验证三者有什么不一样之处
create table t8(id float(255,30));
create table t9(id double(255,30));
create table t10(id decimal(65,30));
insert into t8 values(1.22222222222222222222222222);
insert into t9 values(1.22222222222222222222222222);
insert into t10 values(1.22222222222222222222222222);
结论：三者精确度不同 decimal > double > float 具体使用要结合实际情况
字符类型char()与varchar()
char(4) : 定长
最多存储4个字符 超出了则报错 没超出则用空格填充
varchar(4) : 变长
最多存储4个字符 超出了则报错 没超出则有几个存储几个
验证：
create table t11(id int,name char(4));
create table t12(id int,name varchar(4));
insert into t11 values(1,'kelala')
insert into t12 values(1,'kelala')
上述我们发现：当数据超出时并没有报错而是失真了 如果出现这种情况就是在该配置文件的时候漏掉了一个严格模式的代码(SQL_MODE)
修改：SQL_MODE
1、模糊查询
show variables like '%mode%';
2、修改方式
set session sql_mode=strict_trans_tables # 只在当前操作页面有效
set global sql_mode=strict_trans_tables # 全局有效
也可以直接修改配置文件
sql_mode=strict_trans_tables
# 修改完需要退出客户端重新登录
exit
mysql
再次验证
研究数字在数字类型与类型中的区别
上述语法格式中有很多字符类型后加了一个数字(4)那么他到底是什么意思呢我们来验证一下；
1、验证数字在数字类型中是否是用来限制长度的
create table t14(id int(4));
insert into t14 values(1111111);
结论：数字在数字类型中并不是用来限制存储长度的，而是用来控制展示长度的
# 运用zerofill 0填充的方法来验证
create table t15(id int(8) unsigned zerofill); # unsigned 去除正负号
insert into t15 values(1111);
insert into t15 values(111111111);
结论：以后遇到数字类型不要制定数字，让他使用自带的即可
char()与varchar()数字的差异
char(4) : 定长
最多存储4个字符 超出了则报错 没超出则用空格填充
varchar(4) : 变长
最多存储4个字符 超出了则报错 没超出则有几个存储几个
1、验证char定长特性：
create table t16(id int,name char(5));
insert into t16 values(1,'tom');
create table t17(id int,name varchar(5));
insert into t17 values(1,'tom');
因为mysql底层有一个优化：在存储到硬盘中是确实是5个字符不够的以空格填充 但是在读取的时候自动优化去除了空格填充的部分。
验证：
方法：统计某个字段数据对应的长度
char_length()
用法： select char_length(name) from t16;
# 上述方法还是无法验证，需要取消底层优化操作
set global sql_mode='strict_trans_tables,pad_char_to_full_length'
exit
mysql # 重启客户端
可以看到varchar确实是存储几个就是几个
char与varchar到底那个好呢
各自的优缺点：
char
优势 ：整存整取 速度快
劣势 ：浪费存储空间
# char在存储时：固定了字符的长度不够的会空格填充。在取得时候固定取存时候的长度即可
varchar
优势 ： 节省存储空间
劣势 ： 存取数据都需要先考虑报头 速度相较于char慢
# varchar在存储时： 没有固定字符的长度。在每次取得时候会有一个报头，先取报头然后再取真实数据
eg： 1bytes+tom1bytes+jason1bytes+kevin
# 在使用varchar存储数据时，每个数据前面会有一个报头，报头存储的是后面数据的长度
结论：所以在存储数据长度差异不大得时候使用char，数据长度差异很大情况下使用varchar