咱们来自字节跳动飞书商业运用研发部(Lark Business Applications)，现在咱们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了工作区域。咱们关注的产品领域首要在企业经验管理软件上，包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域体系，也包括飞书审批、OA、法务、财务、收购、差旅与报销等体系。欢迎各位参加咱们。
本文作者：飞书商业运用研发部 严厚宗
欢迎咱们关注飞书技能，每周守时更新飞书技能团队技能干货内容，想看什么内容，欢迎咱们谈论区留言~
前语 Schema 概念
schema在数据库中表明的是数据库方针调集，它包括了各种方针，比如：表，视图，存储进程，索引等等。
一般一个用户对应一个调集，所认为区别不同调集就需给不同调集起名。用户的schema名就相当于用户名，并作为该用户缺省schema。所以schema调集看上去像用户名。
例如当咱们拜访一个数据表时，若该表没有指明归于哪个schema，体系就会主动加上缺省的schema。
真实影响功用最大的部分是在规划中就现已产生了的，后期的优化许多时分所能够带来的改进都仅仅在处理前期规划所遗留下来的一些问题罢了，并且能够处理的问题一般也比较有限。
一、高效的模型规划
最标准的就必定是最合理的吗？
在数据库 Schema 规划理论方面，一向有一个被咱们奉为“葵花宝典”的标准化范式理论。经过范式理论所规划的数据库 Schema 逻辑明晰，联系明晰，扩展便利，就连存储的数据量也做到了尽或许的少，特别是当范式级别较高的时分，几乎找不到任何的冗余数据。在许多人眼里，数据库 Schema 满意的范式级别越高则该 Schema 规划的越优异。
可是，许多人疏忽了一点，那便是产生该理论的时期和出发点。联系性数据库的标准化范式理论诞生于上世纪七十年代初，最根本的意图是让数据库中尽量的去除数据的冗余，坚持数据的共同，使数据的修正简略。
实践上，尽量去除数据的冗余不仅仅是为了让咱们查询相同的数据量的时分能够多返回几条记载，还有一个很重要的原因便是在其时的那个年代，数据的存储空间是及其昂贵的，并且存储设备的容量也都十分的小，这一点在硬件存储设备发展如此敏捷的现在，空间巨细现已不再是太大的问题了。
而范式理论中的数据共同性和使数据修正简略确保首要是依靠添在数据库中添加各种束缚来确保，而各种束缚关于数据库来说自身其实便是一个十分耗费资源的工作。
所以，关于依据功用的数据库 Schema 规划，咱们并不能彻底以标准化范式理论来作为仅有的指导。在规划进程中，应该从实践需求出发，以功用提升为根本方针来展开规划工作，许多时分为了尽或许进步功用，咱们有必要做反范式规划。
①适度冗余 – 让 Query 尽两削减 Join
熟悉 MySQL 的优化器的读者或许清楚，MySQL 的优化器尽管号称运用了新一代的优化器技能完结的十分优异，可是由于现在 MySQL 所收集的数据核算信息还不是特其他多，所以起表现并不是特其他让人满意，也并非如 MySQL 官方所宣传的那样智能。尽管处理一般 Join 的时分一般都能比较智能的得到比较高效的履行计划，可是当遇到一些自查询或许较为杂乱的 Join 的时分，很简略呈现不太合理的履行计划，不少时分对各表的拜访顺序挑选的并不适宜，造成杂乱 Query 的全体履行功率低下。
所以，为了让咱们的 Query 履行计划尽或许的最优化，最直接有用的方法便是尽量削减 Join，而要削减 Join，咱们就不可避免的需求经过表字段的冗余来完结。
计划一 group_message 表中仅保存了发布信息者的 ID 信息，而经过冗余优化之后的 group_message 表中添加了发布信息者的 nick_name 信息存为 author。
优化前完结列表功用的 Query 和履行计划（group_message_bad 是优化前的表，优化后为 group_message 表）：
sky@localhost : example 09:13:41> explain
-> SELECT t.id, t.subject,user.id, user.nick_name
-> FROM (
-> SELECT id, user_id, subject
-> FROM group_message
-> WHERE group_id = 1-> ORDER BY gmt_modified DESC LIMIT 1,10-> ) t, user-> WHERE t.user_id = user.id\G
* 1. row *
id: 1
select_type: PRIMARYtable: <derived2>
type: system
possible_keys: NULL
key: NULL
key_len: NULLref: NULLrows: 1
Extra:
* 2. row *
id: 1
select_type: PRIMARYtable: user
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4ref: const
rows: 1
Extra:
* 3. row *
id: 2
select_type: DERIVED
table: group_message
type: ALL
possible_keys: group_message_gid_ind
key: group_message_gid_ind
key_len: 4ref:
rows: 1
Extra: Using filesort
复制代码
优化后完结列表功用的 Query 和履行计划：
sky@localhost : example 09:14:06> explain
-> SELECT t.id, t.subject, t.user_id, t.author
-> FROM group_message t
-> WHERE group_id = 1-> ORDER BY gmt_modified DESC LIMIT 1,10\G
* 1. row *
id: 1
select_type: SIMPLE
table: t
type: ref
possible_keys: group_message_gid_ind
key: group_message_gid_ind
key_len: 4ref: const
rows: 1
Extra: Using where; Using filesort
复制代码
从优化前和优化后的履行计划能够看出两者的不同十分大的，优化前有必要检索 2 个表（group_message 和 user）才干得到成果，而优化后只需求检索 group_message 一个表就能够完结，由于咱们将“作者”信息冗余到了 group_message。
从数据库范式理论来看，这样的规划是不合理的。由于或许造成 user 表和 group_message 表中的用户昵称数据不共同。每次更新用户昵称的时分，都需求更新两个表的数据，为了尽或许让两者数据确保共同，运用程序中需求处理更多的逻辑。可是，从功用视点来看的话，这种冗余是十分有价值的，尽管咱们的数据更新逻辑杂乱了，可是咱们在考虑更新带来的附加本钱的时分，还应该考虑咱们究竟会有多少更新产生在用户昵称上面呢？咱们需求考虑的是一个体系的全体功用，而不是体系中单个行为的功用。就像示例中的昵称数据，尽管更新的本钱添加了，可是查询的功率进步了，并且产生示例中查询的频率要远大于更新的频率，经过少部分操作的本钱投入换取更大的功用收获，实践上是咱们体系功用优化中常常运用的战略。
在大部分运用体系中，类似于上面示例中的这种查询频频可是更新较少的数据十分十分多，许多时分假如咱们一味的追求范式化理论的 Schema 规划在高功用要求的体系中是十分不适宜的。我个人认为，数据库的标准化理论其实质是在概念上的单一化，尽管标准后的数据库中的表一般都较小，使表中相关列最少。这尽管或许在某些情况下增强了数据库的可保护性，但在体系要完结一些数据的查询检索时，或许要用杂乱的 Join 才干完结，这势必会造成查询检索的功用低下。假如咱们经过拆分 Join，经过多次简略的查询来在运用中完结 Join 逻辑，那所带来的网络开支将会是十分巨大的。
②大字段笔直分拆 – summary 表优化
实践上，在上面的示例中咱们一起还用到了另外一种优化战略，也便是“大字段笔直拆分”战略。大字段笔直拆分战略相关于前面介绍的适度冗余战略在做法上能够说产不多是彻底相反的做法。适度冗余战略是将其他表中的字段拿过来在自己身上也存一份数据，而大字段笔直拆分简略来说便是将自己身上的字段拆分出去放在另外（独自）的表里面。
或许许多读者朋友都会有疑问了，咱们刚刚才剖析出了将其他字段拿过来放自己表里面为什么现在又要将自己的字段分出去呢？这样不是有些自相对立了吗？
其实并没有任何对立，前面咱们将他人的字段那过来，是由于咱们许多时分的查询需求运用该字段，为了削减 Join 带来的功用耗费才拿过来的。而咱们将大字段拿出去，也是将一些咱们在大部分查询中并不需求运用该字段的时分才会拿出去。并且，在咱们拿出去之前，咱们必定会经过全面的评价比较之后才干做出拆分出去的决定。
那究竟什么样的字段适宜于从表中拆分出去呢？
首要必定是大字段。为什么？原因很简略，便是由于他的大。大字段一般都是寄存着一些较长的 Detail 信息，如文章的内容，帖子的内容，产品的介绍等等。
其次是和表中其他字段比较拜访频率明显要少许多。由于大字段寄存的内容较多，大部分情况都是占整条记载的 80%以上，而数据库中数据在数据文件中的格局一般都是以一条一条记载为单位来寄存。也便是说，假如咱们要查询某些记载的某几个字段，数据库并不是只需求拜访咱们需求查询的哪几个字段，而是需求读取其他一切字段（能够在索引中完结整个查询的情况除外），也无法做到只读取咱们需求的几个字段的数据。这样，咱们就不得不读取包括大字段在内的许多并不相干的数据。而由于大字段所占的空间份额十分大，天然所糟蹋的 IO 资源也就十分之大了。
在这样的场景下，咱们就需求将该大字段从原表中拆分出来，经过独自的表进行寄存，让咱们在拜访其他数据的时分大大下降 IO 拜访，从而使功用得到较大的改进。
或许有人会疑问，尽管移出之后拜访其他字段的功率进步了，可是当咱们需求大字段的信息的时分，咱们就无法避免的需求经过Join 来完结，而运用Join 之后的处理功率或许会大打折扣的。其实这个忧虑是很合理的，这也便是咱们在分拆出大字段之前需求还需求考虑的第二个因素，拜访频率的因素了。前面咱们就介绍了，决定是否要分拆出，除了“大”之外，还要“频率低”才行，当然，这儿的“频率低”仅仅“相对频率”罢了。并且，这种分拆之后的两个表的联系都是彻底确认的一一对应联系，运用 Join 在功用方面的影响也并不是特其他大。
那咱们在移出大字段的一起，是否还需求将其他字段也一并移出呢？其实假如咱们现已确认有大字段需求分拆出主表的时分，关于其他的字段，只要满意拜访频率和大字段相同相关于表中其他字段要低许多的都能够和大字段一起分拆出来。
实践上，在有些时分，咱们甚至都不必定非要大字段才干进行笔直分拆。在有些场景下，有的表中大部分字段平常都很少拜访，而其中的某几个字段却是拜访频率十分高。关于这种表，也十分适宜经过笔直分拆来到达优化功用的意图。
③大表水平分拆 – 依据类型的分拆优化
“大表水平拆分”战略在功用优化方面或许被人运用的频率并不是太多，可是假如运用妥当，很或许会给咱们带来不小的惊喜。
咱们仍是直接经过实例来阐明问题吧。假设咱们将前面示例中的需求稍微做一下扩展，咱们期望 group 体系总管理员能够发布体系消息，并且在每一个 group 的评论帖的没一页都能置顶显示。
在得到该需求之后，咱们的榜首反响必定是经过在 group_message 表中添加一个标识列，用来寄存帖子的类型，标识出是一般会员的评论贴仍是体系管理员的置顶帖。然后在每个列表展现页面都经过对 group_message表的两次查询（一次置顶信息，一次一般评论帖）然后在运用程序中合并再展现。这样的成果是由于整个 group_message 表的数据较大，查询置顶信息的 Query 本钱会相对有些高。
下面咱们换一个思路来考虑一下这个问题：
- 首要，置顶信息和其他评论帖彻底不会产生任何关联交互；
- 其次，置顶信息的改动相关于其他评论帖来说改动很少；
- 再次，置顶信息的拜访频率十分高；
- 最后，置顶信息的量和一般评论帖来比十分之少；
经过上面的这几个剖析，假如咱们将置顶信息独自寄存在一般评论帖之外的其他表里面，首要不会带来什么附加的功用耗费，并且能够使每次检索置顶信息的本钱都有所下降。由于拜访频率十分的高，则由于每次检索置顶信息的本钱下降而得到较大的节约。数量少并且改动不怎么频频的特点则十分适宜运用 MySQL 的 Query Cache，而假如和一般评论帖在一起由于一般评论帖的频频改动带来 group_message 表相关的 Query Cache 失效问题会让他无法运用 Query Cache 功用。
经过上面的剖析，咱们很简略得出一个更为优化的计划来寄存这些置顶信息，那便是新增一张类似于 group_message 的表来专门寄存置顶信息，咱们暂且命名为 top_message 如下：
sky@localhost : example 10:49:20> desc top_message;
+--------------+--------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+--------------+--------------+------+-----+---------+-------+| id | int(11) | NO | | 0 | |
| gmt_create | datetime | NO | | NULL | |
| gmt_modified | datetime | NO | | NULL | |
| user_id | int(11) | NO | | NULL | |
| author | varchar(32) | NO | | NULL | || subject | varchar(128) | NO | | NULL | |+--------------+--------------+------+-----+---------+-------+复制代码
由于是大局的，所以省略了 group_id 信息，而 content 信息，仍是相同能够寄存在 group_message_content 表中。
上面仅仅仅仅一个示例，或许在实践运用中并不是如此的简略，但这儿仅仅给咱们一个思路，让咱们知道怎么经过大表的水平拆分来对经过优化 Schema 规划供给体系的全体功用。在许多大型的运用中，由于数据量十分庞大，并发拜访又十分高，到达单台主机都无法支撑单个表的拜访的时分，常常会经过这种大表的水平拆分，寄存在多台主机的多个数据库中完结全体扩展性的提升。
④核算表 – 准实时优化
为什么要准实时？
许多人看到这个优化战略之后或许都会提出这样的质疑，为什么要改动需求将“能够实时”的核算信息做成准实时的呢？原因很简略，由于实时核算的功用耗费本钱太高。由于每一次展现（也便是每一次刷新页面）都需求进行核算核算，带来许多的重复资源糟蹋。而做成准实时的核算信息之后，咱们每次只需求拜访很小的数据量即可，不需求频频的核算核算的工作。
当然，并不是一切的核算数据都适宜于经过准实时的核算表优化战略来完结的，即便咱们期望，产品司理们也不会允许，即便产品司理们也期望那样，咱们的运用者必定也会不同意。
什么类型的核算信息适宜经过准实时核算表来优化完结？
- 首要，核算信息的准确性要求并不是特其他严厉；
- 其次，核算信息对时刻并不是太敏感；
- 再次，核算信息的拜访十分频频，重复履行较多；
- 最后，参加核算数据量较大；
看看上面的要求，还真不少。不过，咱们所保护的体系中确实很或许存在这样的核算数据展现功用。如体系当时在线人数，论坛体系当时总帖数、回帖数等，多条件大成果集查询页面的总成果数以及总页数，某些虚拟积分的 top n 排名等等。
这些核算的核算都会规划到许多的数据，一起也需求许多的核算资源，拜访频率也都十分的高。假如都经过实时核算，恐怕只要数据量稍微大一些，都会带来十分大的硬件资源开支。但在短时刻内的不行精确，又并不会带来太大用户体会的下降。所以彻底能够经过守时使命程序，没隔一守时刻段进行一次核算后寄存在专门规划的核算表中。这样，在核算数据需求展现的时分，咱们只需求从核算好的成果数据中取出即可。这样每次核算数据的展现功用将会成数量级的提升，反而会使全体的用户体会上升。
二、优化数据类型
优化数据类型进步功用的首要原理在于以下几个方面：
- 经过选用更“小”的数据类型削减存储空间，使查询相同数据需求的 IO 资源下降；
- 经过适宜的数据类型加速数据的比较；
下面咱们仍是经过剖析一些常用数据类型的数据存储格局和长度来看看哪些数据类型能够在优化中利用上吧。
①数字日期类型
咱们先来看看寄存长度根本固定的一些数据类型的存储长度和取值规模。
关于数字类型，这儿别离列出了整数类型和小数类型，也便是浮点数类型。实践上，还有一类经过二进制格局以字符串来寄存的数字类型如 DECIMAL(DEC)[(M[,D])]，NUMERIC[(M[,D])]，由于其寄存长度首要经过其界说时分的的 M 所决定，M 界说为多大，则实践寄存就有多长。M 代表整个位数长度，而 D 则表明小数点后的位数，默许 M 为 10，D 为 0。一般来说，首要用在固定精度的场合，由于其寄存长度较大，并且考虑到这种数据彻底能够改动方法以整数寄存，所以笔者个人并不是特别推荐。
关于数字的存储，一般运用到浮点型数据的场合也不应该太多。首要出于两个原因，一个是浮点型数据自身实践上是一个并不精确的数字，仅仅一个近似值，另一个原因便是彻底能够经过乘以一个固定的系数转换为整型数据来寄存。这样不仅能够处理数据不精确的问题，一起也让数据的处理更为高效。
时刻存储格局总类并不是太多，咱们常用的首要便是 DATETIME，DATE 和 TIMESTAMP 这三种了。从存储空间来看TIMESTAMP最少，四个字节，而其他两种数据类型都是八个字节，多了一倍。而 TIMESTAMP 的缺点在于他只能存储从1970 年之后的时刻，而另外两种时刻类型能够寄存最早从1001 年开端的时刻。假如有需求寄存早于 1970 年之前的时刻的需求，咱们有必要抛弃 TIMESTAMP 类型，可是只要咱们不需求运用 1970 年之前的时刻，最好尽量运用 TIMESTAMP 来削减存储空间的占用。
上面所列出的首要是一些寄存固定长度，且咱们平常或许常用到的一些类型。经过这个对照表格，咱们能够很直观的看出哪种类型占用的存储空间大，哪种占用的空间小。这样，在数据类型挑选的时分，咱们就能够结合各种类型的存储规模以及事务中或许存在的数据作出对应，然后挑选存储空间最早的类型来运用。
②字符存储类型
咱们再来看看寄存字符的数据类型。
CHAR[(M)]类型归于静态长度类型，寄存长度彻底以字符数来核算，所以最终的存储长度是依据字符集的，如 latin1 则最大存储长度为 255 字节，可是假如运用 gbk 则最大存储长度为 510 字节。CHAR 类型的存储特点是不论咱们实践寄存多长数据，在数据库中都会寄存 M 个字符，不行的经过空格补上，M 默许 为 1。尽管CHAR会经过空格补齐寄存的空间，可是在拜访数据的时分，MySQL 会疏忽最后的一切空格，所以假如咱们的实践数据中假如在最后确实需求空格，则不能运用CHAR 类型来寄存。在MySQL5.0.3之前的版别中，假如咱们界说 CHAR 的时分 M 值超越 255，MySQL 会主动将 CHAR 类型进行转换为能够存入对应数据量的 TEXT 类型，如 CHAR(1000)会主动转换为 TEXT，CHAR(10000)则会转为 MEDIUMTEXT。而从 MySQL5.0.3 开端，一切超越 255 的界说 MySQL 都会直接拒绝并给出错误信息，不再主动转换。
VARCHAR[(M)]归于动态存储长度类型，仅存占用实践存储数据的长度。其寄存的最大长度与 MySQL 版别有关，在 5.0.3 之前的版别 VARCHAR 以字符数操控最存储的最大长度，最大只能寄存 255 个字符，占用存储空间的实践巨细与字符集有关。可是从 5.0.3 开端，VARCHAR 的最大存储约束现已更改为字节数约束了，扩展到能够寄存 65535 bytes 的数据，不同的字符集或许寄存的字符数并不相同。也便是说，在 MySQL5.0.3 之前的版别，M 所代表的是字符数，而从 5.0.3 版别开端，M 的代表意思现已是字节数了。VARCHAR 的存储特点是不论咱们设定 M 为多大的值，真实占用的存储空间都只要咱们所存入的实践数据的巨细，和 CHAR 不同的是 VARCHAR 会保存咱们存入数据最后的空格，也便是说咱们存入是什么样，MySQL 返回给咱们的也会是什么样。在 VARCHAR 类型字段的数据中，MySQL 会在每个 VARCHAR 数据中运用 1 个或 者 2 个字节用来寄存 VARCHAR 数据的实践长度，当咱们的实践数据在 255 字节之内的时分，会运用 1 字节来寄存实践长度，而大于 255 字节的时分，则需求运用 2 字节来寄存。
TINYTEXT，TEXT，MEDIUMTEXT 和 LONGTEXT 这四种类型同归于一种存储方法，都是动态存储长度类型，不同的仅仅是最大长度的约束。四种类型的界说都是经过最大字符数来约束，可是他们的字符数约束实践上是能够理解为字节数约束的，由于当咱们运用多字节字符集的时分，实践能寄存的字符书并没最大字符数那么多，而是以单字节字符来核算的字符数。此外，由于是动态存储长度类型，所以和 VARCHAR 相同，每个字段数据之前都需求一个寄存实践长度的空间。TINYTEXT需求1 个字节来寄存，TEXT 需求 2 个字节，MEDIUMTEXT 和 LONGTEXT 则别离需求 3 个和 4 个字节来寄存实践数据长度。实践上，出了 MySQL 内 嵌 的 最 大 长 度 限 制 之 外 ， 他 们 还 受 到 客 户 端 与 服 务 器 端 的 网 络 通 信 缓 冲 区 最 大 值 （max_allowed_packet）的约束。
这四种 TEXT 类型和 CHAR 及 VARCHAR 在实践运用中存在几个不相同的当地：
- 不能设置默许值；
- 只要 TEXT 能够运用 TEXT[(M)]这样的方法经过 M 设置巨细；
- 依据这四种类型的索引有必要指定前缀长度；
③其他常用类型
除了上面这些字段类型之外会被咱们常常运用到之外，咱们还会运用到的数据类型首要有以下这些。
关于 BIT 类型，M 表明每个值的 bits 数目，默许为 1，最大为 64 bits。关于 MySQL 来说这是一个新的类型，由于从 MySQL5.0.3 才开端真实完结（在之前实践上是 TINYINT（1）），并且仅仅支持 MyISAM 存储引擎，可是从 MySQL5.0.5 开端 Memory，Innodb 和 NDB Cluster 存储引擎也开端“支持”了。在 MyISAM中，BIT的存储空间很小，是真实的完结了经过bit 来存储，可是在其他的一些存储引擎中就不相同了，由于他们是转换为最小的INT 类型存储的，所以占用的空间也没有节约，还不如直接运用 INT 类的数据类型寄存来得直观。
关于 SET 和 ENUM 类型，首要内容根本处于较少改动状况且值比较少的字段。尽管这两个字段所占用的存储空间都较少，可是由于在运用方面较其他的数据类型要略为杂乱一些，所以在实践环境中一般运用仍是较少。
谁都知道，数据量（这儿首要指数据记载条数）的添加必定会让数据库的检索查询功率下降。所以许多时分人们大都期望经过削减数据库中要害表的记载条数来获得数据库功用的提升。实践上，除了这种经过操控数据记载条数来操控数据总量的办法之外，咱们还能够经过挑选更小的数据类型来让数据库经过更小的空间寄存相同的数据量，这关于检索相同的数据所带来的 IO 耗费天然会下降，功用也就很天然得到了提升。
此外，由于 CPU 对不同数据的处理方法不相同，就会造成不同类型的数据在各种运算处理如比较，排序等方面的处理功率存在差异。所以，关于咱们需求常常进行比较核算以及排序等耗费 CPU 资源的字段，应该尽量挑选处理更为敏捷的字段类型。如经过整数类型替代浮点数或许字符类型。
三、标准的方针命名
标准的命名自身并不会对功用有任何影响，但这是一个不太被人注重，可是对后期的数据库保护影响十分大的内容。 就像编程语言各自的一些不成文编码根本标准相同，尽管在最初运用的时分并看不错太多的利益，反而会被人认为是一种束缚，可是当每一个人在接手保护一段编写很不标准的代码的时分，估量大部分人都会十分郁闷，甚至在心里暗骂当初的编写者。其实任何体系都相同，没有任何标准可循，彻底一个天马行空的作风，只会给后人（甚至或许是自己）留下一个让人摸不着头脑的烂摊子，难以保护。
关于数据库方针的命名标准其实能够很简略，并且业界也并不存在一个严厉的共同规定，只需求在一个公司内满意共同根本就能够了。
一般来说，我个人主张需求留意以下一些方面：
- 数据库和表名应尽或许和所服务的事务模块名共同； 这样，在 DBA 保护相关数据库方针的时分，新开发人员程序开发进程中，相关技能（或非技能）人员整理事务逻辑和数据联系的时分，都能够十分简略理解其中的联系。
- 服务于同一子模块的一类表尽量以子模块名（或部分单词）为前缀或后缀； 对同类功用的表添加前缀或许后缀，也是让查看运用该表的各类人员能够很快的依据相关方针的称号就联想到相应的功用，以及相关事务。不论是从保护视点，仍是从运用视点来看都会带来十分大的便利性。
- 表名应尽量包括与所寄存数据相对应的单词； 这关于新员工来说特别重要，要想尽快的熟悉数据，尽快了解相关事务，快速的定位数据库中各表对应的数据含义是十分有帮助的。
- 字段称号也尽量坚持和实践数据相对应 这一点的含义我想各位读者朋友应该都十分的清楚，每个表都会有许多的字段对应数据的各种不同特点，要搞清楚各自代表的含义，除了完好标准的阐明文档之外，命名明晰合理的字段名也是一个有用的弥补，并且更为直接。
- 索引称号尽量包括一切的索引键字段名或许缩写，且各字段名在索引名中的顺序应与索引键在索引中的索引顺序共同，且尽量包括一个类似于 idx 或许 ind 之类的前缀或许后缀，以表名其方针类型是索引，一起还能够包括该索引所属表的称号； 这样做最大的优点在于 DBA 在保护进程中能够十分直接明晰的经过索引称号就了解到该索引大部分的信息。
- 束缚等其他方针也应该尽或许包括所属表或其他方针的称号，以表名各自联系。
上面列出的仅仅一个比较初略的标准主张，实践操作中彻底能够依据各自公司的习惯，制定自己的命名标准，只要适用，就能够了。标准不在多，而在实用。并且一旦制定的标准，就有必要严厉的按照标准履行，否则就变成了个花架子没有任何实践的含义了。
总结
“数据库体系的功用不是优化出来的，更多的是规划出来的”。 数据库 Schema 的规划并不如许多人幻想的那样仅仅一个简略的方针对应完结，而是一个体系工程。要想规划出一个既功用高效又满意满意事务需求，既逻辑明晰又联系简略的数据库 Schema 结构，不仅仅需求满意的数据库体系知识，还需求满意了解运用体系的事务逻辑。
参加咱们
扫码发现职位&投递简历
官网投递：job.toutiao.com/s/FyL7DRg
