一、引言​

在当今数字化时代，应用系统面临着日益增长的数据处理和高并发访问的挑战。为了提升系统性能、降低数据库负，缓存技术成为了关键手段之一。MyBatis-Plus 作为一款广泛应用的持久层框架，其缓存机制在优化数据访问方面发挥着重要作用。本文将聚焦于基于云监控台的 MyBatis-Plus 缓存策略优化，深入探讨一级缓存和二级缓存的原理、配置及优化策略，旨在为开发者提供全面且实用的性能优化指导。​

二、MyBatis-Plus 缓存机制概述​

2.1 缓存的重要性​

缓存就像是系统中的 “高速通道”，它存储了频繁访问的数据副本。当应用程序需要读取数据时，首先从缓存中查找。如果缓存中存在所需数据，就可以直接返回，避了与数据库的交互，大大减少了数据读取的时间，提升了系统的响应速度。同时，缓存能够分担数据库的部分负，尤其在高并发场景下，能够有效防止数据库因大量请求而不堪重负，从而保障系统的稳定性和可用性。​

2.2 MyBatis-Plus 缓存体系结构​

MyBatis-Plus 的缓存体系主要由一级缓存和二级缓存构成。这两级缓存相互配合，为系统提供了多层次的数据缓存支持。一级缓存作用于 SqlSession 层面，在同一个 SqlSession 内，相同的查询操作会优先从一级缓存中获取结果；二级缓存则是跨 SqlSession 的，它可以在多个 SqlSession 之间共享缓存数据，进一步扩大了缓存的覆盖范围。​

三、一级缓存详解​

3.1 一级缓存的原理​

3.1.1 缓存的作用范围​

一级缓存的作用范围限定在一个 SqlSession 之内。当我们在一个 SqlSession 中执行查询操作时，MyBatis-Plus 会将查询结果存储在一级缓存中。只要这个 SqlSession 没有关闭，后续如果再次执行相同的查询，MyBatis-Plus 会直接从一级缓存中返回结果，而不会再次查询数据库。例如，在一个业务方法中，我们连续两次调用查询用户信息的方法，如果这两次调用在同一个 SqlSession 内，第二次查询就会命中一级缓存，从而快速获取数据。​

3.1.2 缓存的存储方式​

一级缓存通常采用哈希表等数据结构来存储数据。哈希表具有快速查找的特性，能够高效地根据查询语句和参数来定位缓存中的数据。当执行查询时，MyBatis-Plus 会将查询语句、参数以及查询结果封装成一个缓存条目，存储在哈希表中。在后续的查询中，通过计算查询语句和参数的哈希值，快速在哈希表中查找对应的缓存条目。​

3.2 一级缓存的工作流程​

3.2.1 查询时的缓存命中与未命中处理​

当执行查询操作时，MyBatis-Plus 首先会检查一级缓存中是否存在与当前查询语句和参数匹配的缓存数据。如果命中缓存，就直接返回缓存中的数据，整个过程快速高效，无需与数据库进行交互。例如，在一个电商系统中，用户频繁查看商品详情，如果商品信息在一级缓存中命中，就能迅速将商品详情展示给用户。​

若一级缓存未命中，MyBatis-Plus 会向数据库发送查询请求，获取数据后，将数据存储到一级缓存中，以便后续相同查询能够命中缓存。在这个过程中，数据库的查询结果会经过一系列处理，如数据转换、封装等，然后才被存入一级缓存。​

3.2.2 数据更新对一级缓存的影响​

当在一个 SqlSession 中执行数据更新操作（如插入、更新、删除）时，MyBatis-Plus 会自动清空一级缓存。这是为了保证数据的一致性，因为数据更新后，缓存中的旧数据可能已经不再准确。例如，在一个用户管理系统中，如果更新了用户的手机号码，此时一级缓存中关于该用户的旧信息就需要被清除，否则后续查询可能会返回错误的手机号码。清空一级缓存后，下次查询该数据时，会从数据库重新获取最新数据并再次存入一级缓存。​

3.3 一级缓存的优点与局限性​

3.3.1 优点​

