MYSQL开发规范

一 数据库对象命名规范

1. 数据库对象

  • 命名规范的对象是指数据库SCHEMA,表Table,索引Index, 约束Constraints等的命名规定

2. 数据库对象命名原则

  • (1) 命名使用具有意义的英文词汇,词汇中间以下划线分割
  • (2) 命名只能使用英文字母,数字,下划线
  • (3) 避免使用mysql的保留字 如 call,have,group等
  • (4) 所有数据库对象使用小写字母

3. 数据库命名规范

  • (1) 数据库名不能超过30个字符
  • (2) 数据库命名必须为项目英文名称或有意义的简写
  • (3) 数据库创建时必须添加默认字符集和校对规则子句,默认字符集UTF-8或者utf8mb4
  • (4) 命名应该小写

4.表命名规范

  • (1) 同一个模块的表尽可能使用相同的前缀,表名尽可能表达相关含义
  • (2) 多个单词 用 下划线 _ 分割
  • (3) 普通表名以 t_开头,表示为table 命名规则 为 t_模块名(或者有意义的简写)
  • (4) 表名不能超过30个字符
  • (5) 临时表(运营、开发或数据库人员临时用作数据采集的中间表)命名规则:加上tmp前缀和8位时间后缀(tmp_user_20180928)
  • (6) 备份表(DBA备份用作保存历史数据的中间表) 命名规则:加上bak前缀和8位时间后缀(bak_user_20180928)
  • (7) 命名应该小写

5. 字段命名规范

  • (1) 字段名命名需要表示其实际的含义的英文单词或者简写,单词之间用 下划线 _ 进行连接
  • (2) 各表之间相同意义的字段必须同名
  • (3) 字段名不能超过30个字符

二 数据库对象设计规范

1. 存储引擎的选择

  • (1) 存储引擎的选择------ 无特殊需求,必须使用innoDB存储引擎
  • (2) 字符集的选择------- 无特殊需求,必须使用utf-8或者 utf8mb4

2. 表设计规范

  • (1) 不同应用之间所对应数据库表之间的关联尽可能减少,不允许使用外键对表之间进行关联,确保组件对应表之间的独立性,为系统或表结构的重构提供可持续性。
  • (2) 表设计的角度不应该针对整个系统进行数据库设计,而应该根据系统架构中组件划分,针对每个组件所处理的业务进行数据库设计
  • (3) 表必须要有PK(不然innoDB存储会给你自动建一个隐藏的主键列)
  • (4) 一个字段只表示一个含义
  • (5) 表不应该有重复列
  • (6) 禁止使用复杂数据类型(数组、自定义)
  • (7) 需要join的字段,数据类型必须保持一致,避免隐式转换
  • (8) 设计至少满足数据库的第三范式,尽量减少冗余的字段。除了特殊场景允许反范式的设计,但是必须需要对冗余的字段设计给出解释。
  • (9) TEXT字段必须放在独立的表中,用PK与主键关联。尽量避免使用TEXT,BLOB类型
  • (10) 单表字段不要太多,最好控制在50个左右
  • (11) MySQL在处理大表时,性能就开始明显降低,所以建议单表物理大小限制在16GB,表中数据控制在2000W内
  • (12) 如果数据量或数据增长在前期规划时就较大,那么在设计评审时就应加入分表策略

