万字长文带你走进MySql优化(系统层面优化、软件层面优化、SQL层面优化)_mysql删除大量数据的优化

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

采用分布式架构

如果单台服务器无法满足需求，可以采用分布式架构来提高 MySQL 的性能。常用的分布式架构包括主从复制、读写分离等。

扩展

1. 主从复制:主从复制是指将一个 MySQL 实例（主库）中的数据复制到其他 MySQL 实例（从库）中，从库中的数据与主库中的数据保持一致。主从复制的主要优点是：

• 提高系统的可用性，当主库故障时，可以快速切换到从库继续提供服务；
• 分担主库的负载，可以将读请求分发到从库中处理，减轻主库的负担。

2. 读写分离:读写分离是指将读请求和写请求分别分发到不同的 MySQL 实例中处理。写请求只发送到主库中，而读请求则发送到从库中。读写分离的主要优点是：

• 分担主库的负载，将读请求和写请求分别分发到不同的 MySQL 实例中处理，减轻主库的负
• 提高系统的读性能，将读请求分发到从库中处理，减轻主库的负担；

使用缓存

使用缓存优化 MySQL 可以大幅提升系统性能，减少数据库的压力。

常用的缓存方案有以下几种：

• 前端缓存

前端缓存是指将数据缓存在客户端（如浏览器）中，减少服务器端的请求。前端缓存可以通过 HTTP 缓存头来实现，例如，可以设置 Cache-Control、Expires、Last-Modified 等缓存头。

• 应用程序缓存

应用程序缓存是指将数据缓存在应用程序的内存中，减少对数据库的访问。应用程序缓存可以使用一些缓存框架来实现，例如，Redis、Memcached 等。在使用应用程序缓存时需要注意缓存数据的有效期，避免缓存数据过期或失效。

• 数据库缓存

数据库缓存是指将数据缓存在数据库的内存中，减少磁盘 I/O 的访问。数据库缓存可以使用 MySQL 内置的缓存机制来实现，例如，使用 Query Cache、InnoDB Buffer Pool 等。

扩展:使用缓存优化 MySQL 需要注意以下几点：

1. 缓存数据的有效期，避免缓存数据过期或失效。
2. 缓存数据的一致性，需要确保缓存数据与数据库中的数据保持一致。
3. 缓存数据的大小，需要根据系统的需求和硬件资源来确定缓存的大小。
4. 缓存数据的并发访问，需要考虑多线程并发访问时的锁竞争问题。
5. 缓存的选择，需要根据系统的需求和硬件资源来选择合适的缓存方案，例如，前端缓存、应用程序缓存、数据库缓存等。

使用搜索引擎

使用 Elasticsearch 进行查询可以加速查询操作，并且可以提供强大的搜索和分析功能。

注意⚠️

• 在使用 Elasticsearch 进行查询时，需要注意 Elasticsearch 和 MySQL 之间的数据一致性问题。由于 Elasticsearch 中的数据可能会有延迟，因此需要考虑如何处理数据同步和数据一致性问题。
• 需要注意 Elasticsearch 和 MySQL 之间的数据一致性问题。由于 Elasticsearch 中的数据可能会有延迟，因此需要考虑如何处理数据同步和数据一致性问题。

软件层面优化

调整 MySQL 参数配置

通过修改 MySQL 的配置参数来优化 MySQL 的性能，例如，修改缓冲池的大小、修改连接数的数量、缓存池大小等等。

扩展

