MySQL 处理大数据表的 3 种方案，写的太好了，建议收藏！！

Posted 2023-04-17 Java技术栈

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL 处理大数据表的 3 种方案，写的太好了，建议收藏！！相关的知识，希望对你有一定的参考价值。

作者：马佩
链接：https://juejin.cn/post/7146016771936354312

场景

当我们业务数据库表中的数据越来越多，如果你也和我遇到了以下类似场景，那让我们一起来解决这个问题

数据的插入,查询时长较长
后续业务需求的扩展在表中新增字段影响较大
表中的数据并不是所有的都为有效数据需求只查询时间区间内的

评估表数据体量

我们可以从表容量/磁盘空间/实例容量三方面评估数据体量，接下来让我们分别展开来看看。

推荐一个开源免费的 Spring Boot 最全教程：

https://github.com/javastacks/spring-boot-best-practice

表容量：

表容量主要从表的记录数、平均长度、增长量、读写量、总大小量进行评估。一般对于OLTP的表，建议单表不要超过2000W行数据量，总大小15G以内。访问量：单表读写量在1600/s以内

查询行数据的方式：我们一般查询表数据有多少数据时用到的经典sql语句如下：

select count(*) from table;
select count(1) from table;

但是当数据量过大的时候，这样的查询就可能会超时，所以我们要换一种查询方式：

use 库名;
show table status like \'表名\' ; 
show table status like \'表名\'\\G ;

上述方法不仅可以查询表的数据，还可以输出表的详细信息 , 加 \\G 可以格式化输出。包括表名存储引擎版本行数每行的字节数等等，大家可以自行试一下哈

磁盘空间

查看指定数据库容量大小

select
table_schema as \'数据库\',
table_name as \'表名\',
table_rows as \'记录数\',
truncate(data_length/1024/1024, 2) as \'数据容量(MB)\',
truncate(index_length/1024/1024, 2) as \'索引容量(MB)\'
from information_schema.tables
order by data_length desc, index_length desc;

查询单个库中所有表磁盘占用大小

select
table_schema as \'数据库\',
table_name as \'表名\',
table_rows as \'记录数\',
truncate(data_length/1024/1024, 2) as \'数据容量(MB)\',
truncate(index_length/1024/1024, 2) as \'索引容量(MB)\'
from information_schema.tables
where table_schema=\'mysql\'
order by data_length desc, index_length desc;

查询出的结果如下：

建议数据量占磁盘使用率的70%以内。同时，对于一些数据增长较快，可以考虑使用大的慢盘进行数据归档（归档可以参考方案三）

实例容量

MySQL是基于线程的服务模型，因此在一些并发较高的场景下，单实例并不能充分利用服务器的CPU资源，吞吐量反而会卡在mysql层，可以根据业务考虑自己的实例模式

出现问题的原因

上面我们已经查到我们数据表的体量了那么为什么单表数据量越大业务的执行效率就越慢根本原因是什么呢？

一个表的数据量达到好几千万或者上亿时，加索引的效果没那么明显啦。性能之所以会变差，是因为维护索引的B+树结构层级变得更高了，查询一条数据时，需要经历的磁盘IO变多，因此查询性能变慢。

大家是否还记得，一个B+树大概可以存放多少数据量呢？

InnoDB存储引擎最小储存单元是页，一页大小就是16k。

B+树叶子存的是数据，内部节点存的是键值+指针。索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中，进而再去数据页中找到需要的数据；

假设B+树的高度为2的话，即有一个根结点和若干个叶子结点。这棵B+树的存放总记录数为=根结点指针数*单个叶子节点记录行数。

如果一行记录的数据大小为1k，那么单个叶子节点可以存的记录数 =16k/1k =16.
非叶子节点内存放多少指针呢？我们假设主键ID为bigint类型，长度为8字节(面试官问你int类型，一个int就是32位，4字节)，而指针大小在InnoDB源码中设置为6字节，所以就是8+6=14字节，16k/14B =16*1024B/14B = 1170

因此，一棵高度为2的B+树，能存放1170 * 16=18720条这样的数据记录。同理一棵高度为3的B+树，能存放1170 *1170 *16 =21902400，也就是说，可以存放两千万左右的记录。B+树高度一般为1-3层，已经满足千万级别的数据存储。