一级缓存能够显著减少在同一个 SqlSession 内的重复查询次数，提升查询效率。由于缓存数据存储在内存中，读取速度极快，对于频繁执行相同查询的业务场景，如在一个事务中多次查询相同数据，一级缓存能够极大地提高系统性能，减少数据库的负压力。同时，一级缓存的实现相对简单，不需要额外的复杂配置，MyBatis-Plus 默认就开启了一级缓存功能，开发者可以直接受益于其带来的性能提升。​

3.3.2 局限性​

一级缓存的作用范围仅在单个 SqlSession 内，当 SqlSession 关闭后，一级缓存中的数据就会被清空。这意味着在不同的 SqlSession 之间，无法共享一级缓存的数据。在分布式系统或者多线程环境下，如果多个线程使用不同的 SqlSession 进行相同查询，一级缓存无法发挥作用，仍然会多次查询数据库。例如，在一个分布式电商系统中，不同的服务实例可能使用不同的 SqlSession，此时一级缓存的局限性就会凸显出来。此外，一级缓存对于数据一致性的保障相对较弱，因为只要在同一个 SqlSession 内，即使数据在数据库中已经被其他事务更新，一级缓存中的旧数据仍然可能被返回，直到该 SqlSession 被关闭并重新查询。​

四、二级缓存详解​

4.1 二级缓存的原理​

4.1.1 缓存的作用范围​

二级缓存的作用范围是 Mapper 级别，它可以在多个 SqlSession 之间共享缓存数据。这意味着不同的 SqlSession 只要操作的是同一个 Mapper 接口及其对应的 SQL 语句，就可以共享二级缓存中的数据。例如，在一个大型企业级应用中，多个模块可能会通过不同的 SqlSession 查询用户信息，只要它们都使用同一个用户 Mapper 接口，就可以从二级缓存中获取缓存数据，避重复查询数据库。​

4.1.2 缓存的存储方式​

二级缓存通常可以选择多种存储方式，常见的有基于内存的存储和基于分布式缓存系统的存储。基于内存的存储方式如使用 Ehcache 等缓存框架，将缓存数据存储在应用服务器的内存中，这种方式读取速度快，但在分布式环境下可能存在数据同步问题。基于分布式缓存系统的存储方式，如使用 Redis 等，通过将缓存数据存储在分布式缓存集群中，能够有效解决分布式环境下的数据共享和同步问题，并且具有良好的扩展性和高可用性。在选择存储方式时，需要根据应用的具体需求和架构特点来决定。​

4.2 二级缓存的工作流程​

4.2.1 查询时的缓存命中与未命中处理​

当执行查询操作时，MyBatis-Plus 首先会检查二级缓存中是否存在与当前查询语句和参数匹配的缓存数据。如果命中缓存，就直接返回缓存中的数据，无需查询数据库，大大提高了查询效率。在一个新闻资讯系统中，大量用户频繁查看热门新闻列表，这些查询操作如果能够命中二级缓存，就能快速将新闻列表展示给用户，减少数据库的压力。​

若二级缓存未命中，MyBatis-Plus 会继续检查一级缓存。如果一级缓存也未命中，才会向数据库发送查询请求。获取数据后，数据会先被存储到一级缓存中（如果当前 SqlSession 未关闭），同时也会被存储到二级缓存中，以便后续其他 SqlSession 查询时能够命中二级缓存。在这个过程中，数据库查询结果会经过一系列处理，如数据转换、封装等，然后才被存入二级缓存。​

4.2.2 数据更新对二级缓存的影响​

当执行数据更新操作（如插入、更新、删除）时，MyBatis-Plus 会根据配置策略来处理二级缓存。一种常见的策略是在数据更新时，自动清空与该 Mapper 相关的二级缓存数据，以保证数据的一致性。例如，在一个订单管理系统中，如果更新了订单的状态，与订单 Mapper 相关的二级缓存中关于订单的缓存数据就会被清空，下次查询订单状态时，会从数据库重新获取最新数据并更新二级缓存。​

有些场景下，可能需要更细粒度的缓存更新控制，例如只更新与更新操作相关的部分缓存数据，而不是清空整个 Mapper 的二级缓存。这就需要开发者根据具体业务需求，通过自定义缓存更新策略或者使用缓存插件来实现。​

4.3 二级缓存的优点与局限性​

4.3.1 优点​