• innodb_buffer_pool_size：这个参数配置了 InnoDB 存储引擎使用的内存池的大小，可以用来控制 InnoDB 存储引擎的缓存区大小。一般来说，innodb_buffer_pool_size 的大小应该是系统内存的 50%~70%。
• innodb_log_file_size：这个参数配置了 InnoDB 存储引擎的日志文件大小，可以影响到事务的提交速度和数据恢复速度。一般来说，innodb_log_file_size 的大小应该是 1GB~2GB 左右。
• query_cache_size：这个参数配置了查询缓存的大小，可以提高查询的速度。但需要注意，使用查询缓存会增加 MySQL 服务器的 CPU 负载，并且会占用额外的内存，因此需要根据实际情况来决定是否启用查询缓存。
• max_connections：这个参数配置了 MySQL 服务器的最大连接数，可以控制 MySQL 服务器的并发连接数。需要根据实际情况来决定 max_connections 的大小，一般来说，max_connections 的值应该大于服务器上同时在线的最大连接数。
• key_buffer_size：这个参数配置了 MyISAM 存储引擎的索引缓存的大小，可以提高查询的速度。但需要注意，MyISAM 存储引擎的索引缓存只能缓存索引，无法缓存表数据，因此只有在使用 MyISAM 存储引擎时才需要配置 key_buffer_size。

定期清理无用数据

定期清理无用数据可以帮助我们减少数据存储空间，提高数据库的性能，以及减少备份和恢复数据的时间和成本

扩展

• 清理日志文件：MySQL 中的错误日志、二进制日志和慢查询日志等日志文件可能会占用大量的存储空间，需要定期清理。
• 清理过期数据：在 MySQL 中，经常会产生一些过期的数据，例如历史数据、日志数据等，这些数据可以定期清理。可以通过设置自动删除或手动删除的方式来清理过期数据。
• 清理未使用的表和索引：MySQL 中有些表和索引可能已经不再使用，但仍然占用着存储空间。可以通过查询系统表来找出这些未使用的表和索引，然后进行清理。
• 清理无效的备份文件：MySQL 中的备份文件可能会占用大量的存储空间，需要定期清理无效的备份文件，保留最新的有效备份文件。
• 优化数据存储方式：MySQL 中有很多数据存储方式，例如 MyISAM、InnoDB、MEMORY 等，不同的存储方式对空间的使用效率也不同。可以根据实际情况选择合适的存储方式，优化数据的存储方式。

创建索引

索引类似于字典的目录，可以提高查询的效率。

索引从物理上可以分为：聚集索引，非聚集索引

从逻辑上可以分为：普通索引，唯一索引，主键索引，联合索引，全文索引

创建索引可以提高数据库查询性能，但是不是所有场景都适合创建索引。

创建索引

普通索引

适用场景：对于一些较小的表或者经常需要进行查询的表，可以使用普通索引来提高查询效率。

CREATE INDEX idx_name ON table_name(column_name);

唯一索引

适用场景：当需要保证某个字段的唯一性时，可以使用唯一索引。

CREATE UNIQUE INDEX idx_name ON table_name(column_name);

全文索引

适用场景：当需要进行全文搜索时，可以使用全文索引。

CREATE FULLTEXT INDEX idx_name ON table_name(column_name);

组合索引

适用场景：当查询条件中涉及多个字段时，可以使用组合索引来提高查询效率。

CREATE INDEX idx_name ON table_name(column1, column2, ...);

空间索引

适用场景：当需要对地理位置进行查询时，可以使用空间索引。

CREATE SPATIAL INDEX idx_name ON table_name(column_name);

主键索引

适用场景：当需要对某个字段进行唯一标识时，可以使用主键索引。

ALTER TABLE table_name ADD PRIMARY KEY(column_name);

外键索引

适用场景：当需要对表之间的关联进行查询时，可以使用外键索引。

ALTER TABLE table_name ADD FOREIGN KEY(column_name) REFERENCES ref_table(ref_column);

索引前缀

适用场景：当某个字段值的长度较长，可以使用索引前缀来提高查询效率。

注意⚠️：使用索引前缀时，可能会导致索引失效或者查询结果不准确，需要根据实际情况进行选择。

CREATE INDEX idx_name ON table_name(column_name(prefix_length));

适合创建索引的场景