如果B+树想存储更多的数据，那树结构层级就会更高，查询一条数据时，需要经历的磁盘IO变多，因此查询性能变慢。

如何解决单表数据量太大，查询变慢的问题

知道了根本原因之后，我们就需要考虑如何优化数据库来解决问题了

这里提供了三种解决方案，包括数据表分区，分库分表，冷热数据归档了解完这些方案之后大家可以选取适合自己业务的方案

方案一：数据表分区

为什么要分区：表分区可以在区间内查询对应的数据，降低查询范围并且索引分区也可以进一步提高命中率，提升查询效率

分区是指将一个表的数据按照条件分布到不同的文件上面，未分区前都是存放在一个文件上面的，但是它还是指向的同一张表，只是把数据分散到了不同文件而已。

我们首先看一下分区有什么优缺点：

表分区有什么好处？

与单个磁盘或文件系统分区相比，可以存储更多的数据。
对于那些已经失去保存意义的数据，通常可以通过删除与那些数据有关的分区，很容易地删除那些数据。相反地，在某些情况下，添加新数据的过程又可以通过为那些新数据专门增加一个新的分区，来很方便地实现。
一些查询可以得到极大的优化，这主要是借助于满足一个给定WHERE语句的数据可以只保存在一个或多个分区内，这样在查找时就不用查找其他剩余的分区。因为分区可以在创建了分区表后进行修改，所以在第一次配置分区方案时还不曾这么做时，可以重新组织数据，来提高那些常用查询的效率。
涉及到例如SUM()和COUNT()这样聚合函数的查询，可以很容易地进行并行处理。这种查询的一个简单例子如 “SELECT salesperson_id, COUNT (orders) as order_total FROM sales GROUP BY salesperson_id；”。通过“并行”，这意味着该查询可以在每个分区上同时进行，最终结果只需通过总计所有分区得到的结果。
通过跨多个磁盘来分散数据查询，来获得更大的查询吞吐量。

表分区的限制因素

一个表最多只能有1024个分区。
MySQL5.1中，分区表达式必须是整数，或者返回整数的表达式。在MySQL5.5中提供了非整数表达式分区的支持。
如果分区字段中有主键或者唯一索引的列，那么多有主键列和唯一索引列都必须包含进来。即：分区字段要么不包含主键或者索引列，要么包含全部主键和索引列。
分区表中无法使用外键约束。
MySQL的分区适用于一个表的所有数据和索引，不能只对表数据分区而不对索引分区，也不能只对索引分区而不对表分区，也不能只对表的一部分数据分区。

在进行分区之前可以用如下方法看下数据库表是否支持分区哈

mysql> show variables like \'%partition%\';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| have_partitioning | YES   |
+-------------------+-------+
1 row in set (0.00 sec)

方案二：数据库分表

为什么要分表：分表后，显而易见，单表数据量降低，树的高度变低，查询经历的磁盘io变少，则可以提高效率

mysql 分表分为两种水平分表和垂直分表

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。

水平分表

定义：数据表行的拆分，通俗点就是把数据按照某些规则拆分成多张表或者多个库来存放。分为库内分表和分库。比如一个表有4000万数据，查询很慢，可以分到四个表，每个表有1000万数据

垂直分表

定义：列的拆分，根据表之间的相关性进行拆分。常见的就是一个表把不常用的字段和常用的字段就行拆分，然后利用主键关联。或者一个数据库里面有订单表和用户表，数据量都很大，进行垂直拆分，用户库存用户表的数据，订单库存订单表的数据

缺点：垂直分隔的缺点比较明显，数据不在一张表中，会增加join 或 union之类的操作

知道了两个知识后，我们来看一下分库分表的方案

1.取模方案：

拆分之前，先预估一下数据量。比如用户表有4000w数据，现在要把这些数据分到4个表user1 user2 uesr3 user4。比如id = 17，17对4取模为1，加上，所以这条数据存到user2表。

注意：进行水平拆分后的表要去掉auto_increment自增长。这时候的id可以用一个id 自增长临时表获得，或者使用 redis incr的方法。

优点：数据均匀的分到各个表中，出现热点问题的概率很低。

缺点：以后的数据扩容迁移比较困难难，当数据量变大之后，以前分到4个表现在要分到8个表，取模的值就变了，需要重新进行数据迁移。

