mysql优化(一)

作者:有用网

一、表的优化

定长与变长分离,核心且常用字段,宜建成定长,放在一张表,而varchar,text,blob这种变长字段适合放在一张表,用主键关联

常用字段和不常用字段要分离

需要关联统计的字段上,添加冗余字段(反范式)有时候不遵循规则,反倒利于优化。

二、列的类型选择

列的类型选择原则:

字段优先级  整型 > date,time > enum,char > varchar > blob,text

整型:定长,没有国家/地区之分,没有字符集的差异

比如 tinyint 1,2,3,4,5  <----> char(1) a,b,c,d,e   从空间上都是1个字节, 但是order by 排序,前这快

原因后者需要考虑字符集的校对集(就是排序规则)

time: 定长 ,运算快,节省空间,考虑时区,写sql 时不方便 如where>'2005-12-22'

enum :能起到约束值得目的,内部使用整型来存储,但与char联查时,内部要经历串与值得转化

varchar: 不定长要考虑字符集的转化与排序时的校对集,速度慢

text/blob 无法使用内存临时表 (排序等操作只能在磁盘上进行)

附:关于date/time 的选择,大佬们的意思是直接选  int unsigned not null 存储时间戳

性别:

char(1),3个字长字节

enum('男','女');内部转成数字来存,多一个转化过程

tinyint(1),//0,1,2 定长1个字节

列的长度选择,原则上够用就行,不要慷慨

原因:大的字节浪费内存,影响速度,

以年龄为例 tinyint unsigned not null ,可以存储255岁,足够,用int浪费3个字节

以varchar(10),varchar(300)存储的内容相同,但是在表联查时,varchar(300)要花更多内存

尽量避免使用null

原因:null不利于索引,要用特殊的字节来标注,在磁盘上占据的空间其实更大, mysql 5.5已经对null做了优化改进,但是查询还是不便

enum 列的说明

enum列在内部是用整型来存储的

enum列与enum列相关联速度最快

enum列比(var)char的弱势---在碰到char关联时要转化,要花时间

优势在于,当char非常长时,enum依然是整型固定长度,查询的数据量越大时,enum的优势越明显

enum与char/varchar 关联因此需要转化,速度比enum和enum,char和char要慢,但是有时也这样用---就是在数据量特别大的时候可以节省IO


关键字
Mysql

阅读 1852 发布于 2021-03-18