执行计划

最新推荐文章于 2021-08-26 23:21:00 发布
最新推荐文章于 2021-08-26 23:21:00 发布
阅读量227 收藏 1
点赞数 1
分类专栏： warehouse_11gR2 文章标签： Oracle 执行计划
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/sudahai102448567/article/details/115910968
版权

本文章为网络笔记，看了warehouse老师的视频受益匪浅，更是感觉自己技术太过初级，特写了本笔记，方便以后反复学习！
如有任何不妥，请发邮件至102448567@qq.com删除文章！
关于warehouse：
http://blog.itpub.net/19602/viewspace-1059211/
11gR2视频第四版 8_04_执行计划

执行计划：sql语句执行的详细过程
有很多方法
在sqlplus中默认是关闭的[]为可选项，{}为必选项，|隔开的是可选项，只能选择其中的一个

SQL> show autotrace
autotrace OFF

有哪些选项

SQL> set autotrace
Usage: SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]

SQL> select count(1) from tt2 where object_id=2;

  COUNT(1)
----------
	16


Execution Plan  --执行计划
----------------------------------------------------------
Plan hash value: 1151720287

-----------------------------------------------------------------------------
| Id  | Operation	  | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	    |	  1 |	 13 |	  1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |	    |	  1 |	 13 |		 |	    |
|*  2 |   INDEX RANGE SCAN| IDX_TT2 |	 16 |	208 |	  1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"=2)

Note
-----
   - dynamic sampling used for this statement (level=2)
--执行计划结束，下面是统计信息

Statistics
----------------------------------------------------------
	  9  recursive calls
	  0  db block gets
	 75  consistent gets
	  1  physical reads
	  0  redo size
	526  bytes sent via SQL*Net to client
	524  bytes received via SQL*Net from client
	  2  SQL*Net roundtrips to/from client
	  0  sorts (memory)
	  0  sorts (disk)
	  1  rows processed

只要执行计划
set autotrace on stat只要统计信息：执行这个sql语句对资源的消耗汇总
set autotrace traceonly exp只显示执行计划不显示sql的结果

SQL> set autotrace on exp
SQL> select count(1) from tt2 where object_id=2;

  COUNT(1)
----------
	16
############
id：步骤id
Operation：操作的名字
Name：操作的对象的名字
Rows：每一步访问了多少行
Bytes：多少个字节
Cost：成本，一个没有单位的数值，越大消耗的资源越大，主要和IO和CPU有关
Time：消耗的时间
重点关注数值非常大的行
############

Execution Plan
----------------------------------------------------------
Plan hash value: 1151720287

-----------------------------------------------------------------------------
| Id  | Operation	  | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	    |	  1 |	 13 |	  1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |	    |	  1 |	 13 |		 |	    |
|*  2 |   INDEX RANGE SCAN| IDX_TT2 |	 16 |	208 |	  1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"=2)

Note
-----
   - dynamic sampling used for this statement (level=2)

SQL>

因为object_id上有索引所以上面的执行计划最先执行id是3的步骤，因为不是唯一索引，找到object_id就会找到rowid，然后就确定了一行，对于上面的sql来说执行完id3之后就是id2（找到了之后就count聚合了）然后就是id1（输出了）
改变一下sql

SQL> select count(object_name) from tt2 where object_id=2;

COUNT(OBJECT_NAME)
------------------
		16

Execution Plan
----------------------------------------------------------
Plan hash value: 3949934342