2.range 范围方案

以范围进行拆分数据，就是在某个范围内的订单，存放到某个表中。比如id=12存放到user1表，id=1300万的存放到user2 表。

优点：有利于将来对数据的扩容

缺点：如果热点数据都存在一个表中，则压力都在一个表中，其他表没有压力。

我们看到以上两种方案都存在缺点但是却又是互补的，那么我们将这两个方案结合会怎样呢？

3.hash取模和range方案结合

如下图我们可以看到 group 组存放id 为0~4000万的数据，然后有三个数据库 DB0 DB1 DB2，DB0里面有四个数据库，DB1 和DB2 有三个数据库

假如id为15000 然后对10取模（为啥对10 取模因为有10个表），取0 然后落在DB_0,然后在根据range 范围，落在Table_0 里面。

总结：采用hash取模和range方案结合既可以避免热点数据的问题，也有利于将来对数据的扩容

我们已经了解了 mysql分区和分表的知识那我们看一下这两个技术有何不同以及适用场景

分区分表的区别：

1、实现方式上

mysql的分表是真正的分表，一张表分成很多表后，每一个小表都是完整的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.frm表结构
分区不一样，一张大表进行分区后，他还是一张表，不会变成二张表，但是他存放数据的区块变多了。

2、提高性能上

分表重点是存取数据时，如何提高mysql并发能力上；
而分区呢，如何突破磁盘的读写能力，从而达到提高mysql性能的目的。

3、实现的难易度上

1、分表的方法有很多，用merge来分表，是最简单的一种方式。这种方式根分区难易度差不多，并且对程序代码来说可以做到透明的。如果是用其他分表方式就比分区麻烦了。 2、分区实现是比较简单的，建立分区表，根建平常的表没什么区别，并且对开代码端来说是透明的

分区分表的联系

1、都能提高mysql的性高，在高并发状态下都有一个良好的表现。

2、分表和分区不矛盾，可以相互配合的，对于那些大访问量，并且表数据比较多的表，我们可以采取分表和分区结合的方式，访问量不大，但是表数据很多的表，我们可以采取分区的方式等。

分库分表存在的问题

1、事务问题

在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

2、跨库跨表的join问题

在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

3、额外的数据管理负担和数据运算压力

额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order by语句就可以搞定，但是在进行分表之后，将需要n个order by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。

方案三：冷热归档

为什么要冷热归档：其实原因和方案二类似，都是降低单表数据量，树的高度变低，查询经历的磁盘io变少，则可以提高效率如果大家的业务数据，有明显的冷热区分，比如：只需要展示近一周或一个月的数据。那么这种情况这一周喝一个月的数据我们称之为热数据，其余数据为冷数据。那么我们可以将冷数据归档在其他的库表中，提高我们热数据的操作效率。

接下来讲一下归档的过程

创建归档表创建的归档表原则上要与原表保持一致
归档表数据的初始化

业务增量数据处理过程

数据的获取过程

以上三种方案我们如何选型

方案	试用场景	优点	缺点
数据表分区	1.数据量较大 2.查询场景只在某个区 3.没有联合查询的场景	分区分表是在物理上对数据表所对应的文件进行拆分，对应的表名是不变的，所以不会影响到之前业务逻辑的sql	分表后的查询等业务会创建对应的对象，也会造成一定的开销分区数据若要聚合的话耗费时间也较长；使用范围不适合数据量千万级以上的
数据表分表	数据量较大,无法区分明显冷热区且数据可以完整按照区间划分	适用于对冷热分区的界限不是很明显的数据，对后续类似的数据可以采用该方式，将大表拆分成小表提高查询插入等效率	若大数据表逐渐增多那么对应的数据库表越来越多每个表都需要分表；区间的划分较为固定若后续单表的数据量大起来也会对性能造成影响；实现复杂度相对方案三比较复杂需要测试整个实现过程在编码层处理对原有业务有影响；
冷热归档分库	数据量较大；数据冷热分区明显；冷数据使用频率极低；	数据迁移的过程对业务的影响较小开发量也较少减少成本	需要确认分表规则

大家可以根据自己的业务场景，去选择合适自己业务的方案，我这边就给大家提供一下思路～

那么到了这里，我要讲的内容就差不多结束了，如果有什么不对的，或者有什么疑惑，欢迎大家指点！

