MSSQL网页编程之利用查询改写进步查询功能
两个到底是哪一个给出了MySQL这个名字至今依然是个迷，包括开发者在内也不知道。功能无需改动SQL查询就能够年夜幅进步查询功能。
你是不是为守候你的查询前往了局而感应怠倦？你是不是已为加强索引和调优SQL而感应怠倦，但仍旧不克不及进步查询功能？那末，你是不是已思索创立物化视图？有了物化视图，那些已往必要数小时运转的呈报能够在几分钟内完成。物化视图能够包含连接（join）和汇合（aggregate），它供应了一种贮存估计算了局的办法。
在实行一个查询时，优化器会判断会见物化视图或数据驻留的基本表是不是更快一些。假如优化器判断查询物化视图是更好的办理计划，那末优化器会在一个被称为“查询改写”（queryrewrite）的过程当中改写SQL查询。在这个过程当中，不必要对任何SQL或使用程序代码举行修正，以是任何使用SQL会见数据库的使用程序或特定查询工具都可得益于利用物化视图。当为盘算了局而必要会见的数据数目宏大于了局（如汇合）的巨细时，最合适利用查询改写，可是它也可被用于减速高贵的连接或计划。
本文起首先容了优化器能够实行的查询改写范例。然后，它会商了匡助断定创立最好物化视图集的工具，使优化器可以改写多个查询。使用这些工具创立的物化视图在其基本数据产生变更时还能够疾速革新。假如你不晓得创立一个物化视图、一个索引或同时创立二者哪一种更好，那末在Oracle数据库10g中引进的SQLAccessAdvisor能够经由过程剖析给定的事情负荷匡助你做出决意。
查询改写范例
大概有很多范例的查询改写；当物化视图的界说查询与查询的文本完整婚配时，就产生最复杂和最明显范例的查询改写。可是，当不异物化视图可用于响应多个查询时，就能够完成查询改写的最年夜优点。如今，我们将举例申明一些Oracle优化器利用的划定规矩，以断定它是不是将利用物化视图来呼应。
关于本文中的示例，能够思索将一个星形形式中的PURCHASES表看做现实表（facttable），其局限由time_key分别。维度表（dimensiontable）--TIME、PRODUCT和CUSTOMERS--包括主键time_key、product_id和cust_id。在PURCHASES表中有援用各个维度表的外键束缚。
思索一下清单1中所创立的物化视图，该视图按月按product_id盘算发卖总额和发卖总次数。注重：关于用于查询改写的物化视图，必需有ENABLEQUERYREWRITE子句。另有，初始化参数QUERY_REWRITE_ENABLED必需被设置为TRUE。
代码清单1：创立月发卖物化视图
CREATEMATERIALIZEDVIEWmonthly_sales_mvENABLEQUERYREWRITEASSELECTt.month,p.product_id,SUM(ps.purchase_price)assum_of_sales,COUNT(ps.purchase_price)astotal_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idGROUPBYt.month,p.product_id;
汇合盘算
在本文的示例中，我们将申明物化视图的查询并显现由EXPLAINPLAN失掉的实行企图。清单2中的查询请求按月和按产物的均匀推销代价。优化器可使用物化视图monthly_sales_mv，使用SUM和COUNT汇合盘算均匀推销代价。这个示例申明了一种叫做“汇合盘算”的手艺。
代码清单2：取得均匀(AVG)推销代价
SELECTt.month,p.product_id,AVG(ps.purchase_price)asavg_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idGROUPBYt.month,p.product_id;IdOperationName________________________________________________SELECTSTATEMENTMAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_MV
Joinback
joinback手艺十分有效，由于它同意当物化视图中没有列时举行查询改写。清单3中的查询请求按月和按产物种别的发卖总额，而该物化视图中并没有product.category列。但是，产物表的主键product_id列则位于物化视图中。因而，优化器能够将物化视图与产物表连接起来以失掉产物种别。
代码清单3：经由过程joinback取得发卖总额
SELECTt.month,p.category,SUM(ps.purchase_price)assum_of_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idGROUPBYt.month,p.category;IdOperationName__________________________________________________0SELECTSTATEMENT1SORTGROUPBY2HASHJOIN3TABLEACCESSFULLPRODUCT4MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_MV
利用维度举行查询改写
在一个利用维度建模技能计划的典范数据堆栈中，数据中存在着出名的“条理干系”。比方，在工夫条理中，“天”堆集成“月”，“月”又堆集成“年”。在Oracle数据库中，可使用CREATEDIMENSION语句创立一个叫做“DIEMNSION”的工具，向优化器声明这类干系。维度工具是一个形貌性工具，除其元数据外，它不占用空间。利用DIMENSION工具声明的干系听说是可托的。Oracle不会考证这一干系关于你的数据是不是必定建立，它只是假定数据库办理员已判断这些干系是准确的。可托信息的其他示例是利用NOVALIDATERELY标志的束缚及注册为物化视图的先存表。
关于接纳可托信息（包含维度）的查询改写，初始化参数QUERY_REWRITE_INTEGRITY必需被设置为TRUSTED，以下所示：
ALTERSESSIONSETquery_rewrite_integrity=TRUSTED;
比方，假定有一个工夫维度，其声明以下：
CREATEDIMENSIONtime_dimLEVELtime_keyIStime.time_keyLEVELmonthIStime.monthLEVELquarterIStime.quarterLEVELyearIStime.yearHIERARCHYcalendar_rollup(time_keyCHILDOFmonthCHILDOFquarterCHILDOFyear)ATTRIBUTEtime_keydetermines(day_of_week,holiday)ATTRIBUTEmonthdetermines(month_name);
如今，假如具有清单4中请求按年的发卖额的查询，你仍旧可使用monthly_sales_mv物化视图，由于维度工具中的HIERARCHY子句告知Oracle数据库月发卖额能够堆集成年发卖额。它使用后面形貌的joinback技能由物化视图中的“月”列失掉“年”列的值。
代码清单4：经由过程joinback和HIERARCHY取得发卖总额
SELECTt.year,p.category,SUM(ps.purchase_price)assum_of_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idGROUPBYt.year,p.category;IdOperationName__________________________________________________0SELECTSTATEMENT1SORTGROUPBY2HASHJOIN3HASHJOIN4VIEW5SORTUNIQUE6TABLEACCESSFULLTIME7MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_MV8TABLEACCESSFULLPRODUCT
维度的ATTRIBUTE子句指了然一对一干系。比方，你能够判断从time_key入手下手是一周中的哪一天。假定你但愿失掉每一年1月份的发卖总额：你仍旧可使用清单5中所示的monthly_sales_mv物化视图。注重该查询的WHERE子句怎样具有一个在物化视图中没有呈现的选择前提。
代码清单5：经由过程joinback和ATTRIBUTE取得发卖总额
SELECTt.year,p.category,SUM(ps.purchase_price)assum_of_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idANDt.month_name=JanuaryGROUPBYt.year,p.category;IdOperationName__________________________________________________0SELECTSTATEMENT1SORTGROUPBY2HASHJOIN3HASHJOIN4VIEW5SORTUNIQUE6TABLEACCESSFULLTIME7MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_MV8TABLEACCESSFULLPRODUCT
假如优化器并未准期改写一个查询，可使用DBMS_MVIEW.EXPLAIN_REWRITE历程来诊断该成绩。这一特征呈现在Oracle9i数据库及今后的版本中。
过滤后的数据
到今朝为止，我们所给出的一切示例都利用了与推销表中的一切数据对应的物化视图。Oracle9i数据库具有在物化视图唯一一个数据子集情形下改写查询的才能。比方，假如你只对1997年到2002年的发卖额感乐趣，你能够将物化视图修正以下：
CREATEMATERIALIZEDVIEWfive_yr_monthly_sales_mvENABLEQUERYREWRITEASSELECTt.month,p.product_id,SUM(ps.purchase_price)assum_of_sales,COUNT(ps.purchase_price)astotal_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idANDt.yearbetween1997and2002GROUPBYt.month,p.product_id;
此物化视图可用于呼应请求从1997年至2002年纪据的查询，比方，清单6中的查询请求2000年的发卖额。
代码清单6：只查询物化视图
SELECTt.month,p.product_id,SUM(ps.purchase_price)assum_of_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idANDt.year=2000GROUPBYt.month,p.product_id;IdOperationName__________________________________________________SELECTSTATEMENT1HASHJOIN2VIEW3SORTUNIQUE4TABLEACCESSFULLTIME5MAT_VIEWREWRITEACCESSFULLFIVE_YR_MONTHLY_SALES_MV
在Oracle9i数据库中，假如物化视图中没有查询所必要的全体数据，查询就不会利用物化视图。在Oracle数据库10g中，已抓紧了这一限定，因而查询改写能够由物化视图中取得尽量多的数据，并使用详目表取得物化视图中没有的数据。和平常一样，优化器在做出实行此操纵的决意时思索了有改写和无改写情形下的查询本钱。
比方，清单7中的查询请求2000年至2003年之间的月发卖额，它将利用从2000年至2002年的物化视图，而只必要2003年的详目表。
代码清单7：查询物化视图和详目表
SELECTt.month,p.product_id,SUM(ps.purchase_price)assum_of_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idANDt.yearBETWEEN2000and2003GROUPBYt.month,p.product_id;IdOperationName__________________________________________________0SELECTSTATEMENT1SORTGROUPBY2VIEW3UNION-ALL4HASHJOIN5VIEW6SORTUNIQUE7TABLEACCESSFULLTIME8MAT_VIEWREWRITEACCESSFULLFIVE_YR_MONTHLY_SALES_MV9SORTGROUPBY10NESTEDLOOPS11HASHJOIN12TABLEACCESSFULLTIME13PARTITIONRANGEALL14TABLEACCESSFULLPURCHASES15INDEXRANGESCANPRODUCT_PK_INDEX
利用生效的物化视图举行查询改写
你大概想晓得假如详目表中的数据产生了变更会产生甚么情形。查询改写仍将利用物化视图吗？谜底决意于初始化参数QUERY_REWRITE_INTEGRITY的设置。QUERY_REWRITE_INTEGRITY参数有三个取值：STALE_TOLERATED暗示即便详目表中的数据已产生了变更，也仍旧利用物化视图。TRUSTED暗示物化视图未生效时才利用该视图。可是，查询改写可使用信托干系，如那些由维度工具或还没有失效的束缚所声明的干系。ENFORCED（缺省）暗示当物化视图包管能给出与利用详目表不异的了局时才利用它。利用这一参数意味着查询改写将不利用生效的物化视图或信托干系。
准确的设置决意于使用程序的数据需求。利用生效物化视图的查询改写大概会发生与没有利用查询改写时分歧的了局。但是，假如利用详目数据，大概会由于呼应查询必要处置的大批数据而使功能好转。在一个数据堆栈中，一般利用TRUSTED完全级别，由于如许才能够包管你只利用那些具有最新数据的物化视图；但是，被声明为准确（可托任）的干系也可用于查询改写。在年夜多半数据堆栈中，这些干系已在提取、转换和加载（ETL）历程失掉了考证，因而不再必要举行考证。
分区变更跟踪
在Oracle9i数据库中，Oracle引进了分区变更跟踪（PCT，PartitionChangeTracking）。使用这一特征，Oracle9i数据库能够跟踪物化视图的哪一部分对应于分区详目表的已更新部分。因而，假如查询不必要已更新表的部分，那末该物化视图仍旧可使用。
为了在物化视图中跟踪一个详目表的变更，必需对该表举行分区，而且该物化视图（在SELECT列表中）必需包含详目表的分区键或一个特别函数：DBMS_MVIEW.PMARKER。此函数为详目表中的每一个分区天生一个独一的标识符。
比方，由time_key对推销表举行分区。清单8中创立的物化视图与后面利用的monthly_sales_mv物化视图几近完整不异，只是该物化视图在推销表上包括了一个附加的DBMS_MVIEW.PMARKER函数。经由过程包括这一函数，当更新推销表时该物化视图同意PCT。注重：该物化视图本身其实不必要被分区。
代码清单8：具有DBMS_MVIEW.PMARKER函数的物化视图
CREATEMATERIALIZEDVIEWmonthly_sales_pct_mvENABLEQUERYREWRITEASSELECTDBMS_MVIEW.PMARKER(ps.rowid)pm,t.month,p.product_id,SUM(ps.purchase_price)assum_of_sales,COUNT(ps.purchase_price)astotal_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idGROUPBYDBMS_MVIEW.PMARKER(ps.rowid),t.month,p.product_id;
如今，假定我们向推销表中增添一个2003年4月的新分区，并且一个用户收回了一个哀求2002年3月的数据的查询，如清单9所示。在此查询中，我们其实不体贴2003年4月已更新的数据，以是将使用物化图对其举行改写，即便该物化视图已生效也是云云。
代码清单9：利用生效的物化视图举行查询改写
SELECTt.month,p.product_id,SUM(ps.purchase_price)FROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idANDps.time_key>=TO_DATE(01-03-2003,DD-MM-YYYY)ANDps.time_key<TO_DATE(01-04-2003,DD-MM-YYYY)GROUPBYt.month,p.product_id;IdOperationName__________________________________________________0SELECTSTATEMENT1SORTGROUPBY2MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_PCT_MV
假如查询请求从1月至4月的数据，在Orcale9i中，将不会为利用物化视图而对该查询举行改写。但在Oracle数据库10g中，可使用MONTHLY_SALES_PCT_MV和详目表的分离对该查询举行改写。
利用多个物化视图举行查询改写
后面已经提到，在Oracle10g数据库中，查询改写已失掉了加强，以是它可使用一个物化视图的部分数据和详目表的其他数据来呼应查询。现实上，查询改写能够分离利用两个或多个物化视图。比方，假定你为每5年的数据代价保护一个自力的物化视图：monthly_sales_1990-1994、monthly_sales_1995_to_2000、monthly_sales_2001_to_2005，等等。
那末，关于必要从1993年至2003年纪据的清单10中的查询，查询改写能够使用全体的三个物化视图。
代码清单10
SELECTt.month,p.product_id,SUM(ps.purchase_price)assum_of_sales,FROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idANDt.yearbetween1993and2003GROUPBYt.month,p.product_id;IdOperationName---------------------------------------------------------0SELECTSTATEMENT1SORTGROUPBY2VIEW3UNION-ALL4MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_2001_TO_20055MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_1995_TO_20006MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_1990_TO_1994
代码清单11
SELECTt.month,p.product_id,SUM(ps.purchase_price)assum_of_salesFROMtimet,productp,purchasespsWHEREt.time_key=ps.time_keyANDps.product_id=p.product_idANDt.yearbetween1989and1999GROUPBYt.month,p.product_id;IdOperationName---------------------------------------------------------1SELECTSTATEMENT1SORTGROUPBY2VIEW3UNION-ALL4MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_1995_TO_20005MAT_VIEWREWRITEACCESSFULLMONTHLY_SALES_1990_TO_19946SORTGROUPBY7NESTEDLOOPS8NESTEDLOOPS9TABLEACCESSFULLTIME10PARTITIONRANGEITERATOR11TABLEACCESSFULLPURCHASES12INDEXRANGESCANPRODUCT_PK_INDEX
清单11中的查询必要从1989年至1999年的数据，以是查询改写可使用物化视图monthly_sales_1990_to_1994和monthly_sales_1995_to_2000，并由详目表取得1989年的数据。这一历程本色上会比由详目表中取得一切数据更快一些。
Oracle10g数据库在查询改写方面有其他几个改善。在这些改善中值得注重的是Oracle10g数据库可以更好地撑持汇合运算符（UNION、UNIONALL等）加强了对多个表实例的查询的加强，并供应了对分区变更跟踪中的LIST和RANGE-LIST分区范例的撑持。
工具
你大概会一边浏览本文，一边喃喃自语：“嗯，我想我了解了你的意义，可是否有某些工具能够为我完成一切这些事情呢？”谜底是一定的。现实上，这些工具还相称多。
Oracle9i数据库援用了explain_mview和explain_rewrite。使用编程接口（API）EXPLAIN_MVIEW接纳一个物化视图界说，并倡议可以使用何品种型的分区变更跟踪操纵、是不是大概举行疾速革新，和能够完成何品种型的查询改写。当一个查询未被改写时，APIEXPLAIN_REWRITE将告知你SQL查询为何不利用查询改写。在两种情形下，工具包城市告知你成绩地点--比方，不克不及在一个特定列长进行毗连，但两个包都不会正确告知你假如办理这个成绩。这时候，就能够利用包括在Oracle10g数据库中的两个新工具--TUNE_MVIEW和SQLAccessAdvisor来匡助你办理这个成绩。
TUNE_MVIEWAPI将告知你怎样编写物化视图，使其能够疾速革新，并可使用本文所形貌的尽量多的初级查询改写范例。TUNE_MVIEWAPI的利用十分复杂：只必要将你的物化视图语句交给它，它就会判断该物化视图的最好情势。可是，假如你看到你的原始物化视图已被转换为多个新版本，也不要感应奇异。
让我们来看看TUNE_MVIEW怎样可以转换你的物化视图。假定我们有一个复杂的查询，并将其传送给EXPLAIN_MVIEW，如清单12所示，判别该物化视图在以后情势下是不是能够疾速革新。
代码清单12
BEGINdbms_mview.explain_mview(CREATEMATERIALIZEDVIEWcustomer_mvBUILDIMMEDIATEREFRESHFASTENABLEQUERYREWRITEASSELECTc.customer_id,c.town,COUNT(DISTINCT(product_id))ASdist_promo_cntFROMpurchasesps,customercWHEREps.customer_id=c.customer_idGROUPBYc.customer_id,c.town,ID1);END;/--seeifREFRESHFASTcapabilityisallowed(Y)ornot(N)SELECTcapability_name,possibleFROMmv_capabilities_tableWHEREcapability_name=REFRESH_FASTandSTATEMENT_ID=ID1;CAPABILITY_NAMEP---------------------------------REFRESH_FASTN
如今让我们利用不异的查询，并将其传送给TUNE_MVIEW，如以下代码所示：
variabletask_namevarchar2(2000);BEGINDBMS_ADVISOR.TUNE_MVIEW(:task_name,CREATEMATERIALIZEDVIEWcustomer_mvBUILDIMMEDIATEREFRESHFASTENABLEQUERYREWRITEASSELECTc.customer_id,c.town,COUNT(DISTINCT(product_id))ASdist_promo_cntFROMpurchasesps,customercWHEREps.customer_id=c.customer_idGROUPBYc.customer_id,c.town);END;/
代码清单13
SELECTstatementFROMuser_tune_mviewWHEREtask_name=:task_name;CREATEMATERIALIZEDVIEWEASYDW.CUSTOMER_MVBUILDIMMEDIATEREFRESHFASTWITHROWIDENABLEQUERYREWRITEASSELECTEASYDW.PURCHASES.PRODUCT_IDC1,EASYDW.CUSTOMER.TOWNC2,EASYDW.CUSTOMER.CUSTOMER_IDC3,COUNT(*)M1FROMEASYDW.PURCHASES,EASYDW.CUSTOMERWHEREEASYDW.CUSTOMER.CUSTOMER_ID=EASYDW.PURCHASES.CUSTOMER_IDGROUPBYEASYDW.PURCHASES.PRODUCT_ID,EASYDW.CUSTOMER.TOWN,EASYDW.CUSTOMER.CUSTOMER_ID;目次视图USER_TUNE_MVIEW将显现所失掉的物化视图，如清单13所示。只管它看起
来与我们的原始物化视图有点分歧，但在可使用原始物化视图的中央，仍旧可使用该
物化视图改写任何查询，别的，还能够疾速革新。
你也能够天生一个剧本来实行这些倡议，你大概但愿做的唯一修正就是改动物化视图的称号，和指定物化视图应该放在那里的存储语句和表空间。
如今，我们已有了一个物化视图，但假如我们不晓得创立甚么物化视图，那末应该怎样办？这时候，SQLAccessAdvisor能够匡助你，由于它会扫瞄你的体系，并它以为必要的索引和物化视图。
这些倡议是基于实践的事情负荷或依据你的形式所做出的假定提出的。当供应了SQL语句的实践事情负荷时，将失掉最好的了局。这一事情负荷可由SQL缓存确当前内容、SQL调优汇合（TuningSet）、Oracle9iSummaryAdvisor事情负荷或用户供应的事情负荷表（包括你已界说的SQL语句）取得。
SQLAccessAdvisor既能够经由过程命令行API利用，也能够经由过程企业办理器（EnterpriseManager）的一部分--SQLAccessAdvisor导游利用。利用该导游，在显现这些倡议之前只必要完成三个步骤。让我们来看看怎样一般命令行界面利用SQLAccessAdvisor：
起首，创立一个包括，这一调优历程一切信息的义务。然后，该义务将使用事情负荷信息来天生作为义务的一部分存储的调优倡议。因而，全部历程是完整自力的，并且同意各个义务稍有分歧，以便人们可以看到对设置举行修正后的效果。在清单14所示的示例中，是经由过程手工界说SQL语句对事情负荷举行界说的。
代码清单14
DECLAREtask_descVARCHAR2(100);task_idNUMBER;task_nameVARCHAR2(30);workload_nameVARCHAR2(30);BEGINtask_name:=Task_mag;dbms_advisor.create_task(DBMS_ADVISOR.SQLACCESS_ADVISOR,task_id,task_name,MyAdvisorTask,DBMS_ADVISOR.SQLACCESS_WAREHOUSE);dbms_advisor.set_task_parameter(Task_mag,EVALUATION_ONLY,FALSE);dbms_advisor.set_task_parameter(Task_mag,EXECUTION_TYPE,FULL);--createtheworkloadworkload_name:=Workload_mv;dbms_advisor.create_sqlwkld(workload_name,MVworkload,NULL);--nowlinkthetwotogetherdbms_advisor.add_sqlwkld_ref(task_name,workload_name);--addaSQLstatementdbms_advisor.add_sqlwkld_statement(workload_name,App,action,NULL,15,3000,423,507,60,704,3,16-FEB-2002,80,EASYDW,SELECTc.customer_id,c.town,COUNT(DISTINCT(product_id))ASdist_promo_cntFROMpurchasesps,customercWHEREps.customer_id=c.customer_idGROUPBYc.customer_id,c.town);END;/
一旦界说了事情负荷和义务，就能够天生以下所示的倡议，该倡议利用了EXECUTE_TASK并指定了所创立义务的名字--Task_mag：
executedbms_advisor.execute_task(Task_mag);
依据事情负荷的庞大性，天生倡议的工夫能够由几秒到几分钟不等。因而，只管这个历程能够交互式运转，但你大概但愿思索提交一个义务，这就是企业办理器中的导游所要完成的事情。
你能够经由过程查询表USER_ADVISOR_RECOMMENDATIONS来疾速反省是不是有关于task_name的倡议。在对本例举行此操纵时，我们会看到已提出了一个倡议。
SELECTNoofRecommendations:,COUNT(*)FROMuser_advisor_recommendationsrWHEREtask_name=Task_mag;NOOFRECOMMENDATIONS:COUNT(*)--------------------------------NoofRecommendations:1
单个倡议能够招致多个操纵。关于此示例，SQLAccessAdvisor倡议创立物化视图日记、一个CREATEMATERIALIZEDVIEW，和一个用来剖析物化视图的挪用（受版面限定，这里未给出）。
只管你能够查询各类目次视图来检察这些操纵，但检察它们的最复杂办法就是天生一个剧本，以下所示：
executedbms_advisor.create_file(dbms_advisor.get_task_script(Task_mag),ADVISOR_RESULTS,mag_example.sql);
在清单15中，你能够看到该剧本的一段摘录，显现了为我们的查询所创建的物化视图。
代码清单15
RemAccessAdvisorRemRemUsername:EASYDWRemTask:My_TaskRemExecutiondate:20/05/200314:36Rem...CREATEMATERIALIZEDVIEW"EASYDW"."MV$$_002D0000"REFRESHFASTWITHROWIDENABLEQUERYREWRITEASSELECTEASYDW.PURCHASES.PRODUCT_IDC1,EASYDW.CUSTOMER.TOWNC2,EASYDW.CUSTOMER.CUSTOMER_IDC3,COUNT(*)M1FROMEASYDW.PURCHASES,EASYDW.CUSTOMERWHEREEASYDW.CUSTOMER.CUSTOMER_ID=EASYDW.PURCHASES.CUSTOMER_IDGROUPBYEASYDW.PURCHASES.PRODUCT_ID,EASYDW.CUSTOMER.TOWN,EASYDW.CUSTOMER.CUSTOMER_ID;...
结论
经由过程利用查询改写，你能够使用几个物化视图明显改善很多查询的功能，从而削减了坚持物化视图与基本详目数据同步所必要的磁盘空间占用与革新工夫。
Memory所有数据置于内存的存储引擎，拥有极高的插入，更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在Mysql重新启动时丢失 这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。 从项目平台的选择上讲，我们关心的，应该是一款产品能不能满足任务需求，而不是网上怎么说。 是要和操作系统进行Socket通讯的场景。否则建议慎重！ 我是一个ERP初学者，对于前台运用基本熟悉，但对于后台SQLServer的运用一点也不懂，特想学习下相关资料。至少懂得一些基本的运用。希望各位能给于建议，小弟再谢过！ 始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。 对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。 而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。
页:
[1]