3. 字段设计规范

  • (1) INT: 如无特殊需要,存放整型数字使用UNSIGNED INT型。整型字段后的数字代表显示长度
  • (2) DATETIME: 所有需要精确到时间(时分秒)的字段均使用DATETIME,不要使用TIMESTAMP类型
  • (3) VARCHAR: 所有动态长度字符串 全部使用VARCHAR类型,类似于状态等有限类别的字段,也使用可以比较明显表示出实际意义的字符串,而不应该使用INT之类的数字来代替;VARCHAR(N),N表示的是字符数而不是字节数。比如VARCHAR(255),可以最大可存储255个字符(字符包括英文字母,汉字,特殊字符等)。但N应尽可能小,因为MySQL一个表中所有的VARCHAR字段最大长度是65535个字节,且存储字符个数由所选字符集决定。如UTF8存储一个字符最大要3个字节,那么varchar在存放占用3个字节长度的字符时不应超过21845个字符。同时,在进行排序和创建临时表一类的内存操作时,会使用N的长度申请内存。(如无特殊需要,原则上单个varchar型字段不允许超过255个字符)
  • (4) TEXT: 仅仅当字符数量可能超过20000个的时候,才可以使用TEXT类型来存放字符类数据,因为所有MySQL数据库都会使用UTF8字符集。所有使用TEXT类型的字段必须和原表进行分拆,与原表主键单独组成另外一个表进行存放。如无特殊需要,严禁开发人员使用MEDIUMTEXT、TEXT、LONGTEXT类型
  •   对于精确浮点型数据存储,需要使用DECIMAL,严禁使用FLOAT和DOUBLE
      如无特殊需要,严禁开发人员使用BLOB类型
      如无特殊需要,字段建议使用NOT NULL属性,可用默认值代替NULL
      自增字段类型必须是整型且必须为UNSIGNED,推荐类型为INT或BIGINT,并且自增字段必须是主键或者主键的一部分
      不要将业务设置为主键
    

4. 索引设计规范

  • (1) 索引必须创建在索引选择性选择性较高的列上,选择性的计算方式为: select count(distinct(col_name))/count(*) from tb_name;如果结果小于0.2,则不建议在此列上创建索引,否则大概率会拖慢SQL执行
  • (2) 组合索引的首字段,必须在where条件中,对于确定需要组成组合索引的多个字段,建议将选择性高的字段靠前放
  • (3) 禁止使用外键
  • (4) Text类型字段如果需要创建索引,必须使用前缀索引
  • (5) 单张表的索引数量理论上应控制在5个以内。经常有大批量插入、更新操作表,应尽量少建索引
  • (6) ORDER BY,GROUP BY,DISTINCT的字段需要添加在索引的后面,形成覆盖索引
  • (7) 尽量使用Btree索引,不要使用其它类型索引

5. 约束设计规范

  • (1) PK应该是有序并且无意义的,尽量由开发人员自定义,且尽可能短,使用自增序列
  • (2) 表中除PK以外,还存在唯一性约束的,可以在数据库中创建以“uidx_”作为前缀的唯一约束索引
  • (3) PK字段不允许更新
  • (4) 禁止创建外键约束,外键约束由应用控制
  • (5) 如无特殊需要,所有字段必须添加非空约束,即not null
  • (6) 如无特殊需要,所有字段必须有默认值

6. SQL编写规范

  • (1) 尽量避免使用select *,join语句使用select *可能导致只需要访问索引即可完成的查询还需要回表取数
  • (2) 严禁使用select * from table而不加任何where条件
  • (3) MySQL中的text类型字段存储的时候不是和由其他普通字段类型的字段组成的记录存放在一起,而且读取效率本身也不如普通字段块。如果不需要取回text字段,又使用了select *,会让完成相同功能的sql所消耗的io量大很多,而且增加部分的io效率也更低下
  • (4) 在取出字段上可以使用相关函数,但应尽可能避免出现now(),rand(),sysdate(),current_user()等不确定结果的函数,在Where条件中的过滤条件字段上严禁使用任何函数,包括数据类型转换函数
  • (5) 所有连接的SQL必须使用Join … On …方式进行连接,而不允许直接通过普通的Where条件关联方式。外连接的SQL语句,可以使用Left Join On的Join方式,且所有外连接一律写成Left Join,而不要使用Right Join
  • (6) 分页查询语句全部都需要带有排序条件,除非应用方明确要求不要使用任何排序来随机展示数据
  • (7) WHERE条件中严禁在索引列上进行数学运算或函数运算
  • (8) 用in()/union替换or,并注意in的个数小于30
  • (9) 严禁使用%前缀进行模糊前缀查询:如:select id,val from table where val like ‘%name’;可以使用%模糊后缀查询如:select id,val from table where val like ‘name%’
  • (10) 严禁使用INSERT ON DUPLICATE KEY UPDATE、REPLACE INTO、INSERT IGNORE
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 196,264评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,549评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,389评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,616评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,461评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,351评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,776评论 3 387
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,414评论 0 255
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,722评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,760评论 2 314
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,537评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,381评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,787评论 3 300
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,030评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,304评论 1 252
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,734评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,943评论 2 336