二级缓存能够实现跨 SqlSession 的数据共享，大大减少了不同 SqlSession 之间的重复查询，进一步降低了数据库的负。在分布式系统和多线程环境下，二级缓存能够有效提升系统的整体性能，因为多个线程或服务实例可以共享缓存数据，避了每个实例都重复查询数据库的开销。对于一些读取频繁、数据相对稳定的业务场景，如系统参数配置、字典数据等，二级缓存能够显著提高查询效率，提升用户体验。​

此外，二级缓存支持多种存储方式和扩展机制，开发者可以根据实际需求选择合适的缓存框架和配置，具有较的灵活性和可定制性。通过合理配置二级缓存的淘汰策略、缓存过期时间等参数，可以进一步优化缓存的使用效果。​

4.3.2 局限性​

二级缓存的配置和管理相对复杂，需要开发者对缓存机制有深入的理解。在分布式环境下，使用二级缓存可能会面临数据一致性和缓存同步的问题。由于多个节点可能同时访问和更新二级缓存，如何保证各个节点上的缓存数据一致是一个挑战。例如，在一个分布式电商系统中，不同的订单服务节点可能同时更新订单数据，此时如果二级缓存同步机制不完善，就可能导致部分节点读取到过期的订单数据。​

二级缓存还可能存在缓存穿透、缓存雪崩和缓存击穿等问题。缓存穿透是指大量请求访问不存在的数据，导致这些请求绕过缓存直接打到数据库上；缓存雪崩是指大量缓存同时过期，瞬间产生大量数据库请求，可能导致数据库崩溃；缓存击穿是指某个热点数据在缓存中过期的瞬间，大量请求同时访问该数据，导致数据库压力剧增。这些问题都需要开发者采取相应的措施来预防和解决。​

五、基于云监控台的缓存监控与分析​

5.1 云监控台的作用​

云监控台在 MyBatis-Plus 缓存策略优化中扮演着至关重要的角。它就像是系统的 “智能眼睛”，能够实时监测系统的运行状态，包括缓存的使用情况。通过云监控台，我们可以获取详细的缓存性能指标，如缓存命中率、缓存读写次数、缓存容量占用等。这些指标为我们评估缓存策略的有效性提供了数据依据，帮助我们发现缓存使用中存在的问题，如缓存命中率过低可能意味着缓存策略不合理，需要进行调整。​

5.2 监控指标与数据分析​

5.2.1 缓存命中率​

缓存命中率是衡量缓存性能的关键指标之一，它表示缓存命中次数与总查询次数的比值。高缓存命中率意味着大部分查询可以从缓存中获取数据，减少了数据库的负，提高了系统性能。例如，如果缓存命中率达到 90% 以上，说明缓存策略较为有效；如果缓存命中率较低，如低于 60%，则需要深入分析原因，可能是缓存过期时间设置不合理、缓存数据粒度不合适等。​

5.2.2 缓存读写次数​

监控缓存的读写次数可以了解缓存的使用频率和数据更新情况。频繁的写操作可能会导致缓存频繁失效，影响缓存命中率；而大量的读操作则表明缓存对于减少数据库查询的重要性。通过分析读写次数的比例，我们可以判断缓存的使用模式，进而调整缓存策略。例如，如果读操作远远多于写操作，那么可以适当延长缓存过期时间，以提高缓存命中率。​

5.2.3 缓存容量占用​

缓存容量占用指标反映了缓存中存储的数据所占用的内存空间大小。合理控制缓存容量占用对于系统的稳定性和性能至关重要。如果缓存容量占用过高，可能会导致系统内存不足，影响其他服务的正常运行；如果缓存容量占用过低，则说明缓存资源没有得到充分利用。通过云监控台，我们可以实时监测缓存容量占用情况，并根据业务需求进行动态调整，例如在数据访问高峰期适当增加缓存容量。​

5.3 基于监控数据的缓存策略调整​

根据云监控台提供的监控数据，我们可以有针对性地调整 MyBatis-Plus 的缓存策略。如果发现缓存命中率较低，可以尝试调整缓存过期时间，延长热门数据的缓存时间，或者优化缓存数据的粒度，将大粒度的数据拆分成更细粒度的数据进行缓存，以提高缓存的命中率。

如果缓存读写次数不均衡，写操作过于频繁导致缓存频繁失效，可以考虑采用更细粒度的缓存更新策略，只更新与更新操作相关的部分缓存数据，而不是清空整个缓存。对于缓存容量占用问题，如果占用过高，可以清理过期或无用的缓存数据，或者调整缓存存储方式，采用更高效的缓存压缩算法等。​

