MySQL 编码规范

最新推荐文章于 2023-08-29 14:08:45 发布

青风微凉

最新推荐文章于 2023-08-29 14:08:45 发布

阅读量478

点赞数

分类专栏： DB数据库理论源码和最佳实践文章标签：数据库 mysql 编码规范

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.youkuaiyun.com/u010541670/article/details/118491691

版权

DB数据库理论源码和最佳实践专栏收录该内容

7 篇文章

订阅专栏

MySQL 编码规范

文章目录

MySQL 编码规范

1 前言

本编码规范适用于以 MySQL 数据库为主体的开发项目中。

本编码规范基于 5.6.x 和 5.7.x 版本。

一般而言，数据库规范是系统规范的基石。统一的编码规范，能够提升系统的可读性，便于理解和避免出错，可以有效的提高开发、维护和二次开发的效率。

MySQL 编码规范包含：命名规范、设计规范、书写规范、语法规范。

2 命名规范

数据库相关命名包含但不限于：数据库名、表名、字段名、索引名。

良好的命名规范可以让数据库使用人员：程序设计人员、开发人员、运维人员、数据库管理员等可以直观的辨识和理解。

【强制】整体：命名不得使用数据库（MySQL、Oracle等）、系统开发语言（Java、JS、HTML等）的保留关键字。

反例：index / desc / static / return
【强制】整体：命名必须使用小写英文字母 a-z 开头，由小写英文字母 a-z 和数字 0-9 组成，使用 _ 分割，禁止超过 30 个字符。

说明：1）正确的英文拼写和语法可以让阅读者易于理解，避免歧义。

2）建议使用英文名词，避免纯拼音的命名方式。

3）单词超长时，可以使用英文缩写。例如，可将 corporation_id 缩写为 corp_id。

正例：app_code / task_name / file_type

反例：pingfen [评分] / promotion_dazhe [打折]
【强制】表命名规范：表的命名需由3部分组成：项目标识符 + 模块缩写 + 功能缩写

说明：通常，模块缩写 即是 领域缩写，服务端实体类命名可省略 项目标识符 。

正例：gclp_user_info / grmp_task_info / grmp_task_info_detail / grmp_task_process_record
【强制】字段命名规范：保证字段的名称和类型的一致性，保证字段名称全局唯一。

说明：1）同一业务含义的字段在不同表中的字段名称和数据类型需保持一致。

2）同一字段名称，在库内只能唯一表示一种业务含义。

3）不建议所有表的主键都命名为 id，建议使用表名 + id 的格式。

正例：user_info_id / task_info_id / task_info_detail_id
【强制】字段命名规范：布尔类型字段命名为 is + 描述 ，可枚举的状态类型字段命名为 描述 + state，描述性的状态类型字段命名为 描述 + status

说明：此处没有对错之分，统一的命名方式可以让使用者见名知意。

正例：isDelete / isPay / IsEnabled

反例：promotion_dazhe [打折] / pingfen [评分]
【强制】分区命名规范：普通场景下不建议进行表分区。关于时间分区：p_yyyy / p_yyyymm / p_yyyymmdd
【强制】分表命名规范：

1）使用时间分区：_yyyy / _yyyymm / _yyyymmdd

2）使用hash分区：例如，将数据按 hash 取 128 份，从 000-127 命名。
【强制】索引命名规范：

1）普通索引使用 idx_表名_列名，若过长则可使用缩写。例如，idx_task_info_task_id。

2）唯一索引使用 unq_表名_列名

3 设计规范

3.1 数据库设计规范

【强制】普通场景下使用 INNODB 存储引擎；读写比率 <1% ，考虑使用 MYISAM 存储引擎；其他存储引擎请在架构师的建议下使用。
【强制】禁止使用存储过程、视图、函数、触发器、外键等包含业务逻辑处理的 MySQL功能，特殊场景请在架构师的建议下使用。
【强制】UUID()，USER() 这样的 MySQL INSIDE 函数对复制不友好，可能导致主备数据不一致，不允许使用。
【强制】必须采用 UTF8 编码。

3.2 数据表设计规范

【强制】所有表必须设置主键：主键使用BIGINT类型，使用程序生成分布式主键插入，保证全局唯一且趋势有序。
【强制】所有表均需包含两个日期字段： crt_time(创建日期)，upd_time(修改日期)且非空，对表的记录进行插入和更新时，必须相应进行设值。
【强制】由于 MYSQL 表 DDL 维护成本很高，所以关键业务表必须要有冗余字段。

说明：冗余字段可以使用 value1, value2, value3 等。
【强制】当字段的类型为枚举型或布尔型时，统一使用 char(1) 类型。
【强制】一张表中，单行 varchar 类型字段的长度总和不能超过 65535 。超大字段应使用 TEXT/LONGTEXT 类型，超多字段应进行分表。
【强制】当表的字段数非常多时，出于性能和维护考虑，可以将原表分成两张表：一张作为条件查询表，一张作为详细内容表。

3.3 索引设计规范

4 语法规范

【强制】禁止使用 select * 语句，禁止没有 where 的 SQL 语句。

说明：出于性能、安全、成本考虑：

1）提高性能、节省成本：避免返回多余数据，增加服务器、网络和客户端压力。

2）数据安全：避免造成不必要的数据泄露。
【强制】禁止使用隐式数据类型转换。

说明：例如：在值比较的语句中，避免不同数据类型的值的直接比较。
【建议】使用 union all 替代 union 语句。

说明：union 语句会将结果集进行排序去重，效率较低。
【建议】避免使用 <> 语句。

说明：<> 语句无法使用索引。

正例：使用其他方式处理逻辑。例如：

1）数字类型：将 age <> 0 改为 age > 0 or age < 0

2）字符类型：将 name <> ‘’ 改为 name > ‘’ or name < ‘’
【建议】确定只有1条查询结果时，建议使用 limit 1，有效避免全表扫描。
【建议】大量数据下，建议使用 exists 替代 in
【建议】建议使用 not exist 替代 not in

说明：not in 语句无法使用索引。
【建议】避免使用 is null 和 is not null 等不使用索引的语句。

正例：使用其他方式逻辑处理。例如：

1）数字类型：判断是否大于0

2）字符类型：设置默认值 ‘’，判断是否 > ‘’
【建议】避免使用复杂的 SQL 语句。

说明：应思考表的设计是否合理，以及从需求层面避免。

无法避免的场景下，可以考虑使用临时表减少复杂度。