• 经常用作查询条件的列:如果一个列经常用作查询条件，那么为这个列创建索引可以提高查询性能。例如，用户表中的用户名、邮箱、手机号等列。
• 经常被用于连接的列:如果一个列经常被用于连接多个表，那么为这个列创建索引可以提高连接查询的性能。例如，在一个订单表和商品表中，订单表中的商品编号和商品表中的商品编号经常被用于连接查询。
• 经常被用于排序的列:如果一个列经常被用于排序，那么为这个列创建索引可以提高排序查询的性能。例如，新闻网站中的文章发布时间、评论数等列。
• 经常被用于分组的列:如果一个列经常被用于分组，那么为这个列创建索引可以提高分组查询的性能。例如，在一个销售数据表中，按照产品类别分组的查询。
• 大表中的常用列:在大表中，查询性能通常较差。为了提高查询性能，可以为常用的列创建索引，例如，大表中的订单号、产品编号等。

不适合创建索引的场景

• 列的数据分布不均匀:如果一个列的数据分布不均匀，那么为这个列创建索引可能会降低查询性能，因为数据库查询优化器会认为使用索引查询的代价比全表扫描高。例如，在一个性别列中，如果大部分数据是男性，那么为这个列创建索引可能会降低查询性能。
• 小表:如果一个表很小，那么为这个表创建索引的代价可能比使用全表扫描更高，因为查询优化器需要额外的代价来使用索引。通常情况下，小于1000行的表不适合创建索引。
• 经常更新的列:如果一个列经常被更新，那么为这个列创建索引可能会降低数据库写入性能，因为每次更新操作都需要更新索引。例如，一个日志表中的时间戳列。
• 数据类型是 TEXT、BLOB 等:一般对于数据类型是 TEXT、BLOB 等的列，创建索引的代价非常高，因为这些列的数据比较大，索引也会很大，导致查询性能下降。

优化表结构

• 避免使用过大的字段类型，可以使用合适的数据类型来减少存储空间的浪费；
• 避免使用 NULL，因为 NULL 会增加存储空间和查询复杂度；
• 避免使用 BLOB 和 TEXT 类型的字段，因为这些字段会影响查询性能；
• 对于大型的表，可以使用分区表来提高查询性能。

分库分表

MySQL 分库分表是一种常用的数据库水平扩展方式，可以有效地解决单个 MySQL 实例无法满足高并发、海量数据存储等需求的问题。可以将一个大型的数据库拆分成多个小型的数据库，每个小型数据库中包含一部分数据。同时，可以将一个大型的表拆分成多个小型的表，每个小型表中包含一部分数据。这种方式可以解决单一数据库或表过大导致的性能瓶颈问题，提高系统的可扩展性和可用性。

扩展

分库分表的具体实现方法有以下几种：

• 垂直分库

垂直分库是将一个大型的数据库拆分成多个小型的数据库，每个小型数据库中包含一部分相关的表。例如，可以将一个电商系统中的用户表、订单表、商品表等拆分成多个小型数据库，每个小型数据库中只包含一部分相关的表。垂直分库的优点是易于管理，每个小型数据库中包含的表都具有相似的特点。缺点是可能会导致数据不一致，例如，当一个表的数据需要更新时，可能需要在多个小型数据库中进行更新操作。

• 水平分库

水平分库是将一个大型的数据库中的表按照某种规则分散到多个小型数据库中，每个小型数据库中包含一部分表。例如，可以将一个电商系统中的订单表按照订单号的范围分散到多个小型数据库中，每个小型数据库中包含一部分订单数据。水平分库的优点是易于扩展，可以将新的小型数据库添加到系统中。缺点是可能会导致数据不一致，例如，当一个表的数据需要更新时，可能需要在多个小型数据库中进行更新操作。

• 水平分表

水平分表是将一个大型的表按照某种规则分散到多个小型表中，每个小型表中包含一部分数据。例如，可以将一个电商系统中的订单表按照订单号的范围分散到多个小型表中，每个小型表中包含一部分订单数据。水平分表的优点是易于扩展，可以将新的小型表添加到系统中。缺点是可能会导致查询性能下降，因为查询可能需要在多个小型表中进行。

SQL优化

explain执行计划

