再对应的mapper上面实现基本的接口 BaseMapper  extends BaseMapper<User>

里面有各种curd操作

//注解填充字段

@TableField(.. fill = FieldFill.INSERT) 生成器策略部分也可以配置！
@TableField(fill = FieldFill.INSERT)
private Data createTime;
@TableField(fill = FieldFill.INSERT_UPDATE)
private Data updateTime;

添加component，实现MetaObjectHandler

重写方法

//strictInsertFill(MetaObject metaObject, String fieldName, Class<T> fieldType, E fieldVal)
        this.strictInsertFill(metaObject,"createTime", LocalDateTime.class,LocalDateTime.now());// 起始版本 3.3.0(推荐使用)

或者：

        this.setFieldValByName("createBy", UserUtil.getUsername(),metaObject);
        this.setFieldValByName("createTime", new Date(), metaObject);
        this.setFieldValByName("updateBy", UserUtil.getUsername(),metaObject);
        this.setFieldValByName("updateTime", new Date(), metaObject);

// 这个是通用的，插入和更新都可以使用 但是当字段存在值 的时候不进行填充
this.fillStrategy(metaObject, "createTime", LocalDateTime.now()); // 也可以使用(3.3.0 该方法有bug请升级到之后的版本如`3.3.1.8-SNAPSHOT`)
// 这个是insert的时候用的，插入的时候时候强制进行填充
this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); // 起始版本 3.3.0(推荐使用)
// update的时候使用，更新的时候强制进行填充
this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); // 起始版本 3.3.0(推荐使用)
 

 

自定义id生成器
 

@TableId(type = IdType.ASSIGN_ID)   
 

private Long id;
 

UUID
 


 UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF发布的UUID规范 A Universally Unique IDentifier (UUID) URN Namespace。
 

优点：
 

性能非常高：本地生成，没有网络消耗。
 

缺点：
 

没有排序，无法保证趋势递增。
 

UUID往往使用字符串存储，查询的效率比较低。
 

不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
 

信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
 

ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用：
 

MySQL官方有明确的建议主键要尽量越短越好[4]，36个字符长度的UUID不符合要求。
 

对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。
 

SnowFlake（雪花算法）
 


 这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图（图片来自网络）所示：
 

41-bit的时间可以表示（1L<<41）/(1000L360024*365)=69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
 

核心思想：
 

使用41bit作为毫秒数，10bit作为机器的ID(5个bit是数据中心，5个bit的机器ID)，12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生4096个ID），最后还有一个符号位，永远是0,。
 

优点：
 

毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
 

不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
 

可以根据自身业务特性分配bit位，非常灵活。
 

缺点：
 

强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
 

乐观锁和悲观锁
 

  •  
    取出记录时，获取当前version
     
  •  
    更新时，带上这个version
     
  •  
    执行更新时，set version = newVersion where version = oldVersion
     
  •  
    如果version不对，就更新失败
     


分页
 

  •  
    原始的limit进行分页
     
  •  
    pageHelper第三方插件
     
  •  
    MyBatisPlus内置分页插件
     


配置拦截器组件即可
 

使用  Page<User> page = new Page<>(1, 4);
 

//page的其他方法
 System.out.println("当前页：" + page.getCurrent());
 System.out.println("总页数：" + page.getPages());
 System.out.println("记录数：" + page.getTotal());
 System.out.println("是否有上一页：" + page.hasPrevious());
 System.out.println("是否有下一页：" + page.hasNext());
 


                
        
        
     
          



 
更多推荐


MybatisPlus