「mysql优化专题」优化之路高级进阶——表的设计及优化(6)

前一篇详细讲解了索引优化(面试重点),相信大家都有收获,没看过的可以再看看。本篇则讲解表的设计及其优化,喜欢的朋友收藏关注。共同学习。

正文:表的设计及优化

优化①:创建规范化表,消除数据冗余

数据库范式是确保数据库结构合理,满足各种查询需要、避免数据库操作异常的数据库设计方式。满足范式要求的表,称为规范化表,范式产生于20世纪70年代初,一般表设计满足前三范式就可以,在这里简单介绍一下前三范式。

通俗的给大家解释一下(可能不是最科学、最准确的理解)

第一范式:属性(字段)的原子性约束,要求属性具有原子性,不可再分割;

第二范式:记录的惟一性约束,要求记录有惟一标识,每条记录需要有一个属性来做为实体的唯一标识。

第三范式:属性(字段)冗余性的约束,即任何字段不能由其他字段派生出来,在通俗点就是:主键没有直接关系的数据列必须消除(消除的办法就是再创建一个表来存放他们,当然外键除外)

当然,其实我们经常打破第三范式。。。且不可避免的,其实就是要在数据冗余和处理速度之间找到合适的平衡点 。

优化②:合适的字段属性

先举个例子:

以前我做过的电商项目中,关于资金流水类型的字段的选取。本来资金流水类型总共就那么十几种,基本固定死的,那我们就可以选择tinyint(4)就完全足够了,对应的是java的byte。 (要知道的是,tinyint的长度就是8位,tinyint(1)和tinyint(4)只是显示长度)

下面以下给出几个字段的建议:

0)数值型字段的比较比字符串的比较效率高得多,所以字段类型尽量使用最小、最简单的数据类型。如IP地址可以使用int类型,如我上面的例子。

1)建议不要使用DOUBLE,不仅仅只是存储长度的问题,同时还会存在精确性的问题。

2)对于整数的存储,在数据量较大的情况下,建议区分开 TINYINT / INT / BIGINT 的选择(当然,那已经是很老的事情了,现在其实不差这点性能)

3)char是固定长度,所以它的处理速度比varchar快得多,但缺点是浪费存储空间,不能在行尾保存空格。在MySQL中,MyISAM建议使用固定长度代替可变长度列;InnoDB建议使用varchar类型,因为在InnoDB中,内部行存储格式没有区分固定长度和可变长度。

4) 尽量不要允许NULL,除非必要,可以用NOT NULL+DEFAULT代替。

5)text与blob区别:blob保存二进制数据;text保存字符数据,有字符集。text和blob不能有默认值。

实际场景:text与blob主要区别是text用来保存字符数据(如文章,日记等),blob用来保存二进制数据(如照片等)。blob与text在执行了大量删除操作时候,有性能问题(产生大量的“空洞“),为提高性能建议定期optimize table 对这类表进行碎片整理。

6) 自增字段要慎用,不利于数据迁移

7)强烈反对在数据库中存放 LOB 类型数据,虽然数据库提供了这样的功能,但这不是他所擅长的,我们更应该让合适的工具做他擅长的事情,才能将其发挥到极致。(反正我么碰到过LOB类型数据)

8)尽量将表字段定义为NOT NULL约束,这时由于在MySQL中含有空值的列很难进行查询优化,NULL值会使索引以及索引的统计信息变得很复杂,可以使用0或者空字符串来代替。

9)尽量使用TIMESTAMP类型,因为其存储空间只需要 DATETIME 类型的一半,且日期类型中只有它能够和实际时区相对应。对于只需要精确到某一天的数据类型,建议使用DATE类型,因为他的存储空间只需要3个字节,比TIMESTAMP还少。(真的是技术文,欢迎补充)

优化③:索引

索引是一个表优化的重要指标,在表优化中占有极其重要的成分,所以上篇索引优化详解没看过的可以先看看,这里不再赘叙。

优化④:表的拆分(大表拆小表)

1、垂直拆分(其实就是列的拆分将原来的一个有很多列的表拆分成多张表)

注意:垂直拆分应该在数据表设计之初就执行的步骤,然后查询的时候用jion关键起来即可;

通常我们按以下原则进行垂直拆分:

把不常用的字段单独放在一张表;

把text,blob等大字段拆分出来放在附表中;

经常组合查询的列放在一张表中;

缺点也很明显,需要使用冗余字段,而且需要join操作。

2、水平拆分( 如果你发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键的某个值为界线,将该表的记录水平分割为两个表。)

当然,我们还可以用增量法。如流水这类不会改变的数据,我们用增量查询。

1.创建一张日充值表,记录每天充值总额

2.每天用定时器对当前充值记录进行结算

3.创建每月充值表,每月最后一天用定时器计算总额

4.则要查询总额,则从月报表中汇总,再从日报表查询当天之前的数据汇总,再加上今天的使用当天流水表记录今天的流水,三张表加起来,汇总。这样子效率是极好的!

优化⑤:传说中的‘三少原则’

①:数据库的表越少越好

②:表的字段越少越好

③:字段中的组合主键、组合索引越少越好

当然这里的少是相对的,是减少数据冗余的重要设计理念。

今天,表的设计及优化就讲到这里,重点是表的拆分(加分项)。觉得有收获的同学可以收藏关注。

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

推荐阅读更多精彩内容