在看具体SQL优化之前，可以先了解一下explain执行计划，使用 EXPLAIN 命令来获取一个 SQL 查询语句的执行计划。执行计划描述了 MySQL 数据库系统如何执行查询，并且可以用来分析和优化查询语句。

样本sql

CREATE TABLE students (
    id INT NOT NULL AUTO\_INCREMENT,
    name VARCHAR(50) NOT NULL,
    email VARCHAR(50) NOT NULL,
    PRIMARY KEY (id)
);
ALTER TABLE students ADD UNIQUE INDEX email_UNIQUE (email);
#explain执行计划
EXPLAIN select \* from students where email ! "123";

执行结果

字段含义

1. id：查询的唯一标识符。如果查询包含子查询，则每个子查询都有一个唯一标识符。
2. select_type：查询的类型，例如 SIMPLE（简单查询）、PRIMARY（主查询）或 UNION（联合查询）等。
3. table：查询的表名。
4. partitions：查询的分区。
5. type:连接类型【SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是

consts 最好。】(执行性能排名:system > const > eq_ref > ref > range > index > all。)

* system：表仅有一行，基本用不到；
* const：表最多一行数据配合，主键查询时触发较多；
* eq\_ref：对于每个来自于前面的表的行组合，从该表中读取一行。这可能是最好的联接类型，除了const类型；
* ref：对于每个来自于前面的表的行组合，所有有匹配索引值的行将从这张表中读取；
* range：只检索给定范围的行，使用一个索引来选择行。当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符，用常量比较关键字列时，可以使用range；
* index：该联接类型与ALL相同，除了只有索引树被扫描。这通常比ALL快，因为索引文件通常比数据文件小；
* all：全表扫描；

6. possible_keys：查询可能使用的索引列表。

7. key：查询实际使用的索引。

8. key_len：索引的长度。

9. ref：使用索引的列或常数。

10. rows：MySQL 估计将会扫描的行数。

11. filtered：使用条件过滤后，剩余的行数百分比。

12. Extra：额外的信息，例如使用了哪些索引或排序方式等。

    • Using index：只从索引树中获取信息，而不需要回表查询；
    • Using where：WHERE子句用于限制哪一个行匹配下一个表或发送到客户。除非你专门从表中索取或检查所有行，如果Extra值不为Using where并且表联接类型为ALL或index，查询可能会有一些错误。需要回表查询。
    • Using temporary：mysql常建一个临时表来容纳结果，典型情况如查询包含可以按不同情况列出列的GROUP BY和ORDER BY子句时；

Select 优化

避免 SELECT * 查询，只查需要的字段

1. 性能问题：使用"SELECT字段"可以提高查询性能。当使用"SELECT *"时，MySQL需要检索表中的所有字段，包括不需要的字段，这会占用更多的系统资源和时间。而使用"SELECT字段"可以减少检索的数据量，从而提高查询性能。
2. 可读性和维护性问题：使用"SELECT字段"可以提高查询的可读性和维护性。当使用"SELECT *"时，查询结果中的字段顺序可能会发生变化，这会给程序员带来一定的困扰。而使用"SELECT字段"可以明确指定查询的字段，使得查询结果的字段顺序和查询语句中的字段顺序一致，更易于程序员理解和维护。
3. 安全问题：使用"SELECT字段"可以提高查询的安全性。当使用"SELECT *"时，如果表结构发生变化，可能会将不需要的字段暴露给外部，这会给系统带来潜在的安全风险。而使用"SELECT字段"可以避免暴露不需要的字段，从而提高查询的安全性。

尽量避免or查询

or没有索引的字段会走全表查询，有必要时可以让拆成多条sql，让没有索引的字段and有索引的字段

如a，c字段有单值索引

#这条语句走全表扫描
select \* from test where a = "xxx" or b = "xxx";

可以优化成下面语句

#分开查询后续合并结果
select \* from test where a = "xxx";
select \* from test where c = "xxx" and b = "xxx";

#或者单次查询
select \* from test where a = "xxx" or a in (select a from test where c = "xxx" and b = "xxx";);

使用 UNION ALL 替代 UNION

