WAITEVENT: "library cache: mutex X" (文档 ID 727400.1)

最新推荐文章于 2024-10-15 10:00:00 发布
最新推荐文章于 2024-10-15 10:00:00 发布
阅读量4.2k 收藏 1
点赞数
分类专栏： 网络资源_ORACLE_调优
本文详细解释了Oracle数据库中'librarycache:mutex'等待事件的意义及其诊断性能问题的方法，适用于Oracle数据库11g版本。文章还提供了如何减少此类等待事件的建议，并列举了已知的bug及修复版本。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

In this Document

 Purpose
 Scope
 Details
 Definition:
 Individual Waits:
 Systemwide Waits:
 Wait Time:
 Reducing Waits / Wait times:
 Known Bugs:
 References

APPLIES TO:

Oracle Database - Personal Edition - Version 11.1.0.6 to 11.2.0.3 [Release 11.1 to 11.2]
Oracle Database - Standard Edition - Version 11.1.0.6 to 11.2.0.3 [Release 11.1 to 11.2]
Oracle Database - Enterprise Edition - Version 11.1.0.6 to 11.2.0.3 [Release 11.1 to 11.2]
Information in this document applies to any platform.

PURPOSE

This document explains the meaning of the wait event "library cache: mutex" and gives hints on how it may be used to diagnose performance problems.

SCOPE

This is intended for DBAs and developers who are involved with tuning their database. An intermediate level of expertise is required.

DETAILS

This is a reference note for the wait event "library cache: mutex X" which includes the following subsections:

See Note 61998.1 for an introduction to Wait Events.

