后端小白程序员都需要知道的知识点

主要是写给刚出来社会的小白程序员的，有许多比较隐晦的业务上的问题需要我们注意的，但是在学校或者自己的项目开发中没有注意的细节,量少以后如果有新的比较干货的会在这里补充，一些很多人都发了的这里就不赘述了。

1. 数据查询都需要分页，且必要限定最大条数

在数据获取的时候，我们的接口常常会使用到分页，但是很多时候我们在开发过程中会忘记去限制最大条数。

这么做会导致在数据量上来了以后，程序分页条件如果错误 写成查询全部，此时会将数据库的所有数据检索出来。

这个动作是很危险的，很容易导致服务或者数据库直接崩溃，最好的方法就是我们在给他分页的时候限制一个最大条数，这样即可避免因为操作失误或者人为关系导致查询到全部数据，这也适用于其他任何有关的查询接口。

场景

简单的分页接口，导出接口等，特别是导出接口，通常还要在内存将其进行处理成文件 数据量大的情况的很容易就会导致服务直接宕机卡死。

2. 数据操作的时候需要校验数据权限

在我们平时开发中，权限是一个很常见的问题，但是我们小白开发来说通常只会校验接口权限 很少会去关心数据权限(不懂数据权限的建议掘金搜索数据权限.).

如果在修改数据的接口不校验数据权限会发生啥呢？，就是我们可以通过这个接口去操作别人的数据，例如一个删除接口，我们通常是根据数据id进行删除的，如果我们知道了别人的数据id，通过http客户端发送的形式，将我们的认证标识和id发到后端 在没有校验接口数据权限的情况下，我们的删除是完全可以成功的。

场景

所有的数据操作接口(增删改).

3. 循环调用数据库

很多小白用上了mybatis plus之后，会下意识的不再去自己写sql，因为所有的对数据库的关联操作，都可以简化成对应的两张表的增删改查，通过分成多次查询而减少自己编写sql的代码量。

例如商品表和详情表，我们可以通过查询商品表，之后查询详情表的方式来对数据进行获取。

这么做会有一个问题 当商品表的实体比较多的时候(例如正常的商品列表，需要多条商品)，这样子再以上面的形式去做查询就会导致一个问题，就是我们需要执行的sql次数是 1(商品分页)+10(商品详情) 次，因为需要通过for循环给商品实体添加商品详情的信息。循环操作数据库

这么做会导致很严重的性能问题，而且在分页数量很大的情况下，这么做会导致执行 查询数量+1 的sql次数 对数据库的压力极大。

场景

所有关联查询接口

解决方法

查询子表的时候使用in来一次性获取我们需要的所有子表数据，然后通过过滤或者分组的方式填充进去实体，这样sql查询的次数会更改为常数2.