因为 UNION ALL 不会去重，速度更快，UNION 会去重，即将两个结果集中相同的记录合并成一条记录。如果我们确定合并的结果集中不会出现重复记录，那么我们可以使用 UNION ALL 来代替 UNION 操作。

注意⚠️:使用 UNION ALL 可能会增加网络传输的数据量，因为结果集中可能会有重复的记录。因此，我们需要在实际应用中根据具体情况来选择使用 UNION 还是 UNION ALL。

避免使用子查询，可以改成 JOIN

• 执行子查询时, MYSQL需要为内层查询语句的查询结果建立一个临时表。然后外层查询语句从临时表中查询记录。查询完毕后,再撤销这些临时表。连接(JOIN)之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑
• 更容易优化查询：使用 JOIN 操作可以更好地利用索引，提高查询的效率。
• 可读性更好：使用 JOIN 操作可以使 SQL 语句更加清晰易懂，降低出错的概率。
• 子查询嵌套层数过多会影响可维护性：使用 JOIN 操作可以将查询拆分成多个表，易于维护和优化。

有必要时在应用层 ORDER BY 和 GROUP BY

避免使用不必要的 ORDER BY 和 GROUP BY 操作，可以在应用层进行排序和分组。

1. 减少数据库负担：ORDER BY 和 GROUP BY 操作需要对结果集进行排序或分组，会增加数据库的负担，特别是当结果集非常大时，效率会更低。而在应用层进行排序或分组可以减轻数据库的压力。
2. 灵活性更高：在应用层进行排序或分组可以更加灵活地控制结果集的处理方式，可以根据具体需求进行自定义排序或分组操作。

避免使用 LIKE ‘%value%’ 或 LIKE ‘%value’

索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。以通配符（%）开头的搜索字符串会强制数据库系统进行全表扫描。

尽可能使用前缀搜索：如果可以使用前缀搜索而不是在字符串的任意位置进行匹配，那么查询将更加高效。例如，LIKE ‘value%’ 比 LIKE ‘%value%’ 更加高效

如果非要使用 LIKE ‘%value%’ 或 LIKE ‘%value’，可以采取放在语句末、搜索引擎、离线数据仓库

• 放在带索引查询的语句末:将 LIKE 语句放在 WHERE 子句的末尾可以避免在查询的前面进行全表扫描。(如果查询条件前面的字段是索引查询，在执行like的时候会缩减范围使得查询避免走全表查询)【注意⚠️:如果索引查询后的数据量依旧很大，不建议使用!】
• 搜索引擎:可以使用 Elasticsearch来进行模糊查询，效率更高
• 离线数据仓库:如Hive，有些场景可以使用，查询时长可能会有点久且不能保证实时性
• 使用 REVERSE() 函数：可以先将需要查询的值 value 进行反转，然后将查询条件改写为 LIKE reverse('value')%'，这样可以利用索引加速查询，避免全表扫描。

-- 原查询：
SELECT \* FROM my_table WHERE my_column LIKE '%abc';

-- 优化后的查询：
SELECT \* FROM my_table WHERE REVERSE(my_column) LIKE REVERSE('cba')%;

避免在索引字段上使用函数

在索引字段上运用了函数，导致索引失效。B+ 树提供索引的快速定位能力，来源于同一层兄弟节点的有序性。也就是说，对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。可以在查询后对结果数据字段进行函数操作。

避免隐式类型转换

隐式类型转换会导致索引失效

#如order\_id是varchar类型索引字段，查询时用的整数，底层查询时会做类型转换
select \* from test where order_id = 110717;

表连接时候用小数据集驱动大数据集

小表驱动大表可以减少不必要的表连接，从而达到优化效果

扩展:
       嵌套循环联接（NLJ）算法：循环从第一个表中依次读取行，取到每行再到联接的下一个表中循环匹配。这个过程会重复多次直到剩余的表都被联接了。通过外循环的行去匹配内循环的行，所以内循环的表会被扫描多次。(可以理解为外层循环一次就是一次表连接，以小表1万条，大表1000万条来对比，小表驱动大表来算只需要1万次表连接)