参考文章：https://blog.csdn.net/qq_36770474/article/details/119537186

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.别再写满屏的爆爆爆炸类了，试试装饰器模式，这才是优雅的方式！！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！

Spring Boot 项目统一结果，统一异常，统一日志，写的太好了。。

作者：永动的图灵机
链接：https://juejin.cn/post/6844904033488994317

统一结果返回

目前的前后端开发大部分数据的传输格式都是json，因此定义一个统一规范的数据格式有利于前后端的交互与UI的展示。

统一结果的一般形式

是否响应成功；
响应状态码；
状态码描述；
响应数据
其他标识符

结果类枚举

前三者可定义结果枚举，如：success，code，message

@Getter
public enum ResultCodeEnum 
    SUCCESS(true,20000,"成功"),
    UNKNOWN_ERROR(false,20001,"未知错误"),,
    PARAM_ERROR(false,20002,"参数错误"),
    ;

    // 响应是否成功
    private Boolean success;
    // 响应状态码
    private Integer code;
    // 响应信息
    private String message;

    ResultCodeEnum(boolean success, Integer code, String message) 
        this.success = success;
        this.code = code;
        this.message = message;

统一结果类

第5个属于自定义返回，利用前4者可定义统一返回对象

注意：

外接只可以调用统一返回类的方法，不可以直接创建，影刺构造器私有；
内置静态方法，返回对象；
为便于自定义统一结果的信息，建议使用链式编程，将返回对象设类本身，即return this;
响应数据由于为json格式，可定义为JsonObject或Map形式；

@Data
public class R 
    private Boolean success;

    private Integer code;

    private String message;

    private Map<String, Object> data = new HashMap<>();

    // 构造器私有
    private R()

    // 通用返回成功
    public static R ok() 
        R r = new R();
        r.setSuccess(ResultCodeEnum.SUCCESS.getSuccess());
        r.setCode(ResultCodeEnum.SUCCESS.getCode());
        r.setMessage(ResultCodeEnum.SUCCESS.getMessage());
        return r;
    

    // 通用返回失败，未知错误
    public static R error() 
        R r = new R();
        r.setSuccess(ResultCodeEnum.UNKNOWN_ERROR.getSuccess());
        r.setCode(ResultCodeEnum.UNKNOWN_ERROR.getCode());
        r.setMessage(ResultCodeEnum.UNKNOWN_ERROR.getMessage());
        return r;
    

    // 设置结果，形参为结果枚举
    public static R setResult(ResultCodeEnum result) 
        R r = new R();
        r.setSuccess(result.getSuccess());
        r.setCode(result.getCode());
        r.setMessage(result.getMessage());
        return r;
    

    /**------------使用链式编程，返回类本身-----------**/

    // 自定义返回数据
    public R data(Map<String,Object> map) 
        this.setData(map);
        return this;
    

    // 通用设置data
    public R data(String key,Object value) 
        this.data.put(key, value);
        return this;
    

    // 自定义状态信息
    public R message(String message) 
        this.setMessage(message);
        return this;
    

    // 自定义状态码
    public R code(Integer code) 
        this.setCode(code);
        return this;
    

    // 自定义返回结果
    public R success(Boolean success) 
        this.setSuccess(success);
        return this;

控制层返回

视图层使用统一结果

@RestController
@RequestMapping("/api/v1/users")
public class TeacherAdminController 

    @Autowired
    private UserService userService;

    @GetMapping
    public R list() 
        List<Teacher> list = teacherService.list(null);
        return R.ok().data("itms", list).message("用户列表");

json结果


  "success": true,
  "code": 20000,
  "message": "查询用户列表",
  "data": 
    "itms": [
      
        "id": "1",
        "username": "admin",
        "role": "ADMIN",
        "deleted": false,
        "gmtCreate": "2019-12-26T15:32:29",
        "gmtModified": "2019-12-26T15:41:40"
      ,
        "id": "2",
        "username": "zhangsan",
        "role": "USER",
        "deleted": false,
        "gmtCreate": "2019-12-26T15:32:29",
        "gmtModified": "2019-12-26T15:41:40"
      
    ]

统一结果类的使用参考了mybatis-plus中R对象的设计

统一异常处理

