丝袜玉足

天下好丝袜玉足，左证以往的责任教会，好多时候数据库出问题，齐是莫得范例使用数据库导致的。

比如条款字段莫得添加合适索招引致查询渐渐，从而影响到用户体验；

还有即是什么齐往Redis里存放，导致本钱浪费。

等等。

是以，制定里面的数据库范例，显得尤为进军。

在我制作的DBA体系课中，就有一部分是模拟DBA去爱戴一套电商网站的数据库（MySQL、Redis、MongoDB），包括高可用环境准备、日常爱戴、备份、监控、自动化、迁徙等。

诚然，也包括这套电商网站数据库的开导范例。

这篇著述就来共享一下。

MySQL

1 定名范例

家庭伦理小说

1.1、表名提议使用有业务道理的英文词汇，必要时可加数字和下划线，并以英翰墨母开端；

比如商品表products，要是有多个表，可以写成products_001

1.2、库、表、字段全部摄取小写；

胡闹因为大小写问题找不到表大约弄错表。

1.3、幸免用MySQL的保留字；

对于哪些是MySQL的保留字，可以参考官方文档：

https://dev.mysql.com/doc/refman/8.0/en/keywords.html

1.4、定名（包括表名、列名）辞谢首先 30 个字符；

一张表，表名四五十个字符，比如：

online_store_product_information_table

真没必要啊，爱戴和处置也挺窒碍的。

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齐存在精度亏本的问题，很可能在比较值的时候，取得不正确的驱散。

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；

2.14、示意例：

CREATE TABLE student_info (`id` INT NOT NULL AUTO_INCREMENT COMMENT '主键'，`stu_name` VARCHAR(10) NOT NULL DEFAULT '' COMMENT '姓名'，`stu_class` VARCHAR(10) NOT NULL DEFAULT '' COMMENT '班级'，`stu_num` INT NOT NULL DEFAULT '0' COMMENT '学号'，`stu_score` SMALLINT UNSIGNED NOT NULL DEFAULT '0' COMMENT '总分'，`tuition` DECIMAL(5， 2) NOT NULL DEFAULT '0' COMMENT '膏火'，`phone_number` VARCHAR(20) NOT NULL DEFAULT '0' COMMENT '电话号码'，`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '记载创建时刻'，`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记载更新时刻'，`status` TINYINT NOT NULL DEFAULT '1' COMMENT '1代表记载有用，0代表记载无效'，PRIMARY KEY (`id`)，UNIQUE KEY uniq_stu_num (`stu_num`)，KEY idx_stu_score (`stu_score`)，KEY idx_update_time_tuition (`update_time`， `tuition`)) ENGINE = INNODB charset = utf8mb4 COMMENT '学生信息表';

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合成一次操作；

比如加三个字段，有些东谈主会实践三条语句：

ALTER TABLE your_table_name ADD COLUMN new_column1 INT;ALTER TABLE your_table_name ADD COLUMN new_column2 INT;ALTER TABLE your_table_name ADD COLUMN new_column3 INT;

本色一条语句可以实践：

ALTER TABLE your_table_nameADD COLUMN new_column1 INT，ADD COLUMN new_column2 INT，ADD COLUMN new_column3 INT;

4.4、不在业务岑岭期批量更新、查询数据库；

幸免影响宽泛业务

4.5、删除表大约库要求尽量先rename，不雅察几天，详情对业务没影响，再drop。

这么，胡闹一些咱们不知谈的业务还在使用这些库大约表的情况。

Redis范例

1 键值对的提议

1.1、key名提议；

提议key name狡计：业务名:表名:id

比如：

set school:student:1 martin

要求：不包含特地字符

1.2、string 类型截止在10 KB以内，hash、list、set、zset元素个数不要首先5000；

1.3、截止key的落伍时刻；

使用expire诞生key的落伍时刻，胡闹Redis中残留多数松手的数据，Redis不是垃圾桶，内存很贵的。

诚然，吞并个Redis里面的key落伍时刻也尽量错开，荟萃落伍，可能会导致缓存雪崩

2 禁用一些高危高歌

2.1、危境高歌径直禁用；

比如：

keys *flushallflushdb

等。

诚然，可以推敲径直在树立中禁用这些高歌

在树立文献中加多

rename-command flushall ''rename-command flushdb ''rename-command keys ''

大约创建一个ACL用户

ACL SETUSER martin on >martin123 +@all -@dangerous ~*

明白

+@all 所有的高歌

-@dangerous 示意禁用危境高歌

~* 示意授权所有的key

dangerous危境高歌包括：FLUSHALL， MIGRATE， RESTORE， SORT， KEYS， CLIENT， DEBUG， INFO， CONFIG， SAVE， REPLICAOF

2.2、尽量不全量操作Hash、Set等麇辘集构；

要是单个麇辘集构里有多个元素，单次操作过多的元素，恶果可能会很低，况且可能把网卡流量打满。

3 狡计范例

3.1、不同场景合理使用不同的数据结构；

比如名次榜可以使用zset；

地舆位置，可以用GEO；

部队可以用list；

计数器可以用string类型。

3.2、不要将所有的数据齐放Redis里面；

提议Redis只作念热数据缓存，冷数据放到MySQL大约其他数据库里。

一方面，内存是比较贵的，可以省俭本钱；

另一方面，放到干系型数据库中，数据很难丢失。

MongoDB的范例

1 库名

1.1、库名全小写；

1.2、不可包括除_之外其他的一些特地字符；

1.3、库名不首先30个字符。

2 麇集名命范例

2.1、使用小写字母；

2.2、不可包括除_之外其他的一些特地字符；

2.3、不可以system.开端，因为这种是系统表；

2.4、提议是有业务道理的单词组合，用下划线汇聚，比如：shipping_orders；

2.5、麇集名不首先30个字符串。

3 文档范例

3.1、文档的键值不可包括除_之外其他的一些特地字符；

3.2、辞谢使用_id，因为这个是默许的主键；

3.3、一个麇荟萃尽可能使用疏通类型的文档；

3.4、时时看成条款的字段添加索引。

4 语句

4.1、单条语句幸免查询过多的数据；

4.2、单个文档的大小提议不首先16M；

4.3、禁用不带条款的查询和更新；

4.4、每次查询的文档数提议不首先500。

5 清空集群提议

提议用drop()，而不是deleteMany()。

好的，数据库范例就聊到这里，要是认为著述还可以，襄助点个赞哈

图片

本站仅提供存储处事，所有内容均由用户发布，如发现存害或侵权内容，请点击举报。