存储大规模数据集需要仔细设计数据库模式和索引,以便能够高效地支持各种查询操作。 数据库设计表结构设计垂直分割:将大的表分割成多个相关性较小的表,以减少单个表的字段数量。这有助于提高查询效率和降低冗余。规范化:合理使用规范化,将重复数据抽取成独立的表,以减小数据冗余。 索引设计主键索引:对主键字段创建索引,以提高检索速度。 分库分表如果数据量仍然巨大,可以考虑分库分表策略,将数据划分到不同的数据库或表中。4. 数据分区根据时间、范围等条件对数据进行分区,以提高查询效率。5. 在设计时,充分了解数据的访问模式,根据查询的特点合理设计索引,通过适当的规范化和分区来优化存储结构,最终达到高效的查询和存储效果。我正在参与2023腾讯技术创作特训营第三期有奖征文,组队打卡瓜分大奖!
规范总结 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用 MySQL 保留关键字【设计表后逐一排查】 所有表必须使用 Innodb 存储引擎,数据库和表的字符集统一使用 ://dev.mysql.com/doc/mysqld-version-reference/en/keywords-8-0.html 建议在设计数据表之后逐一排查有没有使用关键字。 数据库基本设计规范 1. 方法: a.将字符串转换成数字类型存储,如:将 IP 地址转换成整形数据 MySQL 提供了两个方法来处理 ip 地址 inet_aton 把 ip 转为无符号整型 (4-8 位) inet_ntoa 【MySQL 内存临时表不支持 TEXT、BLOB 这样的大数据类型,如果查询中包含这样的数据,在排序等操作时,就不能使用内存临时表,必须使用磁盘临时表进行。
表设计是每一个后端程序员都无法避开的一块转,而且这块砖一不小心就很容易烫手,本篇笔记就是喂了帮助大家在设计表是能够轻松拿捏1.命名规范数据库表名、字段名、索引名等都需要命名规范。 4.选择合适的字段长度首选问大家一个问题,数据库字段长度表示字符长度还是字节长度?在mysql中,varchar和char类型表示字符长度,而其他类型表示的长度都表示字节长度。 char(10)表示字符长度是10.bigint(4)表示显示长度是4个字节,但是因为bigint实际长度是8个字节,所以bigint(4)的实际长度就是8个字节。 11.避免使用MySQL保留字如果库名、表名、字段名等属性含有保留字时,SQL语句必须用反引号来引用属性名称,这将使得SQL语句书写、SHELL脚本中变量的转义等变得非常复杂。 对于MySQL来说,主要有date、datetime、time、timestamp和year。
二.设计表格 公司表 公司名称 公司编号(自增主键) 电话号码 A 1001 xx B 1002 xx 广告表 广告编号 有该广告的公司的编号(自增主键) 广告收费/点击一次 1 1001 2 2 1001 3 3 1002 2 点击表 广告编号 该广告发送给浏览者的日期 1 101101 2 101102 1 101323 3 111232 三.查询 查都有哪些公司 直接查询公司表的 公司名称 字段 select 公司名称 from 公司表; 结果为A,B公司投放了广告 查A公司都放了哪些广告 先到公司表,将公司名称=A的编号提取出来,然后将公司编号作为条件去广告表里找广告编号。 between 100000 and 199999; 最后做个计算即可 四.分析 表结构设置 目前有3张表,基本满足业务需求,但未来查询更多,需要重新设计主键位置,表结构。 当数据庞大,首当其冲的是点击表,可能一天有几万次记录写入,这张表将变得庞大,可以考虑将表根据月份进行拆分。
标志等具有低范围值的数据smallint2 字节有符号整数,取值范围为 -32,768 到 32,767 或者 0 到 65,535(无符号)储存较小的整数值,如年份、订单数量等 int 4 字节有符号整数,取值范围为 -2,147,483,648 到 2,147,483,647 或者 0 到 4,294,967,295(无符号)储存常规整数值,如用户 ID、年龄、金额等 bigint 尽可能使用 not null定义字段将字段设置成空字符串或者常量值not null防止出现空指针的问题null值存储也需要额外的空间,导致比较运算更为复杂,是优化器难以优化sqlnull值可能会导致索引失效设计索引有查询条件的字段 ,一般要加索引单表的索引不超过5个区分度不高的字段,不添加索引(性别)避免索引失效的情况(mysql的内置函数)索引过多,选用联合索引优化不使用外键关联使用外键存在性能问题、并发死锁问题、使用起来不方便等 mysql对于存储过程、触发器等还不是很成熟,没有完善的出错记录处理,不建议使用sql编写的优化经验查询尽量不要使用select *查询的结果只要一条或者只要最大/小的一条记录,建议使用limit 1避免
在设计好表结构之后, 就需要进行物理设计, 将实体及属性映射到具体表和列. 而合理选择存储引擎和列类型也是数据库设计十分重要的一个环节. 物理设计包括, 命名规范, 存储引擎, 列字段选择, 主键设计以及主键生成算法. 一. 命名规范 首先在定义数据库,表,字段时一定要公司的命名规范; 二. 2^8-1 smallint 2 bytes -2^15, 2^15-1 0, 2^16-1 mediumint 3 bytes -2^23, 2^23-1 0,2^24-1 intinteger 4 否 double 8字节 否 decimal 每4字节存9个数字,小数点占1个字节 是 3.3 字符串类型 MySQL中字符串类型主要有两种varchar 和 char, 如果是非常大的文本可以酌情选择 主键选择 应选择尽可能小且顺序增长的数字类型, 并且表主键可以与业务主键不同.
---- 设计符合 2NF 的表 以订单信息表为例,讲述如何设计一个符合 2NF 的表 首先,我们看原始的订单信息表,如下图所示 ? 使用原则和设计规范 聊完范式,接下来我们看看 MySQL 使用中的一些使用原则和设计规范。 默认字符集 UTF8mb4,以前版本的 UTF8 是 UTF8mb3,未包含个别特殊字符,新版本的 UTF8mb4 包含所有字符,官方强烈建议使用此字符集。 关闭区分大小写功能。 这些字段类型,在 MySQL 数据库的检索性能不高,很难使用索引进行优化。如果必须使用这些功能,一般采取特殊的结构设计,或者与程序结合使用其他的字段类型替代。 不同系统之间,统一规范; 不同表之间的相同字段或者关联字段,字段类型/命名要保持一致;库表字符集和前端程序、中间件必须保持一致的 UTF8mb4。
前言: 在我们项目开发中,数据库及表的设计可以说是非常重要,我遇到过很多库表设计比较杂乱的项目,像表名、字段名命名混乱、字段类型设计混乱等等,此类数据库后续极难维护与拓展。 我一直相信只有优秀的库表设计才能发挥出MySQL最大的性能,前面有篇文章也分享了数据库的使用规范,本篇文章主要讲几个库表设计的小技巧,希望对大家有所启发。 timestamp翻译为汉语即"时间戳",它是当前时间到 Unix元年(1970 年 1 月 1 日 0 时 0 分 0 秒)的秒数,占用4个字节,而且是以UTC的格式储存,它会自动检索当前时区并进行转换 192.168.0.2')); # 相互转换 select INET_ATON('192.168.0.1'); select INET_NTOA(3232235521); 总结: 本篇文章分享了几个库表设计及字段类型选取的建议 其实库表设计是件复杂的事情,需要在项目前期多方人员共同规划讨论。还是那句话,只有优秀的库表设计才能发挥出MySQL最大的性能。 — END —
在MySQL数据库中,表设计的优劣同样对性能有非常重要的影响。本节将介绍表设计的优化方法,包括巧用多表关系、表结构设计优化和表拆分等。 表结构设计优化 在进行表结构设计时,选择合适的数据类型,慎用NULL值,适度冗余,适当进行表拆分等方法对提高性能是至关重要的。表结构设计优化采取的措施通常包括以下几个方面。 NULL值不利于索引,MySQL难以优化可为NULL的列查询。当可为NULL的列被索引时,每个索引记录需要一个额外的字节用于标识其是否可空。如果某列计划要创建索引,要尽量避免将其设计成可为NULL。 另外,为了关联两个表中的记录,把主键id分别冗余存储在这两个表中。垂直拆分效果如图4所示。 图4 垂直拆分效果 说明:本文节选自北京理工大学出版社新出版的《MySQL从入门到部署实战(视频教学版)》。
作者:陈业贵 华为云享专家 51cto(专家博主 明日之星 TOP红人) 阿里云专家博主 文章目录 sql 快递表: 解析: 数据 退货表 解析: 数据 sql 快递表: CREATE TABLE t_delivery 一个快递表是吧。也就是这个表包括送快递这块的方方面面对吧,那这个快递表是送什么的。是不是订单里面的商品。所以得包括订单表的id对吧。也包括商品对吧。 关联的别的表需要索引的。 unsigned not null COMMENT "退款金额", payment_type tinyint unsigned not null COMMENT "退款方式:1借记卡,2信用卡,3微信,4支付宝 INDEX idx_order_id(order_id), INDEX idx_qa_id(qa_id), INDEX idx_status(`status`) ) COMMENT="退货表"
相关文章: MySQL高性能表设计规范:http://www.jianshu.com/p/f797bbe11d76 MySQL EXPLAIN详解:http://www.jianshu.com/p/ea3fc71fdc45 image.png 良好的逻辑设计和物理设计是高性能的基石, 应该根据系统将要执行的查询语句来设计schema, 这往往需要权衡各种因素。 FLOAT使用4个字节存储。DOUBLE占用8个字节,相比FLOAT有更高的精度和更大的范围。和整数类型一样, 能选择的只是存储类型; MySQL使用DOUBLE作为内部浮点计算的类型。 4.BLOB和TEXT类型 BLOB和 TEXT都是为存储很大的数据而设计的字符串数据类型, 分别采用 二进制和字符方式存储 。 二、表结构设计 1.范式和反范式 对于任何给定的数据通常都有很多种表示方法, 从完全的范式化到完全的反范式化, 以及两者的折中。 在范式化的数据库中, 每个事实数据会出现并且只出现一次。
引言: 上一篇我介绍了 MySQL 范式标准化表设计,范式设计具有以下优点: 1、把如何消除数据冗余做到极致,从而减少关系表对磁盘的额外占用。 2、各个表之间的关系表现非常清晰,可读性非常强。 正文: 但是范式设计同样也有缺点: 表范式标准化,等级越高,表数量就越多。比如 2NF 比 1NF 可能要多几张表,3NF 比 2NF 可能又要多几张表等等。 综上,我们需要结合范式设计的优点,并且想办法去解决范式设计的缺点, 由此带来的思路就是允许数据有一定程度的冗余,用空间换时间。比如现在微服务设计、NOSQL 数据库等根本不会考虑范式标准理论。 反范式也即通过一定的冗余把原先高级别的范式设计降低为低级别的范式设计来减少范式设计带来的表数量增多的缺点。 联合查询的开销非常大,为了消除不必要的联合查询,此时就不能完全按照范式理念来设计表,需要一定的反范式思想,针对每个需求,添加必要的冗余列方可达到简化查询。
希望我能说说我在数据库表设计时踩过的坑。那么,我们今天就来聊聊我在数据库表设计时踩过的坑,以及现在对数据库表设计的一点建议。希望能够帮助到你。 utf8的锅 经验提示: 在设计数据表时,一定要注意该字段存储的内容,如果允许设置表情,则一定不能使用utf8,而是使用utf8mb4。 注释 之前在数据库表设计时,就没有加注释的习惯,造成的直接后果是:数据库设计阶段一过,后续数据表的使用中,字段名就全靠猜了。我们写代码是知道注释是非常重要的,同样在设计数据库表时,注释也非常重要! 索引怎么加,索引重不重要,可以查看《写会MySQL索引》一文进行查看!唉,我就吃过不少没加索引或忘记添加索引的亏,记忆犹新!!! 小结 以上是我数据库设计表时躺过的坑,下面小结精简版本一下: 允许保存表情的表,存储格式设计为utf8mb4,避免使用utf8。 选择合适的数据类型。
这是学习笔记的第 2038 篇文章 关于MySQL周期表管理,近期做了初步的设计,总体上是希望把周期表的管理和业务同学对接起来,实现流程化的管理。 对于整体的设计方面,需要开发后端的API,API列表如下: 周期表列表 周期表创建 周期表属性变更 周期表批量变更接口 周期表数据清理接口 巡检任务 大数据提取接口 即时通讯提醒接口 对于模型的设计是重中之重 ,也能够决定我们的周期表管理的存储设计优劣。 模型方面考虑了如下的一些表: Mysql_dailytable 周期表 Mysql_cycle_table_manage_log 周期表维护日志(包含配置创建,属性修改) Mysql_cycle_table_ddl_log 周期表变化历史记录 Mysql_cycle_table_inspection_log 模型详细设计如下: Mysql_dailytable id ip_addr db_port db_name Operator_method
在大部分情况下, 跳跃表的效率可以和平衡树相媲美, 并且因为跳跃表的实现比平衡树要来得更为简单, 所以有不少程序都使用跳跃表来代替平衡树. 跳跃表 使用一个 zskiplist 结构来持有节点, 可以更方便地访问跳跃表的表头节点和表尾节点, 又或者快速地获取跳跃表节点 的数量 (也即是跳跃表的长度) 等信息. zskiplist 结构的定义如下 跳跃表 API 函数 作用 时间复杂度 zslCreate 创建一个新的跳跃表. O(1) zslFree 释放给定跳跃表,以及表中包含的所有节点. O(N),N 为被删除节点数量. zslDeleteRangeByRank 给定一个排位范围, 删除跳跃表中所有在这个范围之内的节点. O(N),N 为被删除节点数量. 4. 用于保存跳跃表信息(比如表头节点, 表尾节点, 长度), 而 zskiplistNode 则用于表示跳跃表节点; 每个跳跃表节点的层高都是 1 至 32 之间的随机数; 在同一个跳跃表中, 多个节点可以包含相同的分值
如果查询中包含可为 NULL 的列,对 MySQL 来说更难优化 ,因为可为 NULL 的列使 得索引、索引统计和值比较都更复杂 。 可为NULL 的列会使用更多的存储空间 ,在 MySQL 里也需要特殊处理 。 InnoDB 被设计对于CPU效率和最大性能 当处理大量数据时 InnoDB 表可以处理大量的数据,即使操作系统 文件限制为2GB CHARSET=utf8mb4 这是字符集 数据 (banner子项表 可为NULL 的列会使用更多的存储空间 ,在 MySQL 里也需要特殊处理 。 InnoDB 被设计对于CPU效率和最大性能 当处理大量数据时 InnoDB 表可以处理大量的数据,即使操作系统 文件限制为2GB CHARSET=utf8mb4 这是字符集 数据 图片 上图的
作者:陈业贵 华为云享专家 51cto(专家博主 明日之星 TOP红人) 阿里云专家博主 文章目录 sql(省份表) sql(城市表) 省市表之间的联系是: province_id int unsigned UNIQUE unq_province(province)是什么意思》 举个例子: 是不是表一般都要有idname呀 像省份是不是 province 就是name呀 sql(省份表) CREATE ; 举个例子: 是不是表一般都要有idname呀 像省份是不是 city 就是name呀 是不是得说这个城市属于哪一个省份呀 sql(城市表) CREATE table t_city( id 主键是能确定一条记录的唯一标识,主键字段必须唯一,必须非空,一个表中只能有一个主键,主键可以包含一个或多个字段。 打个比方,一条记录包括身份正号,姓名,年龄,学校,国籍,性别等。 别人看懂这是什么字段或者表或者数据库 UNIQUE unq_province(province)是什么意思》 因为搜索的时候是先搜索某省才能搜索某市哦
作者:陈业贵 华为云享专家 51cto(专家博主 明日之星 TOP红人) 阿里云专家博主 文章目录 sql 订单表 数据 订单详情表 数据: 订单号与流水号有什么不同? unsigned not null COMMENT "总金额", payment_type tinyint unsigned not null COMMENT "支付方式:1借记卡,信用卡,3微信,4支付宝 ,5现金", `status` tinyint unsigned not null COMMENT "状态:1未付款,2已付款,3已发货,4已签收", postage decimal(10,2) unsigned ,5现金", `status` tinyint unsigned not null COMMENT "状态:1未付款,2已付款,3已发货,4已签收", postage decimal(10,2 别人看懂这是什么字段或者表或者数据库 为什么要用int unsigned类型呢? 因为id是不是整数的。
2、Stored procedure (包括存储过程,函数,触发器)对于 MYSQL 来说还不是很成熟, 没有完善的出错记录处理,不建议使用。 4、请不要使用外键约束,如果数据存在外键关系,请在程序层面实现。 5、必须采用 UTF8 编码。 二、数据库对象设计规范 1、表 设计 a)在设计时尽量包含两个日期字段:crt_time(创建日期),upd_time(修改日期)且 非空, 对表的记录进行更新的时候,必须包含对 upd_time字段的更新 d)Mysql 的表尽量设置成 KV(Key-Value)结构,这样便于扩展和维护。 e)当表的字段数非常多时,可以将表分成两张表,一张作为条件查询表,一张作为详细内容表(主要是为了性能考虑)。 h)由于MYSQL表DDL维护成本很高,所以在适当的时候,可以有一定的字段容余。 比如:Value1,Value2,Value3 这样的字段。
作者:陈业贵 华为云享专家 51cto(专家博主 明日之星 TOP红人) 阿里云专家博主 文章目录 sql(采购表) 解释 你说要采购东西是吧。提供要采购的商品。数量 运去那号仓库。 日期时间 数据 sql(入库信息表) 解释: 解析: 数据 sql(入库商品表) PRIMARY KEY(productin_id,purchase_id) ---- sql(采购表) CREATE table 日期时间 采购的是商品表t_sku中的id==1的商品. num:数量是五十部手机. warehouse_id:是为一号仓库做的采购。 in_price:采购价格3000元. buyer_id:采购员编号为20 status:完成采购就为1.否则0 数据 sql(入库信息表) CREATE TABLE t_productin( id int unsigned PRIMARY 支付方式1 数据 sql(入库商品表) CREATE TABLE t_productin_purchase( productin_id int unsigned not null COMMENT "