Postman+批量插入+分页+逻辑删除

最新推荐文章于 2024-10-13 15:44:49 发布

m0_45198397

最新推荐文章于 2024-10-13 15:44:49 发布

阅读量1.2k

点赞数 1

分类专栏： Java秋招之路文章标签：学习

本文链接：https://blog.csdn.net/m0_45198397/article/details/128295426

版权

Java秋招之路专栏收录该内容

4 篇文章 1 订阅

订阅专栏

1. postman接口测试使用：

(71条消息) 全网最全的 postman 工具使用教程_Jsono8的博客-CSDN博客_postman使用https://blog.csdn.net/Jsono8/article/details/121933133

2.prepareStatement

批量处理：使用prepareStatement让数据库预热再插入（如存在拼接语句速度就会受影响，因为拼接的情况会重新解析，解析耗时）。如果mybatis使用prepareStatement，只需要开启批量事务,循环就可以利用了。没有开启事务执行单个insert循环肯定会慢,因为从连接池获取连接放回等操作很频繁,如果是批量事务,循环插入，是一个连接且复用模板。一般会将插入分片为5w一条,每次插入再没有大量索引的情况下,应该是1秒内完成的（1秒外是慢语句,需要优化)(72条消息) 10万条数据批量插入，到底怎么做才快？_程序员阿金的博客-CSDN博客_insert10万条数据

批处理方案：

方案一、用for循环批量插入：优势在于，JDBC 中的 PreparedStatement 有预编译功能，预编译之后会缓存起来，后面的 SQL 执行会比较快并且 JDBC 可以开启批处理，这个批处理执行非常给力。劣势在于，很多时候我们的 SQL 服务器和应用服务器可能并不是同一台，所以必须要考虑网络 IO，如果网络 IO 比较费时间的话，那么可能会拖慢 SQL 执行的速度。

方案二、仅生成一条SQL插入insert into user(username,address) values('aa','bb'),('cc','dd')... ：优势在于只有一次网络 IO，即使分片处理也只是有限数次网络 IO，所以这种方案不会在网络 IO 上花费太多时间。劣势：一是 SQL 太长了甚至可能需要分片后批量处理；二是无法充分发挥 PreparedStatement 预编译的优势，SQL 要重新解析且无法复用；三是最终生成的 SQL 太长了，数据库管理器解析这么长的 SQL 也需要时间。

方案一更具优势，且当批量插入十万、二十万数据的时候，方案一的优势会更加明显（方案二则需要修改 MySQL 配置或者对待插入数据进行分片）。那么如何实现？

step0（必须的）：Mybatis依赖和Mysql驱动依赖

step1：application.properties（yml）配置数据库信息：

注意：数据库连接 URL 地址中多了一个参数rewriteBatchedStatements ，这是核心。MySQL JDBC 驱动在默认情况下会无视 executeBatch() 语句，把我们期望批量执行的一组 sql 语句拆散，一条一条地发给 MySQL 数据库，批量插入实际上是单条插入，直接造成较低的性能。如果不采用批处理模式，反反复复的获取 Connection 以及释放 Connection 会耗费大量时间，效率奇低。故而将 rewriteBatchedStatements 参数值为 true , 数据库驱动才会帮我们批量执行 SQL 。

step2：写相关语句

3.LoggerFactory.getLogger用法

作用：LoggerFactory.getLogger可以在IDE控制台打印日志，便于开发，一般加在代码最上面。引入依赖：import org.slf4j.Logger；import org.slf4j.LoggerFactory;

4.分页查询

pageHelper是一个适用于MyBatis的分页插件，通过该插件可以很方便的实现分页查询。使用：

step0：pom文件引入依赖

step1：yml文件配置

step2：

5.逻辑删除

1）为什么要逻辑删除：a.防止数据误删除，不能找回数据；b.这些数据还具有一定的商业价值，比如用户的注册信息；c.虽然这些数据可以删除，但是这些数据的关联数据不能删除。

2)逻辑删除带来的问题：a.数据库表的数据冗余，导致查询缓慢；b.写sql进行数据处理时需要排除那些已经逻辑删除的数据，这就会导致sql复杂，容易出错，特别是涉及多表查询时；c.进行逻辑删除时，还需要考虑与之相关的数据怎么处理；

方案一：在表中加一个字段deleted字段：插入时默认0，删除时置1。查询和更新时都带上“deleted=0”这个条件。方案评价：简单，但存在以下问题：如果数据表的某个字段要求唯一，并强制约束，比如user_name字段，设计为逻辑删除的话，一旦有新的相同的user_name就无法插入。但如果不将该字段设置为唯一性约束，那么在每次插入数据的时候，都需先进行一次查询，看看有无未(逻辑)删除的同名记录存在，低效率，而且在高并发的系统中，很难保证其正确性（服务运行了一段时间后还是发现了数据库中存在 name = a 且 is_delete = 0 的多条字段，见下图）

这个问题有下面两个解决方案：

解决方案1：为数据库添加新的一列delete_token，当某一条记录需要删除时，将该字段设置为一个UUID，将（name，delete_token）设置为唯一键，这样当is_delete=0时，delete_token保持一个默认值，能够有效地限制name唯一；当记录被删除时，由于delete_token是一个唯一的UUID，便能保证删除的记录不会被唯一约束束缚，即可以插入与is_delete=1相同name的记录。但UUID会占用很大的空间，不推荐使用。提出优化对策：将删除记录的delete_token设置为该记录的id。而且需要批量删除时，需要对每一条记录进行插入UUID，代价较高。

解决方案2：将删除标记设置默认值(例如0)，将唯一字段与删除标记添加唯一键约束。当某一记录需要删除时，将删除标记置为NULL。由于NULL不会和其他字段有组合唯一键的效果，所以当记录被删除时(删除标记被置为NULL时)，解除了唯一键的约束（即可以插入与已删除相同的name记录）。此外该方法能很好地解决批量删除的问题(只要置为NULL就完事了)，消耗的空间也并不多(1位 + 联合索引)。

方案二：表备份：将删除的数据备份到其他备份表再进行物理删除。如果有级联数据，也需要进行删除备份，不然数据的完整性就不存在了。

使用MyBatis-Plus实现逻辑删除（方案一）

MyBatis-Plus(简称MP)是对MyBatis的增强，可以完全兼容MyBatis的原生功能，而且几乎可以省略单表操作的所有增删改查方法，大大提升了开发效率。具体使用：