使用统一返回结果时，还有一种情况，就是程序的保存是由于运行时异常导致的结果，有些异常我们可以无法提前预知，不能正常走到我们return的R对象返回。

因此，我们需要定义一个统一的全局异常来捕获这些信息，并作为一种结果返回控制层

@ControllerAdvice

该注解为统一异常处理的核心

是一种作用于控制层的切面通知（Advice），该注解能够将通用的@ExceptionHandler、@InitBinder和@ModelAttributes方法收集到一个类型，并应用到所有控制器上

该类中的设计思路：

使用@ExceptionHandler注解捕获指定或自定义的异常；
使用@ControllerAdvice集成@ExceptionHandler的方法到一个类中；
必须定义一个通用的异常捕获方法，便于捕获未定义的异常信息；
自定一个异常类，捕获针对项目或业务的异常;
异常的对象信息补充到统一结果枚举中；

自定义全局异常类

@Data
public class CMSException extends RuntimeException 
    private Integer code;

    public CMSException(Integer code, String message) 
        super(message);
        this.code = code;
    

    public CMSException(ResultCodeEnum resultCodeEnum) 
        super(resultCodeEnum.getMessage());
        this.code = resultCodeEnum.getCode();
    

    @Override
    public String toString() 
        return "CMSException" + "code=" + code + ", message=" + this.getMessage() + '';

统一异常处理器

// ...
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseBody;

@ControllerAdvice
public class GlobalExceptionHandler 

    /**-------- 通用异常处理方法 --------**/
    @ExceptionHandler(Exception.class)
    @ResponseBody
    public R error(Exception e) 
        e.printStackTrace();
        return R.error();    // 通用异常结果
    

    /**-------- 指定异常处理方法 --------**/
    @ExceptionHandler(NullPointerException.class)
    @ResponseBody
    public R error(NullPointerException e) 
        e.printStackTrace();
        return R.setResult(ResultCodeEnum.NULL_POINT);
    

    @ExceptionHandler(HttpClientErrorException.class)
    @ResponseBody
    public R error(IndexOutOfBoundsException e) 
        e.printStackTrace();
        return R.setResult(ResultCodeEnum.HTTP_CLIENT_ERROR);
    

    /**-------- 自定义定异常处理方法 --------**/
    @ExceptionHandler(CMSException.class)
    @ResponseBody
    public R error(CMSException e) 
        e.printStackTrace();
        return R.error().message(e.getMessage()).code(e.getCode());

控制层展示

以下为展示当遇到null指定异常时，返回的结果信息


  "success": false,
  "code": 20007,
  "message": "空指针异常",
  "data":

统一日志收集

日志是追踪错误定位问题的关键，尤其在生产环境中，需要及时修复热部署，不会提供开发者debug的环境，此时日志将会是最快解决问题的关键

日志的框架比较丰富，由于spring boot对logback的集成，因此推荐使用logback在项目中使用。

Spring Boot 基础就不介绍了，推荐下这个实战教程：

https://github.com/javastacks/spring-boot-best-practice

Logback

配置

以下直接贴出配置信息，介绍信息科直接参考备注

<?xml version="1.0" encoding="UTF-8"?>
<!-- 日志级别从低到高分为TRACE < DEBUG < INFO < WARN < ERROR < FATAL，如果设置为WARN，则低于WARN的信息都不会输出 -->
<!-- scan:当此属性设置为true时，配置文档如果发生改变，将会被重新加载，默认值为true -->
<!-- scanPeriod:设置监测配置文档是否有修改的时间间隔，如果没有给出时间单位，默认单位是毫秒。
                 当scan为true时，此属性生效。默认的时间间隔为1分钟。 -->