六、MyBatis-Plus 缓存策略优化实践​

6.1 一级缓存优化策略​

6.1.1 合理使用 SqlSession​

由于一级缓存的作用范围局限于 SqlSession，因此在开发过程中，要合理控制 SqlSession 的创建和使用。避频繁创建和关闭 SqlSession，尽量在一个业务逻辑中复用同一个 SqlSession，以充分发挥一级缓存的作用。例如，在一个服务类中，可以通过依赖注入的方式获取一个 SqlSessionFactory，然后在需要执行数据库操作时，从 SqlSessionFactory 中获取同一个 SqlSession 来执行多个查询操作，这样可以确保在同一个 SqlSession 内的查询能够命中一级缓存。​

6.1.2 避不必要的缓存清除​

在执行数据更新操作时，MyBatis-Plus 会自动清空一级缓存。然而，在某些情况下，可能存在不必要的缓存清除操作。例如，如果只是更新了数据的部分字段，而这些字段并不影响查询结果，那么可以通过自定义缓存更新策略，避清空整个一级缓存。可以通过在 Mapper 接口中定义自定义的缓存更新方法，在方法内部根据具体的更新逻辑来决定是否需要清除缓存，以及清除哪些缓存数据，从而提高一级缓存的利用率。​

6.2 二级缓存优化策略​

6.2.1 选择合适的缓存实现​

MyBatis-Plus 支持多种二级缓存实现，如 Ehcache、Redis 等。在选择缓存实现时，要根据应用的具体需求和架构特点进行合考虑。对于小型应用或者对数据一致性要求不是特别高的场景，可以选择基于内存的 Ehcache 作为二级缓存实现，它具有简单易用、读取速度快的特点。而对于分布式系统或者对数据一致性和扩展性要求较高的场景，Redis 等分布式缓存系统则是更好的选择，它能够实现跨节点的数据共享和缓存同步，并且具有大的集群管理功能。​

6.2.2 优化缓存配置参数​

二级缓存的配置参数对缓存性能有着重要影响。例如，缓存淘汰策略（如 LRU、FIFO 等）决定了在缓存空间不足时，哪些数据会被优先淘汰。对于热点数据访问频繁的场景，LRU（最近最少使用）淘汰策略通常更为合适，它会优先淘汰长时间未被访问的数据，保留热点数据在缓存中。缓存过期时间的设置也需要根据数据的更新频率和业务需求进行合理调整。对于更新频率较低的数据，可以设置较长的缓存过期时间，以提高缓存命中率；对于更新频繁的数据，则需要缩短缓存过期时间，以保证数据的实时性。​

6.2.3 解决缓存一致性问题​

在分布式环境下，二级缓存一致性问题是一个关键挑战。为了解决这个问题，可以采用多种方法。一种常见的方法是使用分布式锁，在更新数据时，先获取分布式锁，确保只有一个节点能够更新数据和缓存，避多个节点同时更新导致数据不一致。另一种方法是利用消息队列来实现缓存同步，当数据更新时，发送消息到消息队列，各个节点监听消息队列，接收到消息后及时更新本地缓存。还可以采用数据库事务与缓存更新相结合的方式，通过在数据库事务中同步更新缓存，保证数据和缓存的一致性。​

6.3 缓存预热与预加​

6.3.1 缓存预热的概念与作用​

缓存预热是指在系统启动时，提前将一些常用的数据加到缓存中。这样在系统正式运行时，用户的查询请求能够直接命中缓存，减少了首次查询的等待时间，提高了系统的响应速度。缓存预热对于一些数据访问具有明显峰值的应用场景尤为重要，如电商系统在促销活动开始前，提前将热门商品信息、用户信息等加到缓存中，能够有效应对活动开始时的高并发访问，避因缓存未命中导致数据库压力过大。​

6.3.2 实现缓存预热的方法​

实现缓存预热可以通过多种方式。一种简单的方法是在系统启动时，编写专门的缓存预热程序，主动调用相关的查询接口，将需要预热的数据查询出来并存储到缓存中。可以利用 Spring 框架的初始化方法，在系统启动完成后，自动执行缓存预热逻辑。另一种方法是使用定时任务，在系统运行过程中，定期更新缓存中的数据，确保缓存中的数据始终是最新的热门数据。例如，每隔一定时间查询一次销量最高的商品列表，并将其更新到缓存中。​