----------------------------------------------------------------------------------------
| Id  | Operation		     | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	     |	       |     1 |    79 |    18	 (0)| 00:00:01 |
|   1 |  SORT AGGREGATE 	     |	       |     1 |    79 |	    |	       |
|   2 |   TABLE ACCESS BY INDEX ROWID| TT2     |    16 |  1264 |    18	 (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN	     | IDX_TT2 |    16 |       |     1	 (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information --谓词信息 (identified by operation id):
---------------------------------------------------
--相当于是告诉你在哪一步用到了where子句，也就是3前边有个*的原因
   3 - access("OBJECT_ID"=2) --这里是access还有可能是filter

Note --注意
-----
      --动态取样被这个语句使用，级别是2 啥意思？看后面
   - dynamic sampling used for this statement (level=2)

上面的sql执行顺序先是id3（走索引范围扫描）然后是id2（在表中通过index的rowid去访问）然后是id1（count聚合）最后是id0（输出）
这里的id2与上一个sql不一样是因为这次count的object_name在index的leaf中没有所以需要到表中去找，而上一个是count(1)直接在index中就可以了

Note --注意
-----
      --动态取样被这个语句使用，级别是2 啥意思？
   - dynamic sampling used for this statement (level=2)

意思是Oracle生成这个执行计划的时候要用到optimizer statistics（优化器统计信息）

optimizer statistics分为三种
1.table
select * from dba_tabes where table_name = ‘TT2’;
其中的blocks：表示存放这个表里的数据用了多少个块
num_rows：表里一共有多少行数据
avg_row_len：平均每一行的长度是多少个字节
这三个信息能宏观的说明这个表大不大
2.index
3.column

正是因为tt2这个表没有优化器统计信息，Oracle生成执行计划的时候没有参考依据，所以Oracle进行了dynamic sampling（动态取样），动态取样受到了一个参数的限制

SQL> show parameter dynamic;

NAME				           TYPE	       VALUE
----------------------------- ----------- -------------
optimizer_dynamic_sampling	   integer	 2

Dynamic Statistics Levels（11.2）
https://docs.oracle.com/cd/E11882_01/server.112/e41573/stats.htm#PFGRF94759
在这里插入图片描述
在这里插入图片描述
下面的参数是11204的时候默认level就是2

SQL> show parameter optimizer_features_enable;

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
optimizer_features_enable	     string	 11.2.0.4

如果不让Oracle动态取样就把optimizer_dynamic_sampling设置成0

SQL> alter session set optimizer_dynamic_sampling = 0;

Session altered.

下面就已经没有了note的提示信息

SQL> select count(object_name) from tt2 where object_id+0=2;

Execution Plan
----------------------------------------------------------
Plan hash value: 1424956034

---------------------------------------------------------------------------
| Id  | Operation	   | Name | Rows  | Bytes | Cost (%CPU)| Time	  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |	  |	1 |    79 |   878   (1)| 00:00:11 |
|   1 |  SORT AGGREGATE    |	  |	1 |    79 |	       |	  |
|*  2 |   TABLE ACCESS FULL| TT2  |  2637 |   203K|   878   (1)| 00:00:11 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("OBJECT_ID"+0=2)

把optimizer_dynamic_sampling改回来，改成2
还可以在sql语句中直接屏蔽掉提示动态取样

SQL> select /*+ dynamic_sampling(0) */count(object_name) from tt2 where object_id+0=2;

Execution Plan
----------------------------------------------------------
Plan hash value: 1424956034

---------------------------------------------------------------------------
| Id  | Operation	   | Name | Rows  | Bytes | Cost (%CPU)| Time	  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |	  |	1 |    79 |   878   (1)| 00:00:11 |
|   1 |  SORT AGGREGATE    |	  |	1 |    79 |	       |	  |
|*  2 |   TABLE ACCESS FULL| TT2  |  2637 |   203K|   878   (1)| 00:00:11 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("OBJECT_ID"+0=2)

或者要是这个表中有了统计信息Oracle就不会提示动态取样了

SQL> exec dbms_stats.gather_table_stats('sys','tt2');

PL/SQL procedure successfully completed.

SQL> select num_rows,blocks,avg_row_len from dba_tables where table_name = 'TT2';

  NUM_ROWS     BLOCKS AVG_ROW_LEN
---------- ---------- -----------
    247104	 3229	       89

SQL> select count(object_name) from tt2 where object_id+0=2;

Execution Plan
----------------------------------------------------------
Plan hash value: 1424956034

---------------------------------------------------------------------------
| Id  | Operation	   | Name | Rows  | Bytes | Cost (%CPU)| Time	  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |	  |	1 |    25 |   878   (1)| 00:00:11 |
|   1 |  SORT AGGREGATE    |	  |	1 |    25 |	       |	  |
|*  2 |   TABLE ACCESS FULL| TT2  |    16 |   400 |   878   (1)| 00:00:11 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("OBJECT_ID"+0=2)

什么是优化器统计信息呢？
为Oracle生成执行计划的时候提供了参考的依据比如dba_tables中的blocks、num_rows、avg_row_len表如果很小Oracle就会直接选择TABLE ACCESS FULL，如果表很大就会评估是不是使用Index效率会更高
改一下sql让谓词信息中的access变成filter

SQL> select count(object_name) from tt2 where object_id+0=2;

COUNT(OBJECT_NAME)
------------------
		16

Execution Plan
----------------------------------------------------------
Plan hash value: 1424956034

---------------------------------------------------------------------------
| Id  | Operation	   | Name | Rows  | Bytes | Cost (%CPU)| Time	  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |	  |	1 |    79 |   878   (1)| 00:00:11 |
|   1 |  SORT AGGREGATE    |	  |	1 |    79 |	       |	  |
|*  2 |   TABLE ACCESS FULL| TT2  |    36 |  2844 |   878   (1)| 00:00:11 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("OBJECT_ID"+0=2)

Note
-----
   - dynamic sampling used for this statement (level=2)

这个执行计划就没有走index而且他的rows不是16因为他是估算的，不是真实的结果，通过index的时候估算的是正确的，没有走index估算的有偏差，cost和bytes也差了很多，显然不走index效率很差

access和filter的区别
access代表的是访问的路径（object_id=2）
1.TABLE ACCESS FULL（直接在表里找）
2.INDEX RANGE SCAN（可以在index里找）
凡是access就说明where子句条件中是有索引的
filter表示就是过滤条件不影响结果

执行计划的顺序：
原则
1.缩进最多的先执行
2.缩进相同的先执行上面的
栗子：
下面的执行顺序就是6-8-9-7-5-11-12-10-4-14-16-15-13-3-2-1-0

SQL> select count(1) from dba_objects;

Execution Plan
----------------------------------------------------------
Plan hash value: 2509769952

----------------------------------------------------------------------------------------
| Id  | Operation		 | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	 |	       |     1 |       |    53	 (0)| 00:00:01 |
|   1 |  SORT AGGREGATE 	 |	       |     1 |       |	    |	       |
|   2 |   VIEW			 | DBA_OBJECTS | 15453 |       |    53	 (0)| 00:00:01 |
|   3 |    UNION-ALL		 |	       |       |       |	    |	       |
|*  4 |     FILTER		 |	       |       |       |	    |	       |
|*  5 |      HASH JOIN		 |	       | 15452 |  1554K|    53	 (0)| 00:00:01 |
|   6 |       INDEX FULL SCAN	 | I_USER2     |    46 |   184 |     1	 (0)| 00:00:01 |
|*  7 |       HASH JOIN 	 |	       | 15452 |  1493K|    52	 (0)| 00:00:01 |
|   8 |        INDEX FULL SCAN	 | I_USER2     |    46 |  1012 |     1	 (0)| 00:00:01 |
|*  9 |        TABLE ACCESS FULL | OBJ$        | 15452 |  1161K|    51	 (0)| 00:00:01 |
|  10 |      NESTED LOOPS	 |	       |     1 |    29 |     2	 (0)| 00:00:01 |
|* 11 |       INDEX SKIP SCAN	 | I_USER2     |     1 |    20 |     1	 (0)| 00:00:01 |
|* 12 |       INDEX RANGE SCAN	 | I_OBJ4      |     1 |     9 |     1	 (0)| 00:00:01 |
|  13 |     NESTED LOOPS	 |	       |     1 |    17 |     0	 (0)| 00:00:01 |
|  14 |      INDEX FULL SCAN	 | I_LINK1     |     1 |    13 |     0	 (0)| 00:00:01 |
|  15 |      TABLE ACCESS CLUSTER| USER$       |     1 |     4 |     0	 (0)| 00:00:01 |
|* 16 |       INDEX UNIQUE SCAN  | I_USER#     |     1 |       |     0	 (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - filter("O"."TYPE#"<>4 AND "O"."TYPE#"<>5 AND "O"."TYPE#"<>7 AND
	      "O"."TYPE#"<>8 AND "O"."TYPE#"<>9 AND "O"."TYPE#"<>11 AND "O"."TYPE#"<>12 AND
	      "O"."TYPE#"<>13 AND "O"."TYPE#"<>14 AND "O"."TYPE#"<>22 AND "O"."TYPE#"<>87 AND
	      "O"."TYPE#"<>88 OR BITAND("U"."SPARE1",16)=0 OR ("O"."TYPE#"=4 OR "O"."TYPE#"=5
	      OR "O"."TYPE#"=7 OR "O"."TYPE#"=8 OR "O"."TYPE#"=9 OR "O"."TYPE#"=10 OR
	      "O"."TYPE#"=11 OR "O"."TYPE#"=12 OR "O"."TYPE#"=13 OR "O"."TYPE#"=14 OR
	      "O"."TYPE#"=22 OR "O"."TYPE#"=87) AND (SYS_CONTEXT('userenv','current_edition_na
	      me')='ORA$BASE' AND "U"."TYPE#"<>2 OR "U"."TYPE#"=2 AND
	      "U"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','current_edition_id')) OR  EXISTS
	      (SELECT 0 FROM SYS."USER$" "U2",SYS."OBJ$" "O2" WHERE
	      "O2"."OWNER#"="U2"."USER#" AND "O2"."TYPE#"=88 AND "O2"."DATAOBJ#"=:B1 AND
	      "U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','current_editio
	      n_id')))))
   5 - access("O"."SPARE3"="U"."USER#")
   7 - access("O"."OWNER#"="U"."USER#")
   9 - filter("O"."NAME"<>'_NEXT_OBJECT' AND
	      "O"."NAME"<>'_default_auditing_options_' AND "O"."TYPE#"<>10 AND "O"."LINKNAME"
	      IS NULL AND BITAND("O"."FLAGS",128)=0)
  11 - access("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','
	      current_edition_id')))
       filter("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','
	      current_edition_id')))
  12 - access("O2"."DATAOBJ#"=:B1 AND "O2"."TYPE#"=88 AND
	      "O2"."OWNER#"="U2"."USER#")
  16 - access("L"."OWNER#"="U"."USER#")
BaldwinSu
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Oracle解释计划 执行计划
03-19
Oracle解释计划执行方式，数据分析原理。SQL优化原理。 教你如何看懂执行计划 --大伟哥
mysql 执行计划分析三看， explain,profiling,optimizer_trace
kevin_xiang的专栏
10-09 5170
step 1  使用explain 查看执行计划， 5.6后可以加参数 explain format=json xxx 输出json格式的信息 step 2  使用profiling详细的列出在每一个步骤消耗的时间，前提是先执行一遍语句。 #打开profiling 的设置 SET profiling = 1; SHOW VARIABLES LIKE '%profiling%';
oracle+执行计划+字节,Oracle中的执行计划
weixin_33014843的博客
04-03 194
要进行SQL的优化，必须要学会读执行计划。 1. autotrace 命令 SQL show autotrace; autotrace OFF SQL set autotrace; Usage: SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]] set autotrace on 表示输出SQL的结果，以及执行计划...
执行计划中各个字段的含义描述及获取方法
u012436346的专栏
04-05 4675
本篇文章主要介绍了"执行计划中各个字段的含义描述及获取方法"，主要涉及到执行计划中各个字段的含义描述及获取方法方面的内容，对于执行计划中各个字段的含义描述及获取方法感兴趣的同学可以参考一下。 一、概述 当一条SQL执行很慢时，我们需要分析SQL的执行计划来判断问题的所在。得到一条sql的执行计划有如下三种方法： 1）set autot trace（设置autotrace）   
trace分析优化器执行计划 || optimizer
qq_39368007的博客
03-14 119
……
oracle执行计划
06-16
执行计划表示了SQL语句执行顺序与方法。 执行计划的存储方式： 一但产生执行计划。这个计划就会和sql语句一起存储在library cache中。sql语句按照hash的算法，产生hash 值，这里，我们可以把hash值当做一个PK值，...
mysql 索引与执行计划
10-21
1. 索引与执行计划 1 1.1. 索引入门 1 1.1.1. 索引是什么 1 1.1.2. 索引得分类 3 1.1.3. 基础语法 3 1.2. 执行计划 3 1.2.1. 什么是执行计划 3 1.2.2. 执行计划的作用 3 1.2.3. 执行计划的语法 4 1.2.4. 执行计划...
Oracle执行计划.ppt
11-12
Oracle 执行计划 Oracle 执行计划是 Oracle 数据库中的一种机制，用于确定如何访问存储器，得到需要的结果集。执行计划的主要内容包括访问方式和访问顺序。下面是 Oracle 执行计划的详细知识点： 一、执行计划的...
hive执行计划可视化工具
最新发布
05-31
然而，对于复杂的Hive查询，理解其执行计划有时会变得相当困难，这就是Hive执行计划可视化工具的作用。这些工具通过图形化的方式展示查询的执行流程，帮助用户更好地理解性能瓶颈和优化查询。 标题中的“Hive执行...
SparkSQL物理执行计划各操作实现
02-21
Catalyst作为一个实现无关的查询优化框架，在优化后的逻辑执行计划到真正的物理执行计划这部分只提供了接口，没有提供像Analyzer和Optimizer那样的实现。本文介绍的是SparkSQL组件各个物理执行计划的操作实现。把...
获取执行计划
guhui2509的专栏
04-21 591
<br />处理执行计划需要采取以下三步：获取、解释、判定效率<br />获取执行计划：<br />-执行SQL语句EXPLAIN PLAN，然后查询结果输出表<br />-查询一张动态性能视图，它显示缓存在库缓存中的执行计划<br />-查询自动工作量资料库(Automatic Workload Repository)或查询Statspack表，它显示存储在资料库中的执行计划<br />-启动提供执行计划的跟踪功能<br />SQL语句EXPLAIN PLAN<br />-通过它可以询问优化器，对给定的S
mysql调优：执行计划、optimizer_trace 查看执行流程、调优
SHOUGOUGOU的专栏
03-31 445
SQL执行计划 1、如何查看sql的执行计划 在需要执行的查询SQL前添加一个关键字“EXPLAIN” EXPLAIN中的列 （1）id 1、标识select所属的行，sql语句中有多少个select就有多少个id，并且id的顺序是按照select出现的顺序增长的 2、id越大，越先执行 3、id相同，从上往下执行 4、id为NUll的最后执行 (2) select_type 显示对应行是简单还是复杂select，SIMPLE值表明没有子查询或Union，如果有子查询，那么最.
执行计划(CBO)
DINYA
06-05 1876
导致不使用CBO而使用RBO的三个原因:1.optimizer_mode设置为rule或optimizer_goal设置为rule2.查询中包含有rule提示. 3.查询的所有表都没有被分析过,并且查询不包含任何提示.RBO的工作方式:    RBO在决定SQL的执行计划时,只使用少量信息:        SQL文本.        SQL的FROM后面的基本信息,如表,簇,视图,参考的其他字
更详细的执行计划 optimizer_trace
三易专栏
08-26 205
目录 数据准备 查看 optimizer_trace 数据准备 CREATE TABLE `t2` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11), `b` int(11), `c` varchar(16) , `create_time` datetime, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 插入数据 for(int i=1; i&
执行计划 dynamic_sampling
csh38127668的博客
03-30 193
现有表t(object_id number,object_name varchar2(20))，表中有上万条记录，并且绝大多数记录的object_id=9999;先来看一下select * from t where objec...
ORACLE 执行计划中cost cardinality bytes cpu_cost io_cost解释
novelly的专栏
02-16 4847
ORACLE 10G R2_执行计划中cost cardinality bytes cpu_cost io_cost解释 2009-12-29 15:42 从网上找到的资料，加上我在文档中查到的内容： ■ Cost The cost assigned to each step of the query plan by the CBO. The CBO works by ge
oracle cost cardinality,ORACLE 执行计划中cost cardinality bytes cpu_cost io_cost解释
weixin_36317502的博客
04-02 952
从网上找到的资料，加上我在文档中查到的内容：■ Cost The cost assigned to each step of the query plan by the CBO. The CBO works bygenerating many different execution paths/plans for the same query and assigns a cost toeach a...
Oracle 中的动态采样（dynamic sampling）相关示例
热门推荐
renfengjun
03-17 1万+
Oracle dynamic sampling 功能说明。（附详细示例）
【DB笔试面试631】在Oracle中，什么是动态采样（Dynamic Sampling）？
小麦苗DBA宝典
09-03 1085
♣题目部分在Oracle中，什么是动态采样（Dynamic Sampling）？ ♣答案部分对于没有收集统计信息的表，Oracle为了能够得到相对准确的执行计划，...
Oracle执行计划1.ppt
11-21
"Oracle执行计划1.ppt" Oracle执行计划是数据库管理系统中一个至关重要的概念，特别是在Oracle数据库中，它描述了Oracle如何执行SQL查询的详细步骤。执行计划是Oracle内部的一种机器级代码，决定了数据如何从存储器...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值