<!-- debug:当此属性设置为true时，将打印出logback内部日志信息，实时查看logback运行状态。默认值为false。 -->
<configuration  scan="true" scanPeriod="10 seconds">
    <contextName>logback</contextName>

    <!-- name的值是变量的名称，value的值时变量定义的值。通过定义的值会被插入到logger上下文中。定义后，可以使“$”来使用变量。 -->
    <property name="log.path" value="D:/Documents/logs/edu" />

    <!--0. 日志格式和颜色渲染 -->
    <!-- 彩色日志依赖的渲染类 -->
    <conversionRule conversionWord="clr" converterClass="org.springframework.boot.logging.logback.ColorConverter" />
    <conversionRule conversionWord="wex" converterClass="org.springframework.boot.logging.logback.WhitespaceThrowableProxyConverter" />
    <conversionRule conversionWord="wEx" converterClass="org.springframework.boot.logging.logback.ExtendedWhitespaceThrowableProxyConverter" />
    <!-- 彩色日志格式 -->
    <property name="CONSOLE_LOG_PATTERN" value="$CONSOLE_LOG_PATTERN:-%clr(%dyyyy-MM-dd HH:mm:ss.SSS)faint %clr($LOG_LEVEL_PATTERN:-%5p) %clr($PID:- )magenta %clr(---)faint %clr([%15.15t])faint %clr(%-40.40logger39)cyan %clr(:)faint %m%n$LOG_EXCEPTION_CONVERSION_WORD:-%wEx"/>

    <!--1. 输出到控制台-->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <!--此日志appender是为开发使用，只配置最底级别，控制台输出的日志级别是大于或等于此级别的日志信息-->
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>debug</level>
        </filter>
        <encoder>
            <Pattern>$CONSOLE_LOG_PATTERN</Pattern>
            <!-- 设置字符集 -->
            <charset>UTF-8</charset>
        </encoder>
    </appender>

    <!--2. 输出到文档-->
    <!-- 2.1 level为 DEBUG 日志，时间滚动输出  -->
    <appender name="DEBUG_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在记录的日志文档的路径及文档名 -->
        <file>$log.path/edu_debug.log</file>
        <!--日志文档输出格式-->
        <encoder>
            <pattern>%dyyyy-MM-dd HH:mm:ss.SSS [%thread] %-5level %logger50 - %msg%n</pattern>
            <charset>UTF-8</charset> <!-- 设置字符集 -->
        </encoder>
        <!-- 日志记录器的滚动策略，按日期，按大小记录 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 日志归档 -->
            <fileNamePattern>$log.path/web-debug-%dyyyy-MM-dd.%i.log</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日志文档保留天数-->
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <!-- 此日志文档只记录debug级别的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>debug</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 2.2 level为 INFO 日志，时间滚动输出  -->
    <appender name="INFO_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在记录的日志文档的路径及文档名 -->
        <file>$log.path/edu_info.log</file>
        <!--日志文档输出格式-->
        <encoder>
            <pattern>%dyyyy-MM-dd HH:mm:ss.SSS [%thread] %-5level %logger50 - %msg%n</pattern>
            <charset>UTF-8</charset>
        </encoder>
        <!-- 日志记录器的滚动策略，按日期，按大小记录 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 每天日志归档路径以及格式 -->
            <fileNamePattern>$log.path/web-info-%dyyyy-MM-dd.%i.log</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日志文档保留天数-->
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <!-- 此日志文档只记录info级别的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>info</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 2.3 level为 WARN 日志，时间滚动输出  -->
    <appender name="WARN_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在记录的日志文档的路径及文档名 -->
        <file>$log.path/edu_warn.log</file>
        <!--日志文档输出格式-->
        <encoder>
            <pattern>%dyyyy-MM-dd HH:mm:ss.SSS [%thread] %-5level %logger50 - %msg%n</pattern>
            <charset>UTF-8</charset> <!-- 此处设置字符集 -->
        </encoder>
        <!-- 日志记录器的滚动策略，按日期，按大小记录 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>$log.path/web-warn-%dyyyy-MM-dd.%i.log</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日志文档保留天数-->
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <!-- 此日志文档只记录warn级别的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>warn</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 2.4 level为 ERROR 日志，时间滚动输出  -->
    <appender name="ERROR_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在记录的日志文档的路径及文档名 -->
        <file>$log.path/edu_error.log</file>
        <!--日志文档输出格式-->
        <encoder>
            <pattern>%dyyyy-MM-dd HH:mm:ss.SSS [%thread] %-5level %logger50 - %msg%n</pattern>
            <charset>UTF-8</charset> <!-- 此处设置字符集 -->
        </encoder>
        <!-- 日志记录器的滚动策略，按日期，按大小记录 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>$log.path/web-error-%dyyyy-MM-dd.%i.log</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日志文档保留天数-->
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <!-- 此日志文档只记录ERROR级别的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!--
        <logger>用来设置某一个包或者具体的某一个类的日志打印级别、
        以及指定<appender>。<logger>仅有一个name属性，
        一个可选的level和一个可选的addtivity属性。
        name:用来指定受此logger约束的某一个包或者具体的某一个类。
        level:用来设置打印级别，大小写无关：TRACE, DEBUG, INFO, WARN, ERROR, ALL 和 OFF，
              还有一个特俗值INHERITED或者同义词NULL，代表强制执行上级的级别。
              如果未设置此属性，那么当前logger将会继承上级的级别。
        addtivity:是否向上级logger传递打印信息。默认是true。
        <logger name="org.springframework.web" level="info"/>
        <logger name="org.springframework.scheduling.annotation.ScheduledAnnotationBeanPostProcessor" level="INFO"/>
    -->

    <!--
        使用mybatis的时候，sql语句是debug下才会打印，而这里我们只配置了info，所以想要查看sql语句的话，有以下两种操作：
        第一种把<root level="info">改成<root level="DEBUG">这样就会打印sql，不过这样日志那边会出现很多其他消息
        第二种就是单独给dao下目录配置debug模式，代码如下，这样配置sql语句会打印，其他还是正常info级别：
        【logging.level.org.mybatis=debug logging.level.dao=debug】
     -->

    <!--
        root节点是必选节点，用来指定最基础的日志输出级别，只有一个level属性
        level:用来设置打印级别，大小写无关：TRACE, DEBUG, INFO, WARN, ERROR, ALL 和 OFF，
        不能设置为INHERITED或者同义词NULL。默认是DEBUG
        可以包含零个或多个元素，标识这个appender将会添加到这个logger。
    -->

    <!-- 4. 最终的策略 -->
    <!-- 4.1 开发环境:打印控制台-->
    <springProfile name="dev">
        <logger name="com.cms" level="info"/>
        <root level="info">
            <appender-ref ref="CONSOLE" />
            <appender-ref ref="DEBUG_FILE" />
            <appender-ref ref="INFO_FILE" />
            <appender-ref ref="WARN_FILE" />
            <appender-ref ref="ERROR_FILE" />
        </root>
    </springProfile>


    <!-- 4.2 生产环境:输出到文档-->
    <springProfile name="pro">
        <logger name="com.cms" level="warn"/>
        <root level="info">
            <appender-ref ref="ERROR_FILE" />
            <appender-ref ref="WARN_FILE" />
        </root>
    </springProfile>