6.4 缓存与数据库的协同优化​

6.4.1 读写分离策略​

读写分离是一种常见的数据库优化策略，它将数据库的读操作和写操作分离到不同的数据库服务器上。在使用 MyBatis-Plus 的缓存机制时，可以结合读写分离策略进一步提升系统性能。对于读操作，优先从缓存中获取数据，如果缓存未命中，则从读库中查询数据，并将查询结果存储到缓存中；对于写操作，则直接操作写库，并在数据更新后，根据缓存策略更新或清除相关缓存数据。这样可以将读操作的压力分散到多个读库上，同时通过缓存进一步减少读库的访问次数，提高系统的整体吞吐量。​

例如，在一个博客系统中，大量用户浏览博客文章（读操作），而博主发布和编辑文章（写操作）相对较少。采用读写分离策略后，读操作可以从多个读库获取数据，结合缓存机制，大部分读请求能够从缓存中得到响应，大大减轻了写库的压力，提升了系统的响应速度。​

6.4.2 分库分表与缓存的配合​

在数据量庞大的系统中，分库分表是常用的数据库扩展策略，它将大量数据分散到多个数据库和数据表中，以提高数据库的处理能力。在这种情况下，MyBatis-Plus 的缓存策略需要与分库分表策略相配合，以确保缓存数据的准确性和有效性。​

对于分库分表场景下的缓存，需要根据分库分表的规则来设计缓存的键值，确保不同分库分表中的数据能够被正确地缓存和查询。例如，在按照用户 ID 进行分库分表的系统中，缓存的键值可以包含用户 ID 信息，这样在查询某个用户的数据时，能够准确地从对应的缓存中获取数据。​

同时，当执行跨分库分表的查询操作时，需要特别注意缓存的处理。可以将查询结果按照分库分表的规则进行拆分，分别存储到对应的缓存中，或者采用全局缓存的方式存储查询结果，但要注意全局缓存的更新和一致性维护。​

七、缓存常见问题及解决办法​

7.1 缓存穿透​

7.1.1 问题表现​

缓存穿透是指查询一个不存在的数据，由于缓存中没有该数据，所有的查询请求都会直接打到数据库上。如果这种不存在的数据的查询请求量很大，会导致数据库压力剧增，甚至可能使其崩溃。例如，在一个用户登录系统中，如果有大量恶意请求尝试查询不存在的用户 ID，就会造成缓存穿透问题。​

7.1.2 解决办法​

一种有效的解决办法是采用布隆过滤器。布隆过滤器是一种概率型数据结构，它可以快速判断一个数据是否存在于一个集合中。在系统初始化时，将数据库中所有存在的数据的标识（如用户 ID、商品 ID 等）存储到布隆过滤器中。当有查询请求时，首先通过布隆过滤器判断该数据是否存在。如果布隆过滤器判断数据不存在，则直接返回空结果，无需查询数据库和缓存；如果布隆过滤器判断数据可能存在，再继续查询缓存和数据库。​

另一种方法是缓存空值。当查询一个不存在的数据时，将查询结果（空值）也存储到缓存中，并设置一个较短的过期时间。这样，后续相同的查询请求就会从缓存中获取空值，避了对数据库的频繁访问。但要注意空值缓存的过期时间不能设置过长，以影响数据的实时性。

7.2 缓存雪崩​

7.2.1 问题表现​

缓存雪崩是指大量的缓存数据在同一时间过期，导致大量的查询请求无法命中缓存，全部涌向数据库，从而使数据库承受巨大的压力，甚至瘫痪。例如，在一个电商系统的促销活动中，如果大量商品的缓存数据在活动开始后的某个时间点同时过期，此时大量用户查询商品信息，就会引发缓存雪崩。​

7.2.2 解决办法​

为了避缓存雪崩，可以采用缓存过期时间随机化的策略。在设置缓存过期时间时，不要让所有缓存数据的过期时间相同，而是在一个基础过期时间的基础上增加一个随机值。这样，缓存数据的过期时间就会分散开来，避大量缓存同时过期。​

