首页 Oracle执行计划讲解

Oracle执行计划讲解

举报
开通vip

Oracle执行计划讲解【精品文档】如有侵权,请联系网站删除,仅供学习与交流.....精品文档......Oracle执行计划讲解Oracle执行计划讲解看懂Oracle执行计划是优化的第一步,让我们从下面的例子开始吧。 下面为补充内容1、创建测试表 SQL> create table t as select 1 id,object_name from dba_objects;  Table created  SQL> update t set id=99 where rownum=1;  1 row updated  SQL> comm...

Oracle执行计划讲解
【精品文档】如有侵权,请联系网站删除,仅供学习与交流.....精品文档......Oracle执行 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 讲解Oracle执行计划讲解看懂Oracle执行计划是优化的第一步,让我们从下面的例子开始吧。 下面为补充内容1、创建测试表 SQL> create table t as select 1 id,object_name from dba_objects;  Table created  SQL> update t set id=99 where rownum=1;  1 row updated  SQL> commit;  Commit complete  SQL> create index t_ind on t(id);  Index created         oracle优化器:RBO和CBO两种,从oracle10g开始优化器已经抛弃了RBO,下面的列子说明CBO大概是怎样的SQL>  select /*+dynamic_sampling(t 0) */* from t where id=1;  50819 rows selected.  Execution Plan  Plan hash value: 1376202287  | Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT            |       |   195 | 15405 |    51   (0)| 00:00:01 |  |   1 |  TABLE ACCESS BY INDEX ROWID| T     |   195 | 15405 |    51   (0)| 00:00:01 |  |*  2 |   INDEX RANGE SCAN          | T_IND |    78 |       |    50   (0)| 00:00:01 |  Predicate Information (identified by operation id):     2 - access("ID"=1)        现象t表还没有被 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 ,提示/*+dynamic_sampling(t0)*/*的目的是让CBO无法通过动态采样获取表中的实际数据情况,此时CBO只能根据T表中非常有限的信息(比如表中的extents数量,数据块的数量)来猜测表中的数据。从结果中可以看到CBO猜出表中id=1的有195条,这个数值对于表的总数来说,是一个非常小的值,所以CBO选择了索引而不是全表扫描。     而实际情况如下所示:SQL> select * from  t where id=1    2  ;  50819 rows selected.  Execution Plan  Plan hash value: 1601196873  | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT  |      | 49454 |  3815K|    67   (2)| 00:00:01 |  |*  1 |  TABLE ACCESS FULL| T    | 49454 |  3815K|    67   (2)| 00:00:01 |  Predicate Information (identified by operation id):     1 - filter("ID"=1)        通过动态取样,CBO估算出行数为49454,非常接近于真实50820数目。选择了全表扫描。      我们来收集一下统计信息SQL> exec dbms_stats.gather_table_stats(user,'t',cascade => true);  SQL> select * from  t where id=1;  50819 rows selected.  Execution Plan  Plan hash value: 1601196873  | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT  |      | 50815 |  1339K|    67   (2)| 00:00:01 |  |*  1 |  TABLE ACCESS FULL| T    | 50815 |  1339K|    67   (2)| 00:00:01 |  Predicate Information (identified by operation id):     1 - filter("ID"=1)  现在扫描过的行数为50815。如果我们更新了所有的id为99看看。SQL> update t set id=99;  50820 rows updated  SQL> select * from  t where id=99;  Execution Plan  Plan hash value: 1376202287  | Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT            |       |     1 |    27 |     2   (0)| 00:00:01 |  |   1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |    27 |     2   (0)| 00:00:01 |  |*  2 |   INDEX RANGE SCAN          | T_IND |     1 |       |     1   (0)| 00:00:01 |  Predicate Information (identified by operation id):     2 - access("ID"=99)         因为没有对表进行分析,所以表中的分析数据还是之前的信息,CBO并不知道。我们可以看出Rows值为1,也就是说CBO人为表T中的ID=99的值只有1条,所有选择仍然是索引。       我们收集一把统计信息。 SQL> exec dbms_stats.gather_table_stats(user,'t',cascade => true);  PL/SQL procedure successfully completed  SQL> select * from  t where id=99;  50820 rows selected.  Execution Plan  Plan hash value: 1601196873  | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT  |      | 50815 |  1339K|    67   (2)| 00:00:01 |  |*  1 |  TABLE ACCESS FULL| T    | 50815 |  1339K|    67   (2)| 00:00:01 |  Predicate Information (identified by operation id):     1 - filter("ID"=99)  上面为补充内容,下面正式开始1、sql的执行计划 创建测试表SQL> create table t1(id int,name varchar2(1000));  Table created  SQL> create table t2(id int,name varchar2(1000));  Table created  SQL> create index ind_t1 on t1(id);  Index created  SQL> create index ind_t2 on t2(id);  Index created  SQL> create index ind_t2_name on t2(name);  Index created  SQL> insert into t1 select  a.OBJECT_ID,a.OBJECT_NAME from all_objects a;  50206 rows inserted  SQL> insert into t2 select  a.OBJECT_ID,a.OBJECT_NAME from all_objects a where rownum<=20;  20 rows inserted  SQL> commit;  Commit complete  SQL> exec dbms_stats.gather_table_stats(user,'t1',cascade => true);  PL/SQL procedure successfully completed  SQL> exec dbms_stats.gather_table_stats(user,'t2',cascade => true);  PL/SQL procedure successfully completed  2、产生执行计划SQL> select * from t1,t2 where t1.id= t2.id;  20 rows selected.  Execution Plan  Plan hash value: 828990364  | Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT            |        |    20 |   780 |    43   (0)| 00:00:01 |  |   1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |    28 |     2   (0)| 00:00:01 |  |   2 |   NESTED LOOPS              |        |    20 |   780 |    43   (0)| 00:00:01 |  |   3 |    TABLE ACCESS FULL        | T2     |    20 |   220 |     3   (0)| 00:00:01 |  |*  4 |    INDEX RANGE SCAN         | IND_T1 |     1 |       |     1   (0)| 00:00:01 |  Predicate Information (identified by operation id):     4 - access("T1"."ID"="T2"."ID")  Statistics            1  recursive calls            0  db block gets           37  consistent gets            0  physical reads            0  redo size         1452  bytes sent via SQL*Net to client          503  bytes received via SQL*Net from client            3  SQL*Net roundtrips to/from client            0  sorts (memory)            0  sorts (disk)           20  rows processed          看执行计划时,我们首先从缩进最大的行读取,它是最先被执行的步骤。在执行计划中:id=3和id=4是最先被执行的,|   3 |    TABLE ACCESS FULL        | T2     |    20 |   220 |     3   (0)| 00:00:01 |  |*  4 |    INDEX RANGE SCAN         | IND_T1 |     1 |       |     1   (0)| 00:00:01 |           两行缩进一样的,最上面的最先被执行,在这里就是id=3|   3 |    TABLE ACCESS FULL        | T2     |    20 |   220 |     3   (0)| 00:00:01 |          选择次之缩进的行数id=2,表连接方式为NESTEDLOOPS。|   2 |   NESTED LOOPS              |        |    20 |   780 |    43   (0)| 00:00:01 |           然后是id=1,扫描表的方式为TABLEACCESSBYINDEXROWID|   1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |    28 |     2   (0)| 00:00:01 |        最后是id=0|   0 | SELECT STATEMENT            |        |    20 |   780 |    43   (0)| 00:00:01 | 我们 翻译 阿房宫赋翻译下载德汉翻译pdf阿房宫赋翻译下载阿房宫赋翻译下载翻译理论.doc 成语言大概如下,     从t2表第一行读取,查看每一行是否符合下面条件: "T1"."ID"="T2"."ID"      如果符合就拿出一行来,扫描整个t2表,这个过程就叫NESTEDLOOPS      当整个t2表被扫描完之后,会产生一个结果集,这个结果集是IND_T1的一个索引集,然后oracle根据索引键值上的rowid去T1表中找到相应的记录,就是这一步:TABLEACCESSBYINDEXROWID       然后将结果返回:SELECTSTATEMENT       id列为:id=3->id=4->id=2->id=1->id=0让我们再看一看表中每一行表示什么含义:1)Operation列:当前操作的内容。2)Rows列:就是当前操作的 cardinality ,Oracle估算当前操作的返回结果集。3)Cost(%CPU):Oracle计算出来的一个数值(代价),用于说明sql执行的代价。4)Time列:Oracle估算当前操作的时间。PredicateInformation(identifiedbyoperationid):---------------------------------------------------  4-access("T1"."ID"="T2"."ID")这里有access和filter区别,access就表示这个谓词的条件的值将会影响数据的访问路径(一般针对索引),filter只起过滤作用。举个例子SQL> select * from t1 where t1.name='AA';  no rows selected  Execution Plan  Plan hash value: 3617692013  | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT  |      |     2 |    56 |    69   (2)| 00:00:01 |  |*  1 |  TABLE ACCESS FULL| T1   |     2 |    56 |    69   (2)| 00:00:01 |  Predicate Information (identified by operation id):     1 - filter("T1"."NAME"='AA')  懂了吧。下面我们来仔细分析Operation里面的内容

