加入收藏 | 设为首页 | 会员中心 | 我要投稿 甘孜站长网 (https://www.0836zz.com.cn/)- 运维、物联设备、数据计算、智能推荐、云管理!
当前位置: 首页 > 站长资讯 > 传媒 > 正文

如何使用Docker内的Kafka服务?

发布时间:2021-02-07 10:53:12 所属栏目:传媒 来源:互联网
导读:背景 因为工作岗位的原因,负责制定了关于后端组数据库的规约规范,作为所有产品线的规范,历经几版的修改,最终形成下边的文本。 规范在整个后端执行也有大半年的时间,对于整个团队在开发阶段就减少不恰当的建表语句、错误SQL、错误的索引有积极的意义,故

背景

因为工作岗位的原因,负责制定了关于后端组数据库的规约规范,作为所有产品线的规范,历经几版的修改,最终形成下边的文本。

规范在整个后端执行也有大半年的时间,对于整个团队在开发阶段就减少不恰当的建表语句、错误SQL、错误的索引有积极的意义,故分享出来给大家参考。

下边分为建表规约、SQL规约、索引规约三个部分,每部分的每一条都有强制、建议两个级别,大家在参考时,根据自己公司的情况来权衡。

一、建表规约

【强制】(1) 存储引擎必须使用InnoDB

解读:InnoDB支持事物、行级锁、并发性能更好,CPU及内存缓存页优化使得资源利用率更高。

【强制】(2)每张表必须设置一个主键ID,且这个主键ID使用自增主键(在满足需要的情况下尽量短),除非在分库分表环境下

解读:由于InnoDB组织数据的方式决定了需要有一个主键,而且若是这个主键ID是单调递增的可以有效提高插入的性能,避免过多的页分裂、减少表碎片提高空间的使用率。 而在分库分表环境下,则需要统一来分配各个表中的主键值,从而避免整个逻辑表中主键重复。

【强制】(3)必须使用utf8mb4字符集

解读:在Mysql中的UTF-8并非“真正的UTF-8”,而utf8mb4”才是真正的“UTF-8”。

【强制】(4) 数据库表、表字段必须加入中文注释

解读:大家都别懒。

【强制】(5) 库名、表名、字段名均小写,下划线风格,不超过32个字符,必须见名知意,禁止拼音英文混用

解读:约定。

【强制】(6)单表列数目必须小于30,若超过则应该考虑将表拆分

解读:单表列数太多使得Mysql服务器处理InnoDB返回数据之间的映射成本太高。

【强制】(7)禁止使用外键,如果有外键完整性约束,需要应用程序控制

解读:外键会导致表与表之间耦合,UPDATE与DELETE操作都会涉及相关联的表,十分影响SQL的性能,甚至会造成死锁。

【强制】(8)必须把字段定义为NOT NULL并且提供默认值

解读:

  •  NULL的列使索引/索引统计/值比较都更加复杂,对MySQL来说更难优化;
  •  NULL这种类型Msql内部需要进行特殊处理,增加数据库处理记录的复杂性;同等条件下,表中有较多空字段的时候,数据库的处理性能会降低很多;
  •  NULL值需要更多的存储空,无论是表还是索引中每行中的NULL的列都需要额外的空间来标识。

【强制】(9)禁用保留字,如DESC、RANGE、MARCH等,请参考Mysql官方保留字

【强制】(10)如果存储的字符串长度几乎相等,使用CHAR定长字符串类型。

解读:能够减少空间碎片,节省存储空间。

【建议】(11)在一些场景下,考虑使用TIMESTAMP代替DATETIME

解读:

  •  这两种类型的都能表达"yyyy-MM-dd HH:mm:ss"格式的时间,TIMESTAMP只需要占用4个字节的长度,可以存储的范围为(1970-2038)年,在各个时区,所展示的时间是不一样的;
  •  而DATETIME类型占用8个字节,对时区不敏感,可以存储的范围为(1001-9999)年。

* 【建议】(12)当心自动生成的Schema,建议所有的Schema手动编写

解读:对于一些数据库客户端不要太过信任。

二、SQL规约

【建议】 (1) 为了充分利用缓存,不允许使用自定义函数、存储函数、用户变量

解读:如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、Mysql库中的系统表,其查询结果都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间,返回不同的查询结果。

(编辑:甘孜站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读