</configuration>

日志收集异常信息

日志信息往往伴随着异常信息的输出，因此，我们需要修改统一异常的处理器，将异常信息以流的方式写到日志文件中

异常信息文件工具类

@Slf4j
public class ExceptionUtil 

    /**
     * 打印异常信息
     */
    public static String getMessage(Exception e) 
        String swStr = null;
        try (StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw)) 
            e.printStackTrace(pw);
            pw.flush();
            sw.flush();
            swStr = sw.toString();
         catch (IOException ex) 
            ex.printStackTrace();
            log.error(ex.getMessage());
        
        return swStr;

修改统一异常处理器，将异常方法中的直接打印改为日志输入并打印

// ...
import lombok.extern.slf4j.Slf4j;

@ControllerAdvice
@Slf4j
public class GlobalExceptionHandler 

    /**-------- 通用异常处理方法 --------**/
    @ExceptionHandler(Exception.class)
    @ResponseBody
    public R error(Exception e) 
        // e.printStackTrace();
        log.error(ExceptionUtil.getMessage(e));
        return R.error();
    

   // ...

注意

日志的环境即spring.profiles.acticve，跟随项目启动；
启动后，即可到自定目录查找到生成的日志文件；
本地idea调试时，推荐Grep Console插件可实现控制台的自定义颜色输出

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.别再写满屏的爆爆爆炸类了，试试装饰器模式，这才是优雅的方式！！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！

以上是关于MySQL 处理大数据表的 3 种方案，写的太好了，建议收藏！！的主要内容，如果未能解决你的问题，请参考以下文章

Spring Boot 日期时间处理总结，写的太好了。。

支付宝支付加密规则梳理，写的太好了！

给跪了，这个 ZooKeeper 源码分析写的太好了！

关于单点登录原理与简单实现，写的太好了一看就懂！

20 个实例玩转 Java 8 Stream，写的太好了！