a、表访问方式

1.Full Table Scan (FTS) 全表扫描  

In a FTS operation, the whole table is read up to the high water mark (HWM). The HWM marks the last block in the table that has ever had data written to it. If you have deleted all the rows then you will still read up to the HWM. Truncate resets the HWM back to the start of the table. FTS uses multiblock i/o to read the blocks from disk.   --全表扫描模式下会读数据到表的高水位线(HWM即表示表曾经扩展的最后一个数据块),读取速度依赖于Oracle初始化参db_block_multiblock_read_count(我觉得应该这样翻译:FTS扫描会使表使用上升到高水位(HWM),HWM标识了表最后写入数据的块,如果你用DELETE删除了所有的数据表仍然处于高水位(HWM),只有用TRUNCATE才能使表回归,FTS使用多IO从磁盘读取数据块).

Query Plan   SELECT STATEMENT [CHOOSE] Cost=1  **INDEX UNIQUE SCAN EMP_I1   --如果索引里就找到了所要的数据,就不会再去访问表

   2.Index Lookup 索引扫描  There are 5 methods of index lookup:    

1)index unique scan   --索引唯一扫描   Method for looking up a single key value via a unique index. always returns a single value, You must supply AT LEAST the leading column of the index to access data via the index.  eg:SQL> select empno,ename from emp where empno=10;