Definition:

  • @Source Symbol:kglmwexc Versions:11.0 - Documentation:None
  • The library cache mutex is acquired for similar purposes that the library cache latches were acquired in prior versions of Oracle. In 10g, mutexes were introduced for certain operations in the library cache.  Starting with 11g, the library cache latches were replaced by mutexes, hence this new wait event.
  • Mutexes are a lighter-weight and more granular concurrency mechanism than latches. Mutexes take advantage of CPU architectures that offer the compare and swap instructions (or similar). The reason for obtaining a mutex in the first place, is to ensure that certain operations are properly managed for concurrency. E.g., if one session is changing a data structure in memory, then another session must wait to acquire the mutex before it can make a similar change - this prevents unintended changes that would lead to corruptions or crashes if not serialized.
  • This wait event is present whenever a library cache mutex is held in exclusive mode by a session and other sessions need to wait for it to be released.  There are many different operations in the library cache that will require a mutex, so its important to recognize which "location" (in Oracle's code) is involved in the wait.  "Location" is useful to Oracle Support engineers for diagnosing the cause for this wait event.

Individual Waits:

Parameters:

    • P1 = "idn" = Unique Mutex Identifier
    • P2 = Mutex "value" = in order to find the mutex value, read note 1298015.1
    • P3 = "where" = location in code (internal identifier) where mutex is being waited for 

     

    Systemwide Waits:

    At a systemwide level, there are two views which will help diagnose this wait:

    GV$MUTEX_SLEEP (or V$MUTEX_SLEEP for non-RAC)
    and GV$MUTEX_SLEEP_HISTORY (or V$MUTEX_SLEEP_HISTORY for non-RAC)

    These views track the instance wide usage of mutexes since instance startup.  Since these views show values that are total values since startup, they are most meaningful when you obtain the difference in values during a short time interval when there was problem.  The easiest way to see this information is through an AWR or statspack report in the "Mutex Sleep Summary" section.

    Wait Time:

    The waiter waits very briefly before timing out.  It is typical to see 100% timeouts for this wait.

    Reducing Waits / Wait times:

    The cause for waits will be very specific to a particular library cache object since mutexes are very granular now compared to the old library cache latches. Generally, excessive waits are caused by frequent pinning and unpinning of cursors or objects; this document will be updated as other causes are encountered.

    Known Bugs:


    Known Bugs

    You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
                         


    NBBugFixedDescription
     1758848012.1.0.2, 12.2.0.0library cache mutex/shared pool latch deadlock
     1623280311.2.0.4, 12.1.0.2, 12.2.0.0Library cache lock / mutex contention with fix 8508078 enabled
     1440173111.2.0.3.BP20, 11.2.0.4, 12.1.0.1Cursor leak using "SET TRANSACTION" within PLSQL
     1686404211.2.0.4, 12.2.0.0Unnecessary library cache operations for DDLs on partitions in exadata
     1640012212.2.0.0Spikes in library cache mutex contention for SQL using SQL Plan Baseline
     1585802211.2.0.4, 12.2.0.0Frequent invalidation of tuning objects with VPD
     1381039311.2.0.2.10, 11.2.0.2.BP20, 11.2.0.3.6, 11.2.0.3.BP15, 11.2.0.4, 12.1.0.1Deadlock waiting for 'library cache: mutex x' while producing an ORA-4031 diagnostic dump
     1372075311.2.0.4, 12.1.0.1Diagnosability issue - mutex wait "idn" value truncated in session wait output in tracefile
     1358824811.2.0.2.BP17, 11.2.0.3.3, 11.2.0.3.BP06, 11.2.0.4, 12.1.0.1"library cache: mutex X" contention for objects with very many library cache locks
     1297637611.2.0.2.6, 11.2.0.2.BP16, 11.2.0.3.3, 11.2.0.3.BP05, 12.1.0.1High VERSION_COUNT for SQL with binds, including recursive dictionary SQL - superseded
     1279742011.2.0.2.11, 11.2.0.2.BP21, 11.2.0.3.3, 11.2.0.3.BP07, 11.2.0.4, 12.1.0.1"library cache: mutex X" waits on DB instance handle with CURSOR_SHARING
     1181833511.1.0.7.9, 11.2.0.2.2, 11.2.0.2.BP06, 11.2.0.3, 12.1.0.1Additional support for bug 10411618 to allow dynamic Mutex wait scheme changes
     1171915111.2.0.3, 12.1.0.1SQL Plan Management capture causes slowness
     1063211311.2.0.3, 12.1.0.1OLS calls cause mutex contention even with low number of concurrent users
     1041771611.2.0.2.5, 11.2.0.2.BP05, 11.2.0.2.GIPSU05, 11.2.0.3, 12.1.0.1Mutex X waits in 11G on an instance with heavy JAVA usage
     1028484511.2.0.3, 12.1.0.1Need index on SID for X$KGLLK and X$KGLPN based views (V$OPEN_CURSOR etc..)
     1028483811.2.0.2.5, 11.2.0.2.BP13, 11.2.0.2.GIPSU05, 11.2.0.3, 12.1.0.1Cache line contention while waiting for mutexes
     1020450511.2.0.3, 12.1.0.1SGA autotune can cause row cache misses, library cache reloads and parsing
     1008684311.2.0.3, 12.1.0.1Recursive SQL cursors not reused - PMON crashes instance with ORA-600 [kglLockOwnersListDelete]
     953075011.2.0.2, 12.1.0.1High waits for 'library cache: mutex X' for cursor Build lock
     923986311.2.0.1.BP06, 11.2.0.2, 12.1.0.1Excessive "library cache:mutex X" contention on hot objects
     898105911.1.0.7.4, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1High Version Count (due to USER_BIND_PEEK_MISMATCH) with bind peeking
     886019811.2.0.2, 12.1.0.1"library cache:mutex X" waits using XMLType
     735277511.2.0.2, 12.1.0.1Many child cursors when PARALLEL_INSTANCE_GROUP set wrong
     1267016511.2.0.2.4, 11.2.0.2.BP12, 11.2.0.3Library cache mutex contention caused by lookup of triggers
     1263334011.2.0.2.6, 11.2.0.2.BP13, 11.2.0.3Heavy "library cache lock" and "library cache: mutex X" contention for a "$BUILD$.xx" lock
     879349210.2.0.5, 11.2.0.1.BP07, 11.2.0.2Mutex Waits with Resource Manager
     1014555811.1.0.7.7, 11.2.0.1.BP12, 11.2.0.2Selects on library cache V$/X$ views cause "library cache: mutex X" waits
     939868511.2.0.2High "library cache: mutex X" when using Application Context
     928252111.2.0.2Excessive "library cache:mutex X" contention on hot objects
     914026211.2.0.2ORA-600 [ksliwat5] followed by cpu spike/"library cache: mutex X" Waits
     900314511.2.0.1.BP03, 11.2.0.2Dump (kglIsOwnerVersionable) / "library cache: mutex X" waits
     750223711.1.0.7.7, 11.2.0.1Unnecessary "library cache: mutex X" waits using stored Java
     730797211.1.0.7.2, 11.2.0.1Excessive waits on 'library cache: mutex x'
     8431767 High "library cache: mutex X" when using Application Context
     931287911.1.0.7.7, 11.2.0.1"library cache: mutex x" waits after killing sessions / PMON slow to clean up
     764840610.2.0.5, 11.1.0.7.4, 11.2.0.1Child cursors not shared for "table_..." cursors (that show as "SQL Text Not Available") when NLS_LENGTH_SEMANTICS = CHAR
     715586011.2.0.1Spin on kgllkde causes 'library cache: mutex X'
     849904311.1.0.7.2SET_CONTEXT incurs unnecessary DLM overhead in RAC
     592827111.1.0.7Excessive waits on "library cache: mutex X"
     731711711.2.0.1Unnecessary "library cache: mutex X" waits on LOB operations
    • '*' indicates that an alert exists for that issue.
    • '+' indicates a particularly notable issue / bug.
    • 'I' indicates an install issue / bug included for completeness.
    • 'P' indicates a port specific bug.
    • Fixed versions use "BPnn" to indicate Exadata bundle nn.
    • "OERI:xxxx" may be used as shorthand for ORA-600 [xxxx].

    Another important fix to keep in mind is:
     bug:10411618  ADD DIFFERENT WAIT SCHEMES FOR MUTEX WAITS

    There are 3 parameters to control the mutex waits, which can be set dynamically and are only allowed to be set by "alter system set"

    * _mutex_spin_count (Integer) - This sets the number of times to spin before yielding/waiting.
    * _mutex_wait_time (Integer) - This sets the amount of time in milli seconds to wait or the maximum amount of time to sleep for exponential backoff
    * _mutex_wait_scheme (Integer) - This controls which wait scheme to use. It can be set to one of the three wait schemes described above.
    o _mutex_wait_scheme = 0 - Always YIELD
    o _mutex_wait_scheme = 1 & _mutex_wait_time = t - Always SLEEP for t ms
    o _mutex_wait_scheme = 2 & _mutex_wait_time = t - EXP BACKOFF with maximum sleep time set to t ms.

    The default in MAIN & the backports is set to exponential backoff with the maximum wait time set to 1 ms. The old default behaviour was mostly yield. So after applying the patch if we need to revert to old behaviour, _mutex_wait_scheme should be set to 0.

    REFERENCES

    NOTE:5928271.8 - Bug 5928271 - Excessive waits on "library cache: mutex X"

    NOTE:7155860.8 - Bug 7155860 - Spin on kgllkde causes 'library cache: mutex X'
    NOTE:7307972.8 - Bug 7307972 - Excessive waits on 'library cache: mutex x'
    NOTE:7317117.8 - Bug 7317117 - Unnecessary "library cache: mutex X" waits on LOB operations
    NOTE:7648406.8 - Bug 7648406 - Child cursors not shared for "table_..." cursors (that show as "SQL Text Not Available") when NLS_LENGTH_SEMANTICS = CHAR
    NOTE:8431767.8 - Bug 8431767 - High "library cache: mutex X" when using Application Context
    NOTE:8499043.8 - Bug 8499043 - SET_CONTEXT incurs unnecessary DLM overhead in RAC
    NOTE:8793492.8 - Bug 8793492 - Mutex Waits with Resource Manager
    NOTE:8860198.8 - Bug 8860198 - "library cache:mutex X" waits using XMLType
    NOTE:8981059.8 - Bug 8981059 - High Version Count (due to USER_BIND_PEEK_MISMATCH) with bind peeking
    NOTE:9003145.8 - Bug 9003145 - Dump (kglIsOwnerVersionable) / "library cache: mutex X" waits
    NOTE:9140262.8 - Bug 9140262 - ORA-600 [ksliwat5] followed by cpu spike/"library cache: mutex X" Waits
    NOTE:9239863.8 - Bug 9239863 - Excessive "library cache:mutex X" contention on hot objects
    NOTE:9282521.8 - Bug 9282521 - Excessive "library cache:mutex X" contention on hot objects
    NOTE:9312879.8 - Bug 9312879 - "library cache: mutex x" waits after killing sessions / PMON slow to clean up
    NOTE:9398685.8 - Bug 9398685 - High "library cache: mutex X" when using Application Context
    NOTE:9530750.8 - Bug 9530750 - High waits for 'library cache: mutex X' for cursor Build lock
    BUG:10411618 - ADD DIFFERENT WAIT SCHEMES FOR MUTEX WAITS





    NOTE:7502237.8 - Bug 7502237 - Unnecessary "library cache: mutex X" waits using stored Java
    NOTE:11719151.8 - Bug 11719151 - SQL Plan Management capture causes slowness
    NOTE:11818335.8 - Bug 11818335 - Additional support for bug 10411618 to allow dynamic Mutex wait scheme changes
    NOTE:12633340.8 - Bug 12633340 - Heavy "library cache lock" and "library cache: mutex X" contention for a "$BUILD$.xx" lock
    NOTE:12670165.8 - Bug 12670165 - Library cache mutex contention caused by lookup of triggers
    NOTE:12797420.8 - Bug 12797420 - "library cache: mutex X" waits on DB instance handle with CURSOR_SHARING
    NOTE:12976376.8 - Bug 12976376 - High VERSION_COUNT for SQL with binds, including recursive dictionary SQL - superseded
    NOTE:13588248.8 - Bug 13588248 - "library cache: mutex X" contention for objects with very many library cache locks
    NOTE:10086843.8 - Bug 10086843 - Recursive SQL cursors not reused - PMON crashes instance with ORA-600 [kglLockOwnersListDelete]
    NOTE:10145558.8 - Bug 10145558 - Selects on library cache V$/X$ views cause "library cache: mutex X" waits
    NOTE:10204505.8 - Bug 10204505 - SGA autotune can cause row cache misses, library cache reloads and parsing
    NOTE:7352775.8 - Bug 7352775 - Many child cursors when PARALLEL_INSTANCE_GROUP set wrong
    NOTE:10284845.8 - Bug 10284845 - Need index on SID for X$KGLLK and X$KGLPN based views (V$OPEN_CURSOR etc..)
    NOTE:10417716.8 - Bug 10417716 - Mutex X waits in 11G on an instance with heavy JAVA usage
    NOTE:10632113.8 - Bug 10632113 - OLS calls cause mutex contention even with low number of concurrent users
library cache: mutex X
huangliang0703的专栏
05-05 2072
发现数据库存在 ;library cache: mutex X 等待事件 （ID 1357946.1） Top 5 Timed Foreground Events Event Waits Time(s) Avg wait (ms) % DB time Wait Class library cache: mute
常见问题：‘cursor:mutex ..‘/ ‘cursor:pin ..‘/ ‘library cache:mutex ..‘类型的等待事件
Lixora's DB Home
01-16 1117
处理或访问cursor的任何操作都可能需要等待，才能访问在 shared pool 中支持这些操作的结构。请注意，所有这些等待事件都非常相似，并且可能都是在一个操作过程中产生的等待。Share(共享)操作可以在不更改的情况下进行，只是需要在更改过程中暂时锁定这些操作，以防止其被其他项更改。基于这些事件的争用通常是另一个问题的症状表现 – 即问题是其它地方产生的，而不是 mutex 机制本身。通常，通过采用合理的cursor共享策略，正确使用绑定变量并确保没有大量版本，应该能够避免大多数这类性质的问题。
11g等待事件之library cache: mutex X
weixin_33898876的博客
08-14 173
11g等待事件之library cache: mutex X 作者: dbafree 日期: 2012 年 07 月 01 日发表评论 (0)查看评论     library cache: mutex X替代了之前的library cache latch，主要作用是在hash bucket中定位handle时使用。（比如SQL硬解析时，需要往hash bucket中新增一个cursor...
[20170727]library cache: mutex X.txt
07-27 165
[20170727]library cache: mutex X.txt --//如果多个会话访问v$sql视图,其底层视图是x$kglcursor_child,如果几个会话同时访问,会出现library cache: mut...
关于等待事件cursor:mutex X的一次案例分析
killvoon的专栏
06-20 4037
数据库环境：oracle12.1.0.2.170718，两节点RAC+单实例ADG日常巡检时候发现，晚上11点系统跑批的时候，会出现系统负载过高情况，明显有异于平时。但并不是每天晚上跑批都会出现该问题，一开始怀疑是跑批内容存在差异导致，后跟开发人员再三确认，跑批程序一致，数据也不相上下。正常时，跑批期间DB Time：异常时，跑批期间DB Time：看看等待事件情况：正常时的等待事件情况：异常时的...
Oracle 11g 生产库因密码过期修改密码产生library cache lock等待事件导致用户hang问题分析及处理
shlei5580的专栏
04-28 948
该生产库是Oracle 11g库，数据库版本为11.2.0.4，Oracle在11g有个新特性，即有一个用户使用错误的密码连接数据库，随着登陆失败次数的增加，每次登陆验证前延迟等待的时间也会增加，这个新特性的主要目的是用于防止一些应用程序使用错误的密码尝试登陆数据库，由于密码延迟策略，大量会话等待登陆验证，导致数据库后续连接产生大量library cache lock等待事件导致hang住。此问题可以在MOS上查询(ID 1309738.1)这篇文章，有详细描述。
oracle共享池管理-library cache: mutex X
oradbm的博客
10-28 2857
产生library cache latch原因 The library cache latches protect the cached SQL statements and objects' definitions held inthe library cache within the shared pool. The library cache latch must be ...
oracle10503事件,library cache: mutex X等待事件, blocker session on cpu
weixin_36331336的博客
04-04 729
library cache: mutex X等待事件是当一个会话以exclusive mode持有library cache mutex时，另一个会话当前无论何时申请此mutex时必须等待其释放。很多时候对 library cache做不同的操作时都需要申请一个mutex, 所以最重要的是确认mutex的位置”location”, 该位置有助于分析该类等待事件的原因。对应参数：P1 = “id...
Troubleshooting 'library cache: mutex X' waits. (文档 ID 1357946.1)
mybluetiankong的专栏
01-19 921
In this Document   Purpose   Troubleshooting Steps   What is a 'library cache: mutex X' wait?   What causes 'library cache: mutex X' wait?
library cache: mutex X 等待事件分析
kiwixing的博客
10-15 738
mutex 功能是一种控制对 in memory 结构的访问的机制。它用于许多领域，包括库缓存。库缓存是一个内存区域，其中包含执行 SQL 所需的已解析游标结构。'library cache： mutex X' 的等待类似于早期版本中的库缓存等待。'library cache： mutex X' 可能是由许多问题引起的（包括应用程序问题、缺乏共享导致高版本数等），但本质上是某些东西持有互斥锁 “太久” 以至于其他会话必须等待资源。
library cache oracle,大量的library cache：mutex X
weixin_28721743的博客
04-15 328
11.2.0.3.0RAC=Yes Microsoft Windows x86 64-bit22.32 (mins)Top 5 wait eventEvent Waits Time(s) Avg wait (ms) % DB time Wait Classlatch: row cache objects...
11g等待事library cache: mutex X
huangliang0703的专栏
11-12 2957
从GC 上发现有一个库的 活动会话超多，sqlplus 进去看了一下等待事件，全是： library cache: mutex X  是由一个 update 语句造成的 ，sql_id 为 2tyrw2x2dwxzx update ecboss_salesOrder set version=version+1, lastUpdateT
Troubleshooting 'library cache: mutex X' Waits. (文档 ID 1357946.1)
热门推荐
badman250的专栏
03-16 3万+
PURPOSE The purpose of the article is to help troubleshoot contention for the wait event 'library cache: mutex X'. TROUBLESHOOTING STEPS What is a 'library cache: mutex X' wait? The mutex feat
library cache: mutex X 和latch: shared pool 一例
oraly的博客
05-22 868
某业务系统数据库HANG，排查进程如下：alert日志信息如下：Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136) Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136) Tue Sep 26 22:10:04 ...
数据性能问题分析-“library cache_ mutex X”
lmxx2020的博客
01-24 1728
4、游标重新载入：游标重新载入是指本来已经存在于 library cache 中，但是当再次查找时已经被移出 library cache（例如：由于内存压力），这时就需要重新解析并且载入该游标。游标重新载入操作不是一件好事，它表明您正在做一件本来不需要做的事情，如果您设置的 library cache 大小适当，是可以避免游标重新载入的。3、游标失效：游标失效是指，保存在 library cache 中的游标由于不可用，而从 library cache 中删除。游标关联表，视图等对象的修改等。
std::mutex和std::shared_timed_mutex的区别
最新发布
07-31
在C++并发编程中，`std::mutex`和`std::shared_timed_mutex`是用于管理共享资源访问的两种互斥锁类型，它们各自适用于不同的场景，并具有不同的功能特性。 ### `std::mutex` `std::mutex`是C++11引入的最基本的互斥锁类型，它提供独占锁（exclusive lock）功能，意味着在任意时刻只能有一个线程能够持有该锁。当一个线程对`std::mutex`进行加锁操作后，其他试图加锁的线程将被阻塞，直到该锁被释放。这种锁适用于需要防止多个线程同时修改共享资源的场景。`std::mutex`通常与`std::lock_guard`或`std::unique_lock`一起使用，以实现RAII风格的锁管理，确保锁在作用域结束时自动释放[^3]。 示例代码： ```cpp #include <mutex> #include <thread> std::mutex mtx; void print_block(int n, char c) { mtx.lock(); for (int i = 0; i < n; ++i) { std::cout << c; } std::cout << '\n'; mtx.unlock(); } int main() { std::thread th1(print_block, 50, '*'); std::thread th2(print_block, 50, '$'); th1.join(); th2.join(); return 0; } ``` ### `std::shared_timed_mutex` `std::shared_timed_mutex`是C++14引入的一种更复杂的互斥锁，它支持两种类型的锁：共享锁（shared lock）和独占锁（exclusive lock）。共享锁允许多个线程同时读取共享资源，而独占锁则保证只有一个线程可以写入资源。这种锁特别适合读多写少的场景，因为它可以提高并发性能，允许多个读线程同时访问资源，而写线程则需要独占访问[^1]。 `std::shared_timed_mutex`还支持定时锁（timed lock）操作，例如`try_lock_for`和`try_lock_until`，允许线程在指定的时间段内尝试获取锁，而不是无限期等待。这在某些场景下可以避免死锁或提高程序的响应性。 示例代码： ```cpp #include <shared_mutex> #include <thread> #include <iostream> std::shared_timed_mutex shared_mtx; int data = 0; void reader(int id) { shared_mtx.lock_shared(); std::cout << "Reader " << id << " sees data = " << data << std::endl; shared_mtx.unlock_shared(); } void writer() { shared_mtx.lock(); data++; std::cout << "Writer updated data to " << data << std::endl; shared_mtx.unlock(); } int main() { std::thread w(writer); std::thread r1(reader, 1); std::thread r2(reader, 2); w.join(); r1.join(); r2.join(); return 0; } ``` ### 主要区别 1. **锁的类型**：`std::mutex`仅支持独占锁，而`std::shared_timed_mutex`支持共享锁和独占锁。 2. **并发性能**：由于`std::shared_timed_mutex`允许多个读线程同时访问资源，因此在读操作远多于写操作的场景中，它通常能提供更好的并发性能。 3. **定时操作**：`std::shared_timed_mutex`支持定时锁操作，而`std::mutex`不支持[^1]。 综上所述，选择`std::mutex`还是`std::shared_timed_mutex`取决于具体的应用场景。如果应用场景主要是写操作或需要简单的互斥机制，则`std::mutex`是合适的选择；而在读多写少的场景中，使用`std::shared_timed_mutex`可以显著提高并发性能。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值