for each row in t1 matching range {
  for each row in t2 matching reference key {
    for each row in t3 {
      if row satisfies join conditions,
          send to client
    }
  }
}

避免在索引字段使用不等值操作(!=、<>)

注意⚠️:当不等值操作作用在普通索引上时，可能索引失效

以下是一些常见情况下不等值操作导致索引失效的情况：

1. 数据类型不匹配：如果不等值操作涉及到不同数据类型的比较，例如将整数列与字符串列进行比较，MySQL 通常无法使用索引。
2. 函数或表达式操作：如果不等值操作中使用了函数或表达式来处理列，例如WHERE LENGTH(column_name) != 5，MySQL 通常无法使用索引，因为它不能对列进行函数计算。
3. OR 连接多个不等值条件：如果你使用 OR 连接多个不等值条件，MySQL 可能会选择不使用索引，因为 OR 连接通常难以优化。例如，WHERE column_name != 'value1' OR column_name != 'value2' 可能会导致索引失效。
4. 使用 IS NULL 或 IS NOT NULL：当你使用 IS NULL 或 IS NOT NULL 条件时，索引可能会失效，因为这些条件与普通的比较条件不同。
5. 索引选择性低：索引选择性指的是索引中不同值的数量与总行数的比例。如果索引的选择性很低，即索引列中的不同值很少，那么 MySQL 可能会选择不使用索引，因为它认为全表扫描更有效。
6. 小表：如果表本身很小，MySQL 可能会选择进行全表扫描而不是使用索引，因为在这种情况下索引的开销可能会超过全表扫描的开销。

inner join 、left join、right join选择

• Inner join 只返回两个表中匹配的记录，不包含左表或右表中没有匹配到的记录。当需要查询两个表中的公共数据时，应该优先使用inner join。
• Left join 返回左表中所有的记录，以及左表和右表中匹配的记录。如果右表中没有匹配到左表中的记录，则返回null值。当需要查询左表的所有记录，并且只需要匹配右表中的一部分记录时，可以使用left join。
• Right join 返回右表中所有的记录，以及左表和右表中匹配的记录。如果左表中没有匹配到右表中的记录，则返回null值。当需要查询右表的所有记录，并且只需要匹配左表中的一部分记录时，可以使用right join。

先过滤，再GROUP BY、ORDER BY

在SQL查询语句中，过滤（Filtering）、分组（Grouping）和排序（Sorting）是常见的操作。正确的顺序应该是先过滤、再分组、最后排序。

1. 减少操作的数据量,如果不先过滤数据，查询引擎可能需要对整个数据集进行聚合操作，这会消耗大量的时间和计算资源。
2. 提高查询效率,如果不先过滤数据，查询引擎需要对大量无用的数据进行排序或分组操作，这会降低查询效率。
3. 优化查询计划，查询引擎可以通过优化查询计划，选择更高效的执行计划来执行查询。如果不先过滤数据，查询引擎可能无法有效地优化查询计划，导致查询效率低下。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

再GROUP BY、ORDER BY

在SQL查询语句中，过滤（Filtering）、分组（Grouping）和排序（Sorting）是常见的操作。正确的顺序应该是先过滤、再分组、最后排序。

1. 减少操作的数据量,如果不先过滤数据，查询引擎可能需要对整个数据集进行聚合操作，这会消耗大量的时间和计算资源。
2. 提高查询效率,如果不先过滤数据，查询引擎需要对大量无用的数据进行排序或分组操作，这会降低查询效率。
3. 优化查询计划，查询引擎可以通过优化查询计划，选择更高效的执行计划来执行查询。如果不先过滤数据，查询引擎可能无法有效地优化查询计划，导致查询效率低下。

[外链图片转存中…(img-7ARtXUNu-1715377195749)]
[外链图片转存中…(img-3FjwYJRU-1715377195749)]
[外链图片转存中…(img-tqpDmZqa-1715377195749)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取