精华内容
下载资源
问答
  • MySQL使用规范

    2021-03-03 19:49:02
    一、 表设计类强制类规范1. 创建表的存储引擎必须是InnoDB。2. 每个表必须显式的指定一个主键。3. 不允许使用联合主键。4. 不允许使用外键。5. 不允许存在和主键重复的索引。6. 自增长字段必须是主键或唯一索引。7. ...

    一、    表设计类

    强制类规范

    1. 创建表的存储引擎必须是InnoDB。

    2. 每个表必须显式的指定一个主键。

    3. 不允许使用联合主键。

    4. 不允许使用外键。

    5. 不允许存在和主键重复的索引。

    6. 自增长字段必须是主键或唯一索引。

    7. 不允许在数据库中存储诸如图片,影像之类的二进制数据。

    8. 不允许使用TEXT类型字段

    9. 建表时不允许显式的指定除了utf8之外的其他字符集。

    10. 对于所有声明为NOT NULL的字段,必须显式指定默认值。

    11. 必须包含时间戳字段DataChange_LastTime,定义默认值为CURRENT_TIMESTAMP和on update CURRENT_TIMESTAMP,并添加索引。

    12.不要使用系统或者常见的名称作为表名 如order

    建议类规范

    1. 建议使用自增长字段作为主键。

    2. 对较长的字符类型,如果需要索引,则建立前缀索引。

    3. 不建议在数据库存放日志。

    4. 建议将字段都定义为not null。

    5. 选用能满足需求的最小类型。

    6. 避免使用保留字命名DB对象。

    7. 对表和字段都添加备注说明。

    二、    SQL类

    强制类规范

    1. 禁止使用子查询。

    2. 禁止使用select *,必须指定需要的字段。

    3. update/delete只能单表操作,不允许多表关联,不允许用子查询,且一定要带where条件。

    4. insert语句要显式指定插入的列名,且不允许使用insert .... select的形式。

    5. 不允许使用存储过程、存储函数、触发器和视图。

    6. 单条查询语句中,不允许出现多于一次的join。

    7. 不要在where后的筛选字段上做运算。

    建议类规范

    1. 尽量不要在数据库里做运算。

    2. 尽量不要做‘%’前缀模糊查询,如 like '%name'。

    3. 不要使用大偏移量的limit分页。

    4. 连接MySQL不要设置成autocommit=0。

    5. 批量insert语句最好采用bulk insert的方法,如insert into table(xxx) values (xxx),(xxx)。

    6. update/delete尽量根据主键进行操作。

    7.  尽量减少count()的使用,尤其是用来频繁获取全表记录数。

    8. 使用group by时,如无排序的需求,建议加order by null。

    9.  Join中使用的关联字段使用统一数据类型。

    展开全文
  • 开发人员可以修改表结构,可以随意修改其中的数据但是需要保证不影响其他开发同事。qa:测试环境,开发可读写,开发人员可以通过工具修改表结构。sim:模拟环境,开发可读写,发起上线请求时,会先在这个环境上进行...

    数据库环境

    dev:开发环境,开发可读写,可修改表结构。开发人员可以修改表结构,可以随意修改其中的数据但是需要保证不影响其他开发同事。

    qa:测试环境,开发可读写,开发人员可以通过工具修改表结构。

    sim:模拟环境,开发可读写,发起上线请求时,会先在这个环境上进行预执行,这个环境也可供部署上线演练或压力测试使用。

    real:生产数据库从库(准实时同步),只读环境,不允许修改数据,不允许修改表结构,供线上问题查找,数据查询等使用。

    online:线上环境,开发人员不允许直接在线上环境进行数据库操作,如果需要操作必须找DBA进行操作并进行相应记录,禁止进行压力测试。

    这些环境的机器,一定要做到权限划分明确,读写帐号分离,并且有辨识度,能区分具体业务。例如用户名w_account,r_ account 分别代表读、写账号,account是读写账号。

    命名规范

    基本命名原则

    使用有意义的英文词汇,词汇中间以下划线分隔。(不要用拼音)

    只能使用英文字母,数字,下划线,并以英文字母开头。

    库、表、字段全部采用小写,不要使用驼峰式命名。

    避免用ORACLE、MySQL的保留字,如desc,关键字如index。

    命名禁止超过32个字符,须见名之意,建议使用名词不是动词

    数据库,数据表一律使用前缀

    临时库、表名必须以tmp为前缀,并以日期为后缀

    备份库、表必须以bak为前缀,并以日期为后缀

    为什么库、表、字段全部采用小写?

    在 MySQL 中,数据库和表对就于那些目录下的目录和文件。因而,操作系统的敏感性决定数据库和表命名的大小写敏感。

    Windows下是不区分大小写的。

    Linux下大小写规则:

    数据库名与表名是严格区分大小写的;

    表的别名是严格区分大小写的;

    列名与列的别名在所有的情况下均是忽略大小写的;

    变量名也是严格区分大小写的;

    如果已经设置了驼峰式的命名如何解决?需要在MySQL的配置文件my.ini中增加 lower_case_table_names = 1即可。

    表命名

    同一个模块的表尽可能使用相同的前缀,表名称尽可能表达含义。所有日志表均以 log_ 开头

    字段命名

    表达其实际含义的英文单词或简写。布尔意义的字段以“is_”作为前缀,后接动词过去分词。

    各表之间相同意义的字段应同名。各表之间相同意义的字段,以去掉模块前缀的表名_字段名命名。

    外键字段用表名_字段名表示其关联关系。

    表的主键一般都约定成为id,自增类型,是别的表的外键均使用xxx_id的方式来表明。

    索引命名

    非唯一索引必须按照“idx_字段名称_字段名称[_字段名]”进行命名

    唯一索引必须按照“uniq_字段名称_字段名称[_字段名]”进行命名

    约束命名

    主键约束:pk_表名称。

    唯一约束:uk_表名称_字段名。(应用中需要同时有唯一性检查逻辑。)

    触发器命名

    trg_表名_操作。

    函数过程命名

    采用动词+名词的形式表达其含义。

    序列命名

    seq_表名

    表设计规范

    1、表引擎取决于实际应用场景;日志及报表类表建议用myisam,与交易,审核,金额相关的表建议用innodb引擎。如无说明,建表时一律采用innodb引擎。myisam与innodb的区别

    2、默认使用utf8mb4字符集,数据库排序规则使用utf8mb4_general_ci,(由于数据库定义使用了默认,数据表可以不再定义,但为保险起见,建议都写上)。

    为什么字符集不选择utf8,排序规则不使用utf8_general_ci?

    采用utf8编码的MySQL无法保存占位是4个字节的Emoji表情。为了使后端的项目,全面支持客户端输入的Emoji表情,升级编码为utf8mb4是最佳解决方案。对于JDBC连接串设置了characterEncoding为utf8或者做了上述配置仍旧无法正常插入emoji数据的情况,需要在代码中指定连接的字符集为utf8mb4。

    3、所有表、字段均应用 comment 列属性来描述此表、字段所代表的真正含义,如枚举值则建议将该字段中使用的内容都定义出来。

    4、如无说明,表中的第一个id字段一定是主键且为自动增长,禁止在非事务内作为上下文作为条件进行数据传递。禁止使用varchar类型作为主键语句设计。

    5、如无说明,表必须包含create_time和modify_time字段,即表必须包含记录创建时间和修改时间的字段

    6、如无说明,表必须包含is_del,用来标示数据是否被删除,原则上数据库数据不允许物理删除。

    7、用尽量少的存储空间来存数一个字段的数据

    能用int的就不用char或者varchar

    能用tinyint的就不用int

    使用UNSIGNED存储非负数值。

    不建议使用ENUM、SET类型,使用TINYINT来代替

    使用短数据类型,比如取值范围为0-80时,使用TINYINT UNSIGNED

    存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE

    时间字段,除特殊情况一律采用int来记录unix_timestamp

    存储年使用YEAR类型。

    存储日期使用DATE类型。

    存储时间(精确到秒)建议使用TIMESTAMP类型,因为TIMESTAMP使用4字节,DATETIME使用8个字节。

    建议使用INT UNSIGNED存储IPV4。

    尽可能不使用TEXT、BLOB类型

    禁止在数据库中使用VARBINARY、BLOB存储图片、文件等。建议使用其他方式存储(TFS/SFS),MySQL只保存指针信息。

    单条记录大小禁止超过8k(列长度(中文)*3(UTF8)+列长度(英文)*1)

    datetime与timestamp有什么不同?

    相同点:TIMESTAMP列的显示格式与DATETIME列相同。显示宽度固定在19字符,并且格式为YYYY-MM-DD HH:MM:SS。

    不同点:

    TIMESTAMP

    4个字节储存,时间范围:1970-01-01 08:00:01 ~ 2038-01-19 11:14:07

    值以UTC格式保存,涉及时区转化 ,存储时对当前的时区进行转换,检索时再转换回当前的时区。

    datetime

    8个字节储存,时间范围:1000-01-01 00:00:00 ~ 9999-12-31 23:59:59

    实际格式储存,与时区无关

    如何使用TIMESTAMP的自动赋值属性?

    将当前时间作为ts的默认值:ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP。

    当行更新时,更新ts的值:ts TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP。

    可以将1和2结合起来:ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。

    如何使用INT UNSIGNED存储ip?

    使用INT UNSIGNED而不是char(15)来存储ipv4地址,通过MySQL函数inet_ntoa和inet_aton来进行转化。Ipv6地址目前没有转化函数,需要使用DECIMAL或者两个bigINT来存储。

    8、如无备注,所有字段都设置NOT NULL,并设置默认值;

    9、禁止在数据库中存储明文密码

    10、如无备注,所有的布尔值字段,如is_hot、is_deleted,都必须设置一个默认值,并设为0;

    11、如无备注,排序字段order_id在程序中默认使用降序排列;

    12、整形定义中不添加长度,比如使用INT,而不是INT[4]

    INT[M],M值代表什么含义?

    注意数值类型括号后面的数字只是表示宽度而跟存储范围没有关系。很多人他们认为INT(4)和INT(10)其取值范围分别是 (-9999到9999)和(-9999999999到9999999999),这种理解是错误的。其实对整型中的 M值与 ZEROFILL 属性结合使用时可以实现列值等宽。不管INT[M]中M值是多少,其取值范围还是 (-2147483648到2147483647 有符号时),(0到4294967295无符号时)。

    显示宽度并不限制可以在列内保存的值的范围,也不限制超过列的指定宽度的值的显示。当结合可选扩展属性ZEROFILL使用时默认补充的空格用零代替。例如:对于声明为INT(5) ZEROFILL的列,值4检索为00004。请注意如果在整数列保存超过显示宽度的一个值,当MySQL为复杂联接生成临时表时会遇到问题,因为在这些情况下MySQL相信数据适合原列宽度,如果为一个数值列指定ZEROFILL, MySQL自动为该列添加UNSIGNED属性。

    13、使用VARBINARY存储大小写敏感的变长字符串

    什么时候用CHAR,什么时候用VARCHAR?

    CHAR和VARCHAR类型类似,但它们保存和检索的方式不同。它们的最大长度和是否尾部空格被保留等方面也不同。CHAR和VARCHAR类型声明的长度表示你想要保存的最大字符数。例如,CHAR(30)可以占用30个字符。

    CHAR列的长度固定为创建表时声明的长度。长度可以为从0到255的任何值。当保存CHAR值时,在它们的右边填充空格以达到指定的长度。当检索到CHAR值时,尾部的空格被删除掉。在存储或检索过程中不进行大小写转换。

    VARCHAR列中的值为可变长字符串。长度可以指定为0到65,535之间的值。(VARCHAR的最大有效长度由最大行大小和使用的字符集确定。整体最大长度是65,532字节)。

    同CHAR对比,VARCHAR值保存时只保存需要的字符数,另加一个字节来记录长度(如果列声明的长度超过255,则使用两个字节)。VARCHAR值保存时不进行填充。当值保存和检索时尾部的空格仍保留,符合标准SQL。

    char适合存储用户密码的MD5哈希值,它的长度总是一样的。对于经常改变的值,char也好于varchar,因为固定长度的行不容易产生碎片,对于很短的列,char的效率也高于varchar。char(1)字符串对于单字节字符集只会占用一个字节,但是varchar(1)则会占用2个字节,因为1个字节用来存储长度信息。

    索引设计规范

    MySQL的查询速度依赖良好的索引设计,因此索引对于高性能至关重要。合理的索引会加快查询速度(包括UPDATE和DELETE的速度,MySQL会将包含该行的page加载到内存中,然后进行UPDATE或者DELETE操作),不合理的索引会降低速度。MySQL索引查找类似于新华字典的拼音和部首查找,当拼音和部首索引不存在时,只能通过一页一页的翻页来查找。当MySQL查询不能使用索引时,MySQL会进行全表扫描,会消耗大量的IO。索引的用途:去重、加速定位、避免排序、覆盖索引。

    什么是覆盖索引?

    InnoDB存储引擎中,secondary index(非主键索引)中没有直接存储行地址,存储主键值。如果用户需要查询secondary index中所不包含的数据列时,需要先通过secondary index查找到主键值,然后再通过主键查询到其他数据列,因此需要查询两次。覆盖索引的概念就是查询可以通过在一个索引中完成,覆盖索引效率会比较高,主键查询是天然的覆盖索引。合理的创建索引以及合理的使用查询语句,当使用到覆盖索引时可以获得性能提升。比如SELECT email,uid FROM user_email WHERE uid=xx,如果uid不是主键,适当时候可以将索引添加为index(uid,email),以获得性能提升。

    索引的基本规范

    1、索引数量控制,单张表中索引数量不超过5个,单个索引中的字段数不超过5个。

    综合评估数据密度和分布

    考虑查询和更新比例

    为什么一张表中不能存在过多的索引?

    InnoDB的secondary index使用b+tree来存储,因此在UPDATE、DELETE、INSERT的时候需要对b+tree进行调整,过多的索引会减慢更新的速度。

    2、对字符串使用前缀索引,前缀索引长度不超过8个字符,建议优先考虑前缀索引,必要时可添加伪列并建立索引。

    不要索引blob/text等字段,不要索引大型字段,这样做会让索引占用太多的存储空间

    什么是前缀索引?

    前缀索引说白了就是对文本的前几个字符(具体是几个字符在建立索引时指定)建立索引,这样建立起来的索引更小,所以查询更快。 前缀索引能有效减小索引文件的大小,提高索引的速度。但是前缀索引也有它的坏处:MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引,也不能把它们用作覆盖索引(Covering Index)。

    建立前缀索引的语法:ALTER TABLE table_name ADD KEY(column_name(prefix_length));

    3、主键准则

    表必须有主键

    不使用更新频繁的列

    尽量不选择字符串列

    不使用UUID MD5 HASH

    默认使用非空的唯一键

    建议选择自增或发号器

    4、 重要的SQL必须被索引,核心SQL优先考虑覆盖索索引

    UPDATE、DELETE语句的WHERE条件列

    ORDER BY、GROUP BY、DISTINCT的字段

    多表JOIN的字段

    5、区分度最大的字段放在前面

    选择筛选性更优的字段放在最前面,比如单号、userid等,type,status等筛选性一般不建议放在最前面

    索引根据左前缀原则,当建立一个联合索引(a,b,c),则查询条件里面只有包含(a)或(a,b)或(a,b,c)的时候才能走索引,(a,c)作为条件的时候只能使用到a列索引,所以这个时候要确定a的返回列一定不能太多,不然语句设计就不合理,(b,c)则不能走索引

    合理创建联合索引(避免冗余),(a,b,c) 相当于 (a) 、(a,b) 、(a,b,c)

    6、索引禁忌

    不在低基数列上建立索引,例如“性别”

    不在索引列进行数学运算和函数运算

    不要索引常用的小型表

    7、 尽量不使用外键

    外键用来保护参照完整性,可在业务端实现

    对父表和子表的操作会相互影响,降低可用性

    INNODB本身对online DDL的限制

    MYSQL 中索引的限制

    MYISAM 存储引擎索引长度的总和不能超过 1000 字节

    BLOB 和 TEXT 类型的列只能创建前缀索引

    MYSQL 目前不支持函数索引

    使用不等于 (!= 或者 <>) 的时候, MYSQL 无法使用索引。

    过滤字段使用函数运算 (如 abs (column)) 后, MYSQL无法使用索引。

    join语句中join条件字段类型不一致的时候MYSQL无法使用索引

    使用 LIKE 操作的时候如果条件以通配符开始 (如 ‘%abc…’)时, MYSQL无法使用索引。

    使用非等值查询的时候, MYSQL 无法使用 Hash 索引。

    语句设计规范

    1、使用预编译语句

    只传参数,比传递SQL语句更高效

    一次解析,多次使用

    降低SQL注入概率

    2、避免隐式转换

    会导致索引失效

    3、充分利用前缀索引

    必须是最左前缀

    不可能同时用到两个范围条件

    不使用%前导的查询,如like “%ab”

    4、不使用负向查询,如not in/like

    无法使用索引,导致全表扫描

    全表扫描导致buffer pool利用率降低

    5、避免使用存储过程、触发器、UDF、events等

    让数据库做最擅长的事

    降低业务耦合度,为sacle out、sharding留有余地

    避开BUG

    6、避免使用大表的JOIN

    MySQL最擅长的是单表的主键/二级索引查询

    JOIN消耗较多内存,产生临时表

    7、避免在数据库中进行数学运算

    MySQL不擅长数学运算和逻辑判断

    无法使用索引

    7、减少与数据库的交互次数

    INSERT … ON DUPLICATE KEY UPDATE

    REPLACE INTO、INSERT IGNORE 、INSERT INTO VALUES(),(),()

    UPDATE … WHERE ID IN(10,20,50,…)

    8、合理的使用分页

    限制分页展示的页数

    只能点击上一页、下一页

    采用延迟关联

    如何正确的使用分页?

    假如有类似下面分页语句:SELECT * FROM table  ORDER BY id LIMIT 10000, 10

    由于MySQL里对LIMIT OFFSET的处理方式是取出OFFSET+LIMIT的所有数据,然后去掉OFFSET,返回底部的LIMIT。所以,在OFFSET数值较大时,MySQL的查询性能会非常低。可以使用id > n 的方式进行解决:

    使用id > n 的方式有局限性,对于id不连续的问题,可以通过翻页的时候同时传入最后一个id方式来解决。

    1

    2

    3

    4

    5

    6

    7

    //输出时,找出当前结果集中的最大最小id

    //下一页

    http://example.com/page.php?last=100

    select *from table where id<100order by id desc limit10

    //上一页

    http://example.com/page.php?first=110

    select *from table where id>110order by id desc limit10

    这种方式比较大的缺点是,如果在浏览中有插入/删除操作,翻页不会更新,而总页数可能仍然是根据新的count(*) 来计算,最终可能会产生某些记录访问不到。为了修补这个问题,可以继续引入当前页码以及在上次翻页以后是否有插入/删除等影响总记录数的操作并进行缓存

    其他变种方式:

    1

    select *from table where id>=(select id from table order by id limit#offset#, 1)

    9、拒绝大SQL,拆分成小SQL

    充分利用QUERY CACHE

    充分利用多核CPU

    10、使用in代替or,in的值不超过1000个

    11、禁止使用order by rand()

    12、使用EXPLAIN诊断,避免生成临时表

    EXPLAIN语句(在MySQL客户端中执行)可以获得MySQL如何执行SELECT语句的信息。通过对SELECT语句执行EXPLAIN,可以知晓MySQL执行该SELECT语句时是否使用了索引、全表扫描、临时表、排序等信息。尽量避免MySQL进行全表扫描、使用临时表、排序等。详见官方文档。

    13、用union all而不是union

    union all与 union有什么区别?

    union和union all关键字都是将两个结果集合并为一个,但这两者从使用和效率上来说都有所不同。

    union在进行表链接后会筛选掉重复的记录,所以在表链接后会对所产生的结果集进行排序运算,删除重复的记录再返回结果。如:

    1

    2

    3

    select *from test_union1

    union

    select *from test_union2

    这个SQL在运行时先取出两个表的结果,再用排序空间进行排序删除重复的记录,最后返回结果集,如果表数据量大的话可能会导致用磁盘进行排序。

    而union all只是简单的将两个结果合并后就返回。这样,如果返回的两个结果集中有重复的数据,那么返回的结果集就会包含重复的数据了。

    从效率上说,union all要比union快很多,所以,如果可以确认合并的两个结果集中不包含重复的数据的话,那么就使用union all,如下:

    1

    2

    3

    select *from test_union1

    union all

    select *from test_union2

    14、程序应有捕获SQL异常的处理机制

    15、禁止单条SQL语句同时更新多个表

    16、不使用select * ,SELECT语句只获取需要的字段

    消耗CPU和IO、消耗网络带宽

    无法使用覆盖索引

    减少表结构变更带来的影响

    因为大,select/join 可能生成临时表

    17、UPDATE、DELETE语句不使用LIMIT

    18、INSERT语句必须显式的指明字段名称,不使用INSERT INTO table()

    19、INSERT语句使用batch提交(INSERT INTO table VALUES(),(),()……),values的个数不超过500

    20、统计表中记录数时使用COUNT(*),而不是COUNT(primary_key)和COUNT(1) 备注:仅针对Myisam

    21、数据更新建议使用二级索引先查询出主键,再根据主键进行数据更新

    22、禁止使用跨库查询

    23、禁止使用子查询,建议将子查询转换成关联查询

    24、针对varchar类型字段的程序处理,请验证用户输入,不要超出其预设的长度;

    分表规范

    单表一到两年内数据量超过500w或数据容量超过10G考虑分表,需提前考虑历史数据迁移或应用自行删除历史数据,采用等量均衡分表或根据业务规则分表均可。要分表的数据表必须与DBA商量分表策略

    用HASH进行散表,表名后缀使用十进制数,下标从0开始

    按日期时间分表需符合YYYY[MM][DD][HH]格式

    采用合适的分库分表策略。例如千库十表、十库百表等

    禁止使用分区表,分区表对分区键有严格要,分区表在表变大后执行DDL、SHARDING、单表恢复等都变得更加困难。

    拆分大字段和访问频率低的字段,分离冷热数据

    行为规范

    批量导入、导出数据必须提前通知DBA协助观察

    禁止在线上从库执行后台管理和统计类查询

    禁止有super权限的应用程序账号存在

    产品出现非数据库导致的故障时及时通知DBA协助排查

    推广活动或上线新功能必须提前通知DBA进行流量评估

    数据库数据丢失,及时联系DBA进行恢复

    对单表的多次alter操作必须合并为一次操作

    不在MySQL数据库中存放业务逻辑

    重大项目的数据库方案选型和设计必须提前通知DBA参与

    对特别重要的库表,提前与DBA沟通确定维护和备份优先级

    不在业务高峰期批量更新、查询数据库其他规范

    提交线上建表改表需求,必须详细注明所有相关SQL语句

    其他规范

    日志类数据不建议存储在MySQL上,优先考虑Hbase或OceanBase,如需要存储请找DBA评估使用压缩表存储。

    展开全文
  • GitLab使用规范

    2021-02-25 13:38:58
    我们选择使用的是Gitlab flow管理流程,他是功能驱动式开发(Feature-driven development,简称FDD)。 需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该...

    一、Gitlab flow管理流程说明

    我们选择使用的是Gitlab flow管理流程,他是功能驱动式开发(Feature-driven development,简称FDD)。

    需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

    Gitlab flow的最大原则叫做上游优先(upsteam first),即只存在一个主分支master,它是所有其他分支的上游。只有上游分支采纳的代码变化,才能应用到其他分支。

    Gitlab flow分成两种情况,可以适用于不同的开发流程,满足我们管理需求。

    (一)、持续发布(针对网站类的项目)

    对于持续发布的项目,它建议在master分支以外,再建立不同的环境分支。

    比如,开发环境的分支是master预发环境的分支是pre-production生产环境的分支是production

    开发分支是预发分支的上游,预发分支又是生产分支的上游。代码的变化,必须由上游下游发展。

    如果生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master,确认没有问题,再cherry-pick到pre-production,这一步也没有问题,才进入production。

    只有紧急情况,才允许跳过上游,直接合并到下游分支。

    Alt

    (二)、版本发布(针对按照版本发布的项目)

    对于"版本发布"的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如V2.3-stable、V2.4-stable等等,每次拉出一个稳定版本的同时也在master上面打上相应的标签。

    为了方便内部测试,需要从master分支拉出一个test分支,每次提测时都标明当前测试版本号V2.3-Alpha。

    以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号标签。

    Alt

    二、分支命名规范

    1. 功能分支:feature/(功能英文缩写)

    2. 版本分支:release/(版本号)

    3. 修复分支:hotfix/(问题英文英文缩写)

    4. OEM分支:oem/(公司英文缩写)/(版本号)

    5. 项目分支:project/(公司英文缩写)/(版本号)

    修复分支和功能分支从master支派生,最后还要回归到master支上。

    三、版本号命名规范

    版本号格式:v<主版本号>.<副版本号>.<迭代版本号>.<发布号> (标识区)

    版本号的初始值:v1.0.0.0

    主版本号和副版本号都由产品部定,它们变更标志着重要的功能或结构变动;主版本号或副版本号变更时,发布号和迭代版本号置0

    迭代版本号和发布号由开发组定,迭代版本号得变动标志着小功能的添加,迭代版本号变更时,发布号置0;发布号的变更用于体现小的功能变更或bug修复,每次变更发布号+1

    在开发阶段版本号后面需要添加标识

    如:

    Alpha:是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。

    Beta:也是测试版,这个阶段的版本会一直加入新的功能。在Alpha版之后推出。

    RC:(Release Candidate) 顾名思义么 ! 用在软件上就是候选版本。系统平台上就是发行候选版本。RC版不会再加入新的功能了,主要着重于除错。

    GA:General Availability,正式发布的版本,在国外都是用GA来说明release版本的。

    正式的版本由分支管理,小版本由tag管理

    四、Commit格式规范

    Commit格式:类型+说明+地址

    Commit格式说明:

    1.类型,只允许使用下面7个标识。

    feat:新功能(feature)

    fix:修补bug,可以是QA发现的BUG,也可以是研发自己发现的BUG。

    docs:文档(documentation)

    style: 格式(不影响代码运行的变动)

    refactor:重构(即不是新增功能,也不是修改bug的代码变动)

    test:增加测试

    perf:优化相关,比如提升性能、体验

    chore:构建过程或辅助工具的变动

    revert:回滚到上一个版本。

    merge:代码合并。

    sync:同步主线或分支的Bug。

    2.说明,为commit的目的简要说明,字数不可以超过50个字符

    3.地址:用于类型为feat和fix类型的commit,用于定位具体需求和bug,地址来源与jira

    五、gitlab权限说明

    Guest:可以创建issue、发表评论,不能读写版本库

    Reporter:可以克隆代码,不能提交,可以赋予测试、产品经理此权限

    Developer:可以克隆代码、开发、提交、push,可以赋予开发人员此权限

    MainMaster:可以创建项目、添加tag、保护分支、添加项目成员、编辑项目,一般GitLab管理员或者CTO才有此权限

    展开全文
  • Redis的使用规范

    2021-10-18 15:49:25
    1、Redis的使用规范 1.1、 key的规范要点 我们设计Redis的key的时候,要注意以下这几个点: 以业务名为key前缀,用冒号隔开,以防止key冲突覆盖。如,live:rank:1 确保key的语义清晰的情况下,key的长度尽量...

     1、Redis的使用规范

    1.1、 key的规范要点

    我们设计Redis的key的时候,要注意以下这几个点:

    • 以业务名为key前缀,用冒号隔开,以防止key冲突覆盖。如,live:rank:1
    • 确保key的语义清晰的情况下,key的长度尽量小于30个字符。
    • key禁止包含特殊字符,如空格、换行、单双引号以及其他转义字符。
    • Redis的key尽量设置ttl,以保证不使用的Key能被及时清理或淘汰。

    1.2、value的规范要点

    Redis的value值不可以随意设置的哦。

    第一点,如果大量存储bigKey是会有问题的,会导致慢查询,内存增长过快等等。

    • 如果是String类型,单个value大小控制10k以内。
    • 如果是hash、list、set、zset类型,元素个数一般不超过5000。

    第二点,要选择适合的数据类型。不少小伙伴只用Redis的String类型,上来就是set和get。实际上,Redis 提供了丰富的数据结构类型,有些业务场景,更适合hash、zset等其他数据结果。

    image.png

    反例:

    set user:666:name jay
    set user:666:age 18
    复制代码

    正例

    hmset user:666 name jay age 18 
    复制代码

    1.3. 给Key设置过期时间,同时注意不同业务的key,尽量过期时间分散一点

    • 因为Redis的数据是存在内存中的,而内存资源是很宝贵的。
    • 我们一般是把Redis当做缓存来用,而不是数据库,所以key的生命周期就不宜太长久啦。
    • 因此,你的key,一般建议用expire设置过期时间

    如果大量的key在某个时间点集中过期,到过期的那个时间点,Redis可能会存在卡顿,甚至出现缓存雪崩现象,因此一般不同业务的key,过期时间应该分散一些。有时候,同业务的,也可以在时间上加一个随机值,让过期时间分散一些。

    1.4.建议使用批量操作提高效率

    我们日常写SQL的时候,都知道,批量操作效率会更高,一次更新50条,比循环50次,每次更新一条效率更高。其实Redis操作命令也是这个道理。

    Redis客户端执行一次命令可分为4个过程:1.发送命令-> 2.命令排队-> 3.命令执行-> 4. 返回结果。1和4 称为RRT(命令执行往返时间)。 Redis提供了批量操作命令,如mget、mset等,可有效节约RRT。但是呢,大部分的命令,是不支持批量操作的,比如hgetall,并没有mhgetall存在。Pipeline 则可以解决这个问题。

    Pipeline是什么呢?它能将一组Redis命令进行组装,通过一次RTT传输给Redis,再将这组Redis命令的执行结果按顺序返回给客户端.

    我们先来看下没有使用Pipeline执行了n条命令的模型:

    image.png

    使用Pipeline执行了n次命令,整个过程需要1次RTT,模型如下:

    image.png

    2、Redis 有坑的那些命令

    2.1. 慎用O(n)复杂度命令,如hgetallsmemberlrange

    因为Redis是单线程执行命令的。hgetall、smember等命令时间复杂度为O(n),当n持续增加时,会导致 Redis CPU 持续飙高,阻塞其他命令的执行。

    hgetall、smember,lrange等这些命令不是一定不能使用,需要综合评估数据量,明确n的值,再去决定。 比如hgetall,如果哈希元素n比较多的话,可以优先考虑使用hscan

    2.2 慎用Redis的monitor命令

    Redis Monitor 命令用于实时打印出Redis服务器接收到的命令,如果我们想知道客户端对redis服务端做了哪些命令操作,就可以用Monitor 命令查看,但是它一般调试用而已,尽量不要在生产上用!因为monitor命令可能导致redis的内存持续飙升。

    monitor的模型是酱紫的,它会将所有在Redis服务器执行的命令进行输出,一般来讲Redis服务器的QPS是很高的,也就是如果执行了monitor命令,Redis服务器在Monitor这个客户端的输出缓冲区又会有大量“存货”,也就占用了大量Redis内存。

    image.png

    2.3、生产环境不能使用 keys指令

    Redis Keys 命令用于查找所有符合给定模式pattern的key。如果想查看Redis 某类型的key有多少个,不少小伙伴想到用keys命令,如下:

    keys key前缀*
    复制代码

    但是,redis的keys是遍历匹配的,复杂度是O(n),数据库数据越多就越慢。我们知道,redis是单线程的,如果数据比较多的话,keys指令就会导致redis线程阻塞,线上服务也会停顿了,直到指令执行完,服务才会恢复。因此,一般在生产环境,不要使用keys指令。官方文档也有声明:

    Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using sets.

    其实,可以使用scan指令,它同keys命令一样提供模式匹配功能。它的复杂度也是 O(n),但是它通过游标分步进行,不会阻塞redis线程;但是会有一定的重复概率,需要在客户端做一次去重

    scan支持增量式迭代命令,增量式迭代命令也是有缺点的:举个例子, 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素, 但是对于 SCAN 这类增量式迭代命令来说, 因为在对键进行增量式迭代的过程中, 键可能会被修改, 所以增量式迭代命令只能对被返回的元素提供有限的保证 。

    2.4 禁止使用flushall、flushdb

    • Flushall 命令用于清空整个 Redis 服务器的数据(删除所有数据库的所有 key )。
    • Flushdb 命令用于清空当前数据库中的所有 key。

    这两命令是原子性的,不会终止执行。一旦开始执行,不会执行失败的。

    2.5 注意使用del命令

    删除key你一般使用什么命令?是直接del?如果删除一个key,直接使用del命令当然没问题。但是,你想过del的时间复杂度是多少嘛?我们分情况探讨一下:

    • 如果删除一个String类型的key,时间复杂度就是O(1)可以直接del
    • 如果删除一个List/Hash/Set/ZSet类型时,它的复杂度是O(n), n表示元素个数。

    因此,如果你删除一个List/Hash/Set/ZSet类型的key时,元素越多,就越慢。当n很大时,要尤其注意,会阻塞主线程的。那么,如果不用del,我们应该怎么删除呢?

    • 如果是List类型,你可以执行lpop或者rpop,直到所有元素删除完成。
    • 如果是Hash/Set/ZSet类型,你可以先执行hscan/sscan/scan查询,再执行hdel/srem/zrem依次删除每个元素。

    2.6 避免使用SORT、SINTER等复杂度过高的命令。

    执行复杂度较高的命令,会消耗更多的 CPU 资源,会阻塞主线程。所以你要避免执行如SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE等聚合命令,一般建议把它放到客户端来执行。

    展开全文
  • 头文件的规范使用

    2021-04-14 20:18:20
    我们知道C++是一门比较复杂的语言,养成良好的代码规范对我们在以后的工作中维护项目,阅读别人的项目等都有很大的作用,因此学习了google代码规范。 几乎每个cpp文件都会包含一个.h头文件。正确使用头文件可以使...
  • MySQL 使用规范

    2021-03-03 20:36:41
    MySQL 使用规范以下规范适用在线交易(OLTP)系统的数据库。数据仓库与分析系统也可以参考。命名规范表名、字段名、索引名使用小写字母、数字,采用下划线分割表名采用模块名3个缩小字符_前缀,之后顺序为表名,最后_...
  • 这一篇主要讲述git在我们开发中的使用规范以及需要注意的问题。 笔者之前遇到的项目中分支会随便创建,开发也没有文档,分支的命名也很随意最后不知道哪个分支是做什么用的都不清楚。项目越做越乱,最后无人能接盘...
  • 史上最强的MySQL数据库设计规范(互联网大厂都使用的2021年最新版本)
  • 文件服务器使用规范

    2021-08-07 10:40:47
    文件服务器使用规范 内容精选换一换可以。SSL证书管理服务是全局服务,不论是在哪个区域购买的证书,均可在其他区域进行使用。可以。SSL证书签发后,可跨帐号进行使用。示例1:A帐号购买的SSL证书,证书签发后可以给...
  • Cppcheck 用法-编码规范

    2021-01-12 13:39:51
    编辑推荐:本文来自于csdn,本文简单介绍了一种C/C++ 代码缺陷静态检查工具Cppcheck的用法。简述Cppcheck不同于 C/C++ 编译器及很多其它分析工具,它不检查代码中的语法错误。Cppcheck只检查编译器检查不出来的 bug ...
  • Log日志规范

    2021-02-28 15:39:37
    Overview一个在生产环境里运行...一般来说日志分为两种:业务日志和异常日志,使用日志我们希望能达到以下目标:对程序运行情况的记录和监控;在必要时可详细了解程序内部的运行状态;对系统性能的影响尽量小;Java...
  • Python最简编码规范

    千次阅读 2021-02-04 08:31:58
    原标题:Python最简编码规范来源:机器学习算法与Python学习ID:guodongwei19910、前言本文是阅读《Python Coding Rule》之后总结的最为精华及简单的编码规范,根据每个人不同喜好有些地方会有不同的选择,我只是做了...
  • 最近在看MySQL相关的内容,整理如下规范,作为一名刚刚学习MySQL的菜鸟,整理的内容非常的基础,中间可能涉及到有错误的地方,欢迎批评指正,看到有错误的地方期望看官留言。数据库环境dev:开发环境,开发可读写,...
  • Dubbo服务规范

    2021-03-04 10:37:10
    1前言:在公司使用dubbo框架的一些约定,记录一下,后期其他项目使用直接借鉴,嘿嘿! 2项目命名规则 2.1 服务消费方:业务名-api,如图 2.2 服务生产方:业务名-server ,如图: 3 项目架构 3.1.业务模型设计分为...
  • 前端开发规范详解

    千次阅读 2021-01-21 14:46:46
    如果开发团队就一个人的话,那么自己写的代码就是规范,随着公司业务的扩展,团队不断壮大,这时候就要开始考虑协作和编码规范问题了。 一个人走的更快,一群人可以走的更远,前提是统一的策略,还要不断地反省和...
  • 数据库规范化技巧

    2021-01-28 00:29:22
    数据库规范化技巧Luke ChungFMS 总裁2002年9月适用于:Microsoft® Access摘要:本文为开发人员提供了一些技巧,使用这些技巧可以在设计 Access 表时避免某些问题。本文适用于 Microsoft Access 数据库 (.mdb) 和 ...
  • AMD、CMD规范详解

    2021-04-26 19:57:37
    AMD规范 1.1什么是AMD规范 Asynchronous Module Definition,用白话文讲就是 异步模块定义,对于 JSer 来说,...1.2用法 AMD规范定义了一个自由变量或者说是全局变量 define 的函数。 define( id?, dependencies?, fac
  • 一,Python与其他语言最大区别没有{}来区分代码块或者控制区域,全部是通过缩进来实现的。其中缩进的空白数量可变,但是所有代码块语句必须包含相同的缩进空白数量,这个必须严格执行。语句中包含[] ,{}或者是()括号...
  • Java代码规范

    2021-02-28 15:10:02
    Java代码规范命名规范类名采用大驼峰,一般为名词,如 ArrayList方法名采用小驼峰,一般为动词,如 ArrayList的isEmpty()变量采用小驼峰常量的字母全部大写,单词之间用下划线连接包名统一使用小写,点分隔符之间有...
  • java开发规范

    2021-03-01 11:03:52
    hbh开发规范文档一:目的使本组织能以标准的,规范的方式设计...二:代码组织与风格1:长度:为便于阅读和理解,单个函数的有效代码长度当尽量在100行以内(不包括注行),当功能模块过大时往往采用使用子函数将相应的...
  • Eric Evans 和OO之父 Martin Fowler定义的规范(Specification也称规格模式)模式article越来越受到广泛应用,本文介绍如何使用JavaEE 持久层规范JPA实现规格模式,其实现思想也适合其他持久层框架。案例源码见GitHub...
  • Go语言编码规范

    2021-07-21 23:23:41
    "编码规范(Go)"规范为日常Go项目开发提供一个统一的规范指导, 方便团队形成统一的代码风格, 提高代码可读性, 规范性和一致性. 同时作为CR的有效指导工具, 如果有变更的, 需要补充的, 可以在文档中(文档下)添加评论...
  • vue项目前端规范

    2021-03-26 14:45:18
    前端 vue 开发规范笔记 命名规范组件method方法命名views下文件命名props 命名目录文件夹及子文件规范vue文件...跟需求的内容相关 复数的时候需要加s 常量 方法:全部大写 规范:使用大写字母和下划线来组合命名,下划...
  • Oracle 12C使用规范标准

    2021-05-01 03:32:39
    1概要1.1目的本规范简要说明了Oracle 12C Inmemory和Multitenant的使用范围及功能介绍。1.2范围本文档适用于Oracle 12C数据库。2 In Memory2.1基本介绍In-Memory列存储组件,为12c中SGA的可选组件。可以用来存储表、...
  • Java编码规范

    2021-03-16 03:12:59
    1 注释规范1.1 注释的三...注释若干行,并可写入javadoc文档1.2 类、类属性、类方法的注释必须使用Javadoc规范使用/**内容*/格式,不得使用// xxx方式。说明:在IDE编辑窗口中,Javadoc方式会提示相关注释,生成J...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 843,979
精华内容 337,591
关键字:

其他其它规范用法