ToB企服应用市场:ToB评测及商务社交产业平台

标题: DataBase 的一些规范？ [打印本页]

作者: 罪恶克星 时间: 2024-8-13 10:04
标题: DataBase 的一些规范？
1定名规范
1.1表名要有业务意义
1.2制止利用关键字 mysql关键字
1.3库、表、字段全部接纳小写
1.4定名（包括表名、列名）禁止超过 30 个字符
1.5临时库、表名必须以 tmp 为前缀，并以日期为后缀；如：tmp_shop_info_20240101；
1.6备份库、表必须以 bak 为前缀，并以日期为后缀；如：bak_shop_info_20240101；
1.7索引定名：非唯一索引必须按照“idx字段名称”进行定名；唯一索引必须按照“uniq字段名称”进行定名。
2 计划规范
2.1、主键：
无特殊要求，主键均按如下语句来设置：

`id` INT NOT NULL AUTO_INCREMENT COMMENT '主键',

复制代码

2.2如无特殊要求，建议都利用 InnoDB 引擎；
2.3字符集默认利用utf8mb4字符集；
数据排序规则利用utf8mb4_general_ci；
原因：utf8mb4为万国码，无乱码风险；与utf8编码相比，utf8mb4能支持Emoji心情。
2.4所有表、字段都需要增加comment来形貌此表、字段所表现的含义；
好比：

data_status TINYINT NOT NULL DEFAULT 1 COMMENT ‘1代表记录有效，0代表记录无效’。

复制代码

2.5、如无阐明，建议表包罗create_time和update_time字段，即表必须包罗记载创建时间和修改时间的字段；
2.6、用尽量少的存储空间来存放一个字段的数据：
能用 int 的就不用 char 大概 varchar；
能用 tinyint 的就不用 int；
利用 UNSIGNED 存储非负数值；
只存储年利用 YEAR 类型；
只存储日期利用 DATE 类型。
2.7、存储精确浮点数必须利用DECIMAL替代FLOAT和DOUBLE；
原因：在存储的时间，FLOAT和DOUBLE都存在精度损失的问题，很大概在比较值的时间，得到不正确的结果。

-- value列的数据类型为DECIMAL，其中10表示总共有10位数字(加上小数点后2位后10位)，2表示小数点后保留2位。这样可以确保浮点数的精确存储和计算。
CREATE TABLE example (
id INT PRIMARY KEY,
value DECIMAL(10, 2)
);

复制代码

进行浮点数生存时float，double 和 decimal 的区别：

float 4字节
double 8字节
decimal

小：DECIMAL(M, D)，此中M小于等于9。在这种情况下，DECIMAL(M, D)数据类型将利用4个字节进行存储。
中：DECIMAL(M, D)，此中M小于等于18，大于9。在这种情况下，DECIMAL(M, D)数据类型将利用8个字节进行存储。
大：DECIMAL(M, D)，此中M小于等于65，大于18。在这种情况下，DECIMAL(M, D)数据类型将利用16个字节进行存储。

2.8、尽大概不利用 TEXT、BLOB 类型；
原因：会浪费更多的磁盘和内存空间，非必要的大量大字段查询会淘汰掉热数据，导致内存命中率急剧低沉，影响数据库性能。
假如实在有某个字段过长需要利用 TEXT、BLOB 类型，则建议独立出来一张表，用主键来对应，制止影响原表的查询效率。
2.9、禁止在数据库中存储明文密码；
2.10、索引计划规范：
a、需要添加索引的字段
UPDATE、DELETE 语句的 WHERE 条件列；
ORDER BY、GROUP BY、DISTINCT 的字段
JOIN 语句的关联字段
b、单表索引建议控制在 5 个以内；
c、得当配置联合索引；
好比方便查询能走覆盖索引，大概几个字段同时作为条件的概率很高时，可以增加合适的联合索引。
d、业务上具有唯一性的字段，添加成唯一索引；
遇到过频频字段在业务场景上要求唯一，但是该字段在数据库里的数据却出现了重复。因此在代码层考虑外，还需要在 MySQL 上的对应字段添加唯一索引。
e、在 varchar 字段上创建索引时，建议根据实际文本区分度指定索引长度；
原因：可以低沉索引所占用的空间，并且很多时间，好比字符串基本是长度大于 20，但是只要创建长度为 20 的索引，就已经有很高的区分度了。可以利用 count(distinct left(列名, 索引长度))/count(*) 的区分度来确定。
f、索引禁忌：
不在低基数列上创建索引，例如：性别字段。
不在索引列进行数学运算和函数运算
2.11、不建议利用外键；
原因：外键会导致表与表之间耦合，update 与 delete 操纵都会涉及相干联的表，很影响sql 的执行效率，甚至会造成死锁。高并发情况下容易造成数据库性能降落。
2.12、禁止利用存储过程、视图、触发器、Event ；
原因：高并发的情况下，这些功能很大概将数据库拖死，业务逻辑放到服务层具备更好的扩展性。
2.13、单表列数量建议小于30；

3 SQL语句规范
3.1、制止隐式转换；
隐式转换将利用不了索引。
3.2、尽量不利用select *,只select需要的字段；
原因：读取不需要的列会增加CPU、IO、NET消耗，并且不能有效的利用覆盖索引。利用SELECT *容易在增加大概删除字段后导致步伐报错。
3.3、禁止代码中利用INSERT INTO t_xxx VALUES (xxx)，必须显示指定插入的列名；
原因：容易在增加大概删除字段后导致步伐报错。
3.4、尽量不利用负向查询；
好比 not in/like。
3.5、禁止以%开头的模糊查询；
原因：利用不了索引
3.6、禁止单条SQL语句同时更新多个表；
同时更新多个表的SQL语句大概会变得非常复杂，难以理解和维护。
当出现问题时，排查和修复错误也会更加困难。
3.7、统计记载数利用select count(*)
而不是select count(primary_key)大概select count(普通字段名)；
原因：大概会导致走的索引不是最优的大概导致统计数字不准确。
3.8、建议将子查询转换为关联查询；
关联查询通常比子查询执行速度更快。
子查询会在内部执行多次，而关联查询会以更有效的方式一次性检索所需的数据。这可以减少数据库的负载，提高查询性能。
3.9、建议应用步伐捕捉SQL非常，并有相应处理；
这样，可以大大提升堕落时的排查速度
3.10、SQL中不建议利用 sleep()，如特殊需求需要用到sleep()，请提前告知DBA；
大概占用数据库毗连和资源，并且大概会在高负载的情况下导致性能降落
4 举动规范
4.1、批量导入、导出数据必须提前关照DBA协助观察；
操纵前，可以一起看一下语句是否可以优化，另有就是DBA可以临时关闭一些定时任务（好比备份），方便加快批量导入导出。
另外导入导出过程，可以让DBA关注数据库性能。
4.2、有大概导致MySQL QPS上升的运动，提前告知DBA；
DBA可以评估数据库是否会到瓶颈，大概有些细节是否可以再调整；运动期间，DBA也会观察数据库监控，看数据库是否存在性能问题。
4.3、同一张表的多个alter合成一次操纵；
4.4、不在业务高峰期批量更新、查询数据库；
制止影响正常业务
4.5、删除表大概库要求尽量先rename，观察几天，确定对业务没影响，再drop。
这样，防止一些我们不知道的业务还在利用这些库大概表的情况。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)