另外，可以采用多级缓存架构。除了 MyBatis-Plus 的一级缓存和二级缓存外，还可以引入本地缓存（如应用服务器内存缓存）和分布式缓存。当某一级缓存失效时，其他级别的缓存可以继续提供服务，减少对数据库的冲击。同时，多级缓存之间可以相互配合，例如本地缓存可以缓存热点数据，分布式缓存可以存储更大量的数据。​

7.3 缓存击穿​

7.3.1 问题表现​

缓存击穿是指一个热点数据在缓存中过期的瞬间，有大量的查询请求同时访问该数据，这些请求会同时穿透缓存，直接访问数据库，导致数据库瞬间压力增大。例如，在一个热门商品的秒杀活动中，该商品的缓存数据过期时，大量用户同时抢购该商品，就会造成缓存击穿。

7.3.2 解决办法​

使用互斥锁是解决缓存击穿的有效方法。当缓存失效时，只有一个查询请求能够获得锁并去查询数据库，其他查询请求则等待该请求完成后，从缓存中获取数据。这样可以避大量请求同时访问数据库。例如，当热点数据缓存过期时，第一个查询请求获取锁后，去数据库查询数据并更新缓存，其他请求在等待锁释放后，就可以从缓存中获取更新后的数据。​

另一种方法是设置热点数据永不过期。对于一些非常热门且更新不频繁的数据，可以将其缓存设置为永不过期，或者通过后台定时任务定期更新缓存数据，确保缓存中始终有该数据，从而避缓存击穿。但这种方法只适用于数据更新频率低的场景，否则会导致缓存数据与数据库数据不一致。​

八、缓存策略优化效果评估​

8.1 性能指标对比​

在进行缓存策略优化前后，需要对比系统的性能指标，以评估优化效果。主要的性能指标包括系统响应时间、数据库查询次数、缓存命中率等。优化后，系统响应时间应明显缩短，例如在一个查询接口中，优化前的响应时间为 500ms，优化后可能缩短到 100ms 以内；数据库查询次数应大幅减少，尤其是在高并发场景下，减少的比例可能达到 80% 以上；缓存命中率应显著提高，从优化前的 60% 提升到 90% 以上。​

8.2 实际业务场景验证​

除了性能指标对比外，还需要在实际业务场景中验证缓存策略优化的效果。例如，在电商系统的促销活动中，优化后的缓存策略应能够承受大量用户的并发访问，商品详情页的加速度明显加快，订单提交的响应时间缩短，数据库服务器的负保持在合理范围内。通过实际业务场景的验证，可以确保缓存策略优化能够真正提升系统的性能和用户体验。​

九、总结与展望​

9.1 总结​

本文深入探讨了基于云监控台的 MyBatis-Plus 一级缓存和二级缓存策略优化。首先介绍了 MyBatis-Plus 缓存机制的概述，包括缓存的重要性和体系结构；然后分别详细阐述了一级缓存和二级缓存的原理、工作流程、优点与局限性；接着讨论了基于云监控台的缓存监控与分析，以及如何根据监控数据调整缓存策略；之后介绍了缓存策略优化的实践方法，包括一级缓存和二级缓存的优化策略、缓存预热与预加、缓存与数据库的协同优化等；还分析了缓存常见问题及解决办法，并说明了缓存策略优化效果的评估方法。​

通过合理优化 MyBatis-Plus 的缓存策略，可以显著提升系统的性能，降低数据库的负，提高用户体验。在实际应用中，需要根据具体的业务场景和系统架构，选择合适的缓存策略，并结合云监控台进行持续的监控和调整，以确保缓存策略的有效性和稳定性。​

9.2 展望​

随着信息技术的不断发展，应用系统面临的并发访问和数据处理需求将越来越高，缓存技术在系统性能优化中的作用将更加重要。未来，MyBatis-Plus 缓存机制可能会不断完善，提供更加大的缓存功能和更灵活的配置选项。同时，云监控台的智能化程度也将不断提高，能够更精准地监测缓存性能，提供更智能的缓存策略调整建议。​

此外，随着分布式系统和微服务架构的普及，缓存技术与分布式系统的融合将更加紧密，如何在分布式环境下实现高效、一致的缓存将是未来研究的重要方向。相信通过不断的技术创新和实践探索，MyBatis-Plus 缓存策略优化将为应用系统的性能提升提供更有力的支持。