SQL> select empno,ename from emp where empno=10;  no rows selected  Execution Plan  Plan hash value: 2949544139  | Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT            |        |     1 |    20 |     1   (0)| 00:00:01 |  |   1 |  TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    20 |     1   (0)| 00:00:01 |  |*  2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     1   (0)| 00:00:01 |  Predicate Information (identified by operation id):     2 - access("EMPNO"=10)  Statistics           24  recursive calls            0  db block gets            3  consistent gets            0  physical reads            0  redo size          385  bytes sent via SQL*Net to client          481  bytes received via SQL*Net from client            1  SQL*Net roundtrips to/from client            0  sorts (memory)            0  sorts (disk)            0  rows processed 2)indexrangescan --索引局部扫描Indexrangescanisamethodforaccessingarangevaluesofaparticularcolumn.ATLEASTtheleadingcolumnoftheindexmustbesuppliedtoaccessdataviatheindex.Canbeusedforrangeoperations(e.g.><<>>=<=between).SQL> select empno from emp where EMPNO>=7902;  Execution Plan  Plan hash value: 1567865628  | Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT |        |     2 |    26 |     2   (0)| 00:00:01 |  |*  1 |  INDEX RANGE SCAN| PK_EMP |     2 |    26 |     2   (0)| 00:00:01 |  Predicate Information (identified by operation id):     1 - access("EMPNO">=7902)  Note     - dynamic sampling used for this statement  Statistics            0  recursive calls            0  db block gets            2  consistent gets            0  physical reads            0  redo size          569  bytes sent via SQL*Net to client          492  bytes received via SQL*Net from client            2  SQL*Net roundtrips to/from client            0  sorts (memory)            0  sorts (disk)            2  rows processed  3)indexfullscan --索引全局扫描FullindexscansareonlyavailableintheCBOasotherwiseweareunabletodeterminewhetherafullscanwouldbeagoodideaornot.WechooseanindexFullScanwhenwehavestatisticsthatindicatethatitisgoingtobemoreefficientthanaFulltablescanandasort.ForexamplewemaydoaFullindexscanwhenwedoanunboundedscanofanindexandwantthedatatobeorderedintheindexorder.SQL> select empno from emp order by empno;  14 rows selected.  Execution Plan  Plan hash value: 179099197  | Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT |        |    14 |   182 |     2   (0)| 00:00:01 |  |   1 |  INDEX FULL SCAN | PK_EMP |    14 |   182 |     2   (0)| 00:00:01 |  Note     - dynamic sampling used for this statement  Statistics            4  recursive calls            0  db block gets           11  consistent gets            0  physical reads            0  redo size          676  bytes sent via SQL*Net to client          492  bytes received via SQL*Net from client            2  SQL*Net roundtrips to/from client            0  sorts (memory)            0  sorts (disk)           14  rows processed 4)indexfastfullscan --索引快速全局扫描,不带orderby情况下常发生Scansalltheblockintheindex,Rowsarenotreturnedinsortedorder,Introducedin7.3andrequiresV733_PLANS_ENABLED=TRUEandCBO,maybehintedusingINDEX_FFShint,usesmultiblocki/o,canbeexecutedinparallel,canbeusedtoaccesssecondcolumnofconcatenatedindexes.Thisisbecauseweareselectingalloftheindex.SQL> select empno from emp;  14 rows selected.  Execution Plan  Plan hash value: 366039554  | Id  | Operation            | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT     |        |    14 |   182 |     2   (0)| 00:00:01 |  |   1 |  INDEX FAST FULL SCAN| PK_EMP |    14 |   182 |     2   (0)| 00:00:01 |  Note     - dynamic sampling used for this statement  Statistics            4  recursive calls            0  db block gets           13  consistent gets            0  physical reads            0  redo size          676  bytes sent via SQL*Net to client          492  bytes received via SQL*Net from client            2  SQL*Net roundtrips to/from client            0  sorts (memory)            0  sorts (disk)           14  rows processed  5)indexskipscan --索引跳跃扫描,where条件列是非索引的前导列情况下常发生Indexskipscanfindsrowsevenifthecolumnisnottheleadingcolumnofaconcatenatedindex.Itskipsthefirstcolumn(s)duringthesearch.SQL> create index i_emp on emp(empno, ename);  Index created.  SQL> select /*+ index_ss(emp i_emp)*/ job from emp where ename='SMITH';  Execution Plan  Plan hash value: 98078853  | Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT            |       |     1 |    13 |     5   (0)| 00:00:01 |  |   1 |  TABLE ACCESS BY INDEX ROWID| EMP   |     1 |    13 |     5   (0)| 00:00:01 |  |*  2 |   INDEX SKIP SCAN           | I_EMP |     1 |       |     4   (0)| 00:00:01 |  Predicate Information (identified by operation id):     2 - access("ENAME"='SMITH')         filter("ENAME"='SMITH')  Note     - dynamic sampling used for this statement  Statistics            5  recursive calls            0  db block gets           11  consistent gets            0  physical reads            0  redo size          513  bytes sent via SQL*Net to client          492  bytes received via SQL*Net from client            2  SQL*Net roundtrips to/from client            0  sorts (memory)            0  sorts (disk)            1  rows processed  3.Rowid物理ID扫描Thisisthequickestaccessmethodavailable.Oracleretrievesthespecifiedblockandextractstherowsitisinterestedin. --Rowid扫描是最快的访问数据方式SQL> select * from emp where rowid='AAAjFUAAEAAABZ1AAM';  Execution Plan  Plan hash value: 1116584662  | Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT           |      |     1 |    99 |     1   (0)| 00:00:01 |  |   1 |  TABLE ACCESS BY USER ROWID| EMP  |     1 |    99 |     1   (0)| 00:00:01 |  Statistics            1  recursive calls            0  db block gets            1  consistent gets            0  physical reads            0  redo size          983  bytes sent via SQL*Net to client          492  bytes received via SQL*Net from client            2  SQL*Net roundtrips to/from client            0  sorts (memory)            0  sorts (disk)            1  rows processed  b、运算符1.sort  --排序,很消耗资源Thereareanumberofdifferentoperationsthatpromotesorts:(1)orderbyclauses(2)groupby(3)sortmergejoin–-这三个会产生排序运算 2.filter  --过滤,如notin、min函数等容易产生Hasanumberofdifferentmeanings,usedtoindicatepartitionelimination,mayalsoindicateanactualfilterstepwhereonerowsourceisfiltering,another,functionssuchasminmayintroducefilterstepsintoqueryplans. 3.view  --视图,大都由内联视图产生(可能深入到视图基表)Whenaviewcannotbemergedintothemainqueryyouwilloftenseeaprojectionviewoperation.Thisindicatesthatthe'view'willbeselectedfromdirectlyasopposedtobeingbrokendownintojoinsonthebasetables.Anumberofconstructsmakeaviewnonmergeable.Inlineviewsarealsononmergeable.SQL> select ename,tot from emp,(select empno,sum(empno) tot from emp group by empno) tmp where emp.empno = tmp.empno;  14 rows selected.  Execution Plan  Plan hash value: 138960760  | Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT             |          |    14 |   644 |     4  (25)| 00:00:01 |  |   1 |  MERGE JOIN                  |          |    14 |   644 |     4  (25)| 00:00:01 |  |   2 |   TABLE ACCESS BY INDEX ROWID| EMP      |    14 |   280 |     2   (0)| 00:00:01 |  |   3 |    INDEX FULL SCAN           | PK_EMPNO |    14 |       |     1   (0)| 00:00:01 |  |*  4 |   SORT JOIN                  |          |    14 |   364 |     2  (50)| 00:00:01 |  |   5 |    VIEW                      |          |    14 |   364 |     1   (0)| 00:00:01 |  |   6 |     HASH GROUP BY            |          |    14 |   182 |     1   (0)| 00:00:01 |  |   7 |      INDEX FULL SCAN         | PK_EMPNO |    14 |   182 |     1   (0)| 00:00:01 |  Predicate Information (identified by operation id):     4 - access("EMP"."EMPNO"="TMP"."EMPNO")         filter("EMP"."EMPNO"="TMP"."EMPNO")  Note     - dynamic sampling used for this statement  Statistics           43  recursive calls            0  db block gets           61  consistent gets            0  physical reads            0  redo size          821  bytes sent via SQL*Net to client          492  bytes received via SQL*Net from client            2  SQL*Net roundtrips to/from client            5  sorts (memory)            0  sorts (disk)           14  rows processed   4.partitionview  --分区视图Partitionviewsarealegacytechnologythatweresupercededbythepartitioningoption.Thissectionofthearticleisprovidedasreferenceforsuchlegacysystems.3、让我们再看看统计信息部分SQL> set autotrace traceonly;  SQL> select count(*) from emp;  Execution Plan  Plan hash value: 2083865914  | Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT   |      |     1 |     3   (0)| 00:00:01 |  |   1 |  SORT AGGREGATE    |      |     1 |            |          |  |   2 |   TABLE ACCESS FULL| EMP  |    14 |     3   (0)| 00:00:01 |  Note     - dynamic sampling used for this statement  Statistics            5  recursive calls  (归调用次数)            0  db block gets  (从磁盘上读取的块数,即通过update/delete/select for update读的次数)           15  consistent gets (从内存里读取的块数,即通过不带for update的select 读的次数)            0  physical reads (物理读—从磁盘读到数据块数量,一般来说是'consistent gets' + 'db block gets')            0  redo size (重做数——执行SQL的过程中,产生的重做日志的大小)          515  bytes sent via SQL*Net to client          492  bytes received via SQL*Net from client            2  SQL*Net roundtrips to/from client            0  sorts (memory) (在内存中发生的排序)            0  sorts (disk) (在硬盘中发生的排序)            1  rows processed  说明:Cost=(Single block I/O cost+ Multiblock I/O cost+   CPU cost)/sreadtim  序号列名解释1dbblockgets从buffercache中读取的block的数量2consistentgets从buffercache中读取的undo数据的block的数量3physicalreads从磁盘读取的block的数量4redosizeDML生成的redo的大小5sorts(memory)在内存执行的排序量6sorts(disk)在磁盘上执行的排序量现在我们讲讲oracle执行计划里面每个参数的含义我们以下面的一个例子来讲解这里做个补充:trace的类型一共有以下几种序号命令解释1SET AUTOTRACE OFF此为默认值,即关闭Autotrace 2SET AUTOTRACE ON EXPLAIN只显示执行计划3SET AUTOTRACE ON STATISTICS 只显示执行的统计信息4SET AUTOTRACE ON 包含2,3两项内容5SET AUTOTRACE TRACEONLY 与ON相似,但不显示语句的执行结果 我喜欢SET AUTOTRACE TRACEONLY,我们以后的例子都是基于这种方式的SQL> select * from departments a where a.department_id in (select b.department_id from employees b where b.employee_id=205);  Execution Plan  Plan hash value: 2782876085  | Id  | Operation                    | Name          | Rows  | Bytes | Cost (%CPU)| Time     |  |   0 | SELECT STATEMENT             |               |     1 |    27 |     2   (0)| 00:00:01 |  |   1 |  NESTED LOOPS                |               |     1 |    27 |     2   (0)| 00:00:01 |  |   2 |   TABLE ACCESS BY INDEX ROWID| EMPLOYEES     |     1 |     7 |     1   (0)| 00:00:01 |  |*  3 |    INDEX UNIQUE SCAN         | EMP_EMP_ID_PK |     1 |       |     0   (0)| 00:00:01 |  |   4 |   TABLE ACCESS BY INDEX ROWID| DEPARTMENTS   |    27 |   540 |     1   (0)| 00:00:01 |  |*  5 |    INDEX UNIQUE SCAN         | DEPT_ID_PK    |     1 |       |     0   (0)| 00:00:01 |  Predicate Information (identified by operation id):     3 - access("B"."EMPLO
本文档为【Oracle执行计划讲解】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
个人认证用户
simle
我是一线教师 有丰富的 教学经验
格式:doc
大小:249KB
软件:Word
页数:50
分类:初中语文
上传时间:2022-05-10
浏览量:1