序言

以下是本萌新对于后端内容设计的一些见解。由于个人从业时间等因素。不论是观点还是方案等都具备一定的局限性。阅读过程中如发现不合理之处还望各位海涵，有可以优化的地方亦可以在评论区打出。

职位认知

首先对于个人职位的认知：一个后端码农。作为一个后端我个人具备的能力有哪些。能够大致做出那种类型的工作。比如我对大部分CURD没啥大问题，部分传统的算法如各类排序，搜索没啥问题。但如果项目需求是训练一个智能模型。那我只能说做不了，我不配。

设计注意事项

除了做不了的需求，那么有一部分需求是合乎情理，且是我能够做到的。那么我进行设计的时候我应该要关注哪些信息，分别是什么。以下是我的个人见解。 作为后端设计，数据库设计应该算是头疼的一部分之一。数据库设计过程中需要考虑的有字段结构，字段内信息结构，以及索引。这是最基础的设计。这些设计可以满足大部分的需求。当然仅仅依靠这些设计并不能保证服务器的有效利用。接下来可以进行优化的方案我大致分为4类。

第一类：

简单粗暴，老板砸钱，提硬件去。

第二类：

索引优化，网上教程一堆，不再过多赘述。

第三类：

参数优化，如调节数据库的连接数，调节语句执行返回时间，如集群中当一个节点被更新就进行返回而不是等到所有节点全部更新完毕再进行返回（注意数据一致问题）等。这一类也可以算作是针对于数据库的优化。

第四类：

对于数据库表结构的更改，和对接口调用量分析平衡。简而言之就是当服务器负责数据处理，数据主要分为两类数据流入和数据流出。要在中间加入数据计算的过程。这一类型的提升往往具有需求的独特性。需要根据各个接口的调用量，并发性进行调节。调整数据计算的时间，是在数据流入时进行计算，将计算结果存入数据库，当需要数据信息的时候直接进行读取。还是说将数据先保存下来，当需要用的时候再取出进行计算。当然计算也未必要一次性全部计算完全。也完全可以数据流入时计算一部分，数据流出时计算一部分。平衡二者之间的关系，也可以在一定程度上提高服务器的利用。举一个简单的例子，如用户信息的获取。在登陆的时候我们需要获取用户信息。用户也可以修改个人的用户信息。 在这种情况下修改用户个人信息可以认为是数据流入，用户登录获取个人信息是数据流出。可以设计两种数据库。其一（我相信不会有人用的）将用户的每次更改存入一张数据表，当用户登陆时查询该数据表，对原始数据进行更改。这种情况使用户用户更新个人信息次数远大于登录次数的情况，更严格的来说应该是用户信息修改的操作满足不了修改的请求并发量，就可以选择牺牲用户登录的性能，来提高用户修改的并发上限。另一种方式就是常见的维护一张用户表，用户每次更新个人信息就对该表进行数据更新。这种情况适用于用户登录远大于用户更新的情况（也比较符合时间情况）。

个人特色

总要留下些属于我的特色：书山有路勤为径，学海无涯苦作舟。奈何山太高，海太深，我像个傻子。