MYSQL教程之为何偶然 Oracle 数据库不必索引来查...

这一切听起来不错，无疑DBaaS具有很多相对于RDBMS的优势。然而MySQL学习教程，DBaaS也有其局限性，云服务中固有的局限性就是之一。当客户开始将数据放入云端时，他们会遭遇到无法控制的网络性能问题。oracle|数据|数据库|索引
当你使用SQL言语，向数据库公布一条查询语句时，ORACLE将陪伴发生一个“实行企图”，也就是该语句将经由过程何种数据搜刮计划实行，是经由过程全表扫描、仍是经由过程索引征采等别的体例。搜刮计划的选用与ORACLE的优化器互相关注。

SQL语句的实行步骤。

1语法剖析剖析语句的语法是不是切合标准，权衡语句中各表达式的意义。

2语义剖析反省语句中触及的一切数据库工具是不是存在，且用户有响应的权限。

3视图转换将触及视图的查询语句转换为响应的对基表查询语句。

4表达式转换将庞大的SQL表达式转换为较复杂的等效毗连表达式。

5选择优化器分歧的优化器一样平常发生分歧的“实行企图”

6选择毗连体例ORACLE有三种毗连体例，对多表毗连ORACLE可选择得当的毗连体例。

7选择毗连按次对多表毗连ORACLE选择哪一对表先毗连，选择这两表中哪一个表做为源数据表。

8选择数据的搜刮路径依据以上前提选择符合的数据搜刮路径，如是选用全表搜刮仍是使用索引或是其他的体例。

9运转“实行企图”

ORACLE的优化器

ORACLE有两种优化器：基于划定规矩的优化器（RBO，RuleBasedOptimizer），和基于价值的优化器（CBO，CostBasedOptimizer）。

RBO自ORACLE6版以来被接纳，有着一套严厉的利用划定规矩，只需你依照它往写SQL语句，不管数据表中的内容如何，也不会影响到你的“实行企图”，也就是说对数据不“敏感”，ORACLE公司已不再开展这类手艺了。

CBO自ORACLE7版被引进，ORACLE自7版以来接纳的很多新手艺都是基于CBO的，如星型毗连分列查询，哈希毗连查询，和并行查询等。CBO盘算各类大概“实行企图”的“价值”，即cost，从当选用cost最低的计划，作为实践运转计划。各“实行企图”的cost的盘算依据，依附于数据表中数据的统计散布，ORACLE数据库自己对该统计散布其实不分明，必要剖析表和相干的索引，才干汇集到CBO所需的数据。

一样平常而言，CBO所选择的“实行企图”都不会比RBO的“实行企图”差，并且绝对而言，CBO对程序员的请求没有RBO那末刻薄，节俭了程序员为了从多个大概的“实行企图”当选择一个最优的计划而消费的调试工夫，但在某些场所下也会存在成绩。

较典范的成绩有：偶然，标明明建有索引，但查询历程明显没有效到相干的索引，招致查询历程耗时冗长，占用资本伟大，成绩究竟出在哪儿呢？依照以下按次查找，基础上能发明缘故原由地点。

查找缘故原由的步骤

起首，我们要断定数据库运转在何种优化形式下，响应的参数是：optimizer_mode。可在svrmgrl中运转“showparameteroptimizer_mode"来检察。ORACLEV7以来缺省的设置应是"choose"，即假如对已剖析的表查询的话选择CBO，不然选择RBO。假如该参数设为“rule”，则不管表是不是剖析过，一概选用RBO，除非在语句顶用hint强迫。

其次，反省被索引的列或组合索引的首列是不是呈现在PL/SQL语句的WHERE子句中，这是“实行企图”能用到相干索引的需要前提。

第三，看接纳了哪一种范例的毗连体例。ORACLE的共有SortMergeJoin（SMJ）、HashJoin（HJ）和NestedLoopJoin（NL）。在两张表毗连，且内表的方针列上建有索引时，只要NestedLoop才干无效天时用到该索引。SMJ即便相干列上建有索引，最多只能因索引的存在，制止数据排序历程。HJ因为须做HASH运算，索引的存在对数据查询速率几近没有影响。

第四，看毗连按次是不是同意利用相干索引。假定表emp的deptno列上有索引，表dept的列deptno上无索引，WHERE语句有emp.deptno=dept.deptno前提。在做NL毗连时，emp做为表面，先被会见，因为毗连机制缘故原由，表面的数据会见体例是全表扫描，emp.deptno上的索引明显是用不上，最多在其上做索引全扫描或索引疾速全扫描。

第五，是不是用到体系数据字典表或视图。因为体系数据字典表都未被剖析过，大概招致极差的“实行企图”。可是不要私自对数据字典表做剖析，不然大概招致逝世锁，或体系功能下落。
第六，是不是存在潜伏的数据范例转换。如将字符型数据与数值型数据对照，ORACLE会主动将字符型用to_number()函数举行转换，从而招致第六种征象的产生。


第七，是不是为表和相干的索引汇集充足的统计数据。对数据常常有增、删、改的表最好按期对表和索引举行剖析，可用SQL语句“analyzetablexxxxcomputestatisticsforallindexes;"。ORACLE把握了充实反应实践的统计数据，才有大概做出准确的选择。

第八，索引列的选择性不高。我们假定典范情形，有表emp，共有一百万行数据，但个中的emp.deptno列，数据只要4种分歧的值，如10、20、30、40。固然emp数据行有良多，ORACLE缺省认定表中列的值是在一切数据行匀称散布的，也就是说每种deptno值各有25万数据行与之对应。假定SQL搜刮前提DEPTNO=10，使用deptno列上的索引举行数据搜刮效力，常常不比全表扫描的高，ORACLE天经地义对索引“置若罔闻”，以为该索引的选择性不高。但我们思索另外一种情形，假如一百万数据行实践不是在4种deptno值间均匀分派，个中有99万行对应着值10，5000行对应值20，3000行对应值30，2000行对应值40。在这类数据散布图案中对除值为10外的别的deptno值搜刮时，毫无疑问，假如索引能被使用，那末效力会凌驾良多。我们能够接纳对该索引列举行独自剖析，或用analyze语句对该列创建直方图，对该列汇集充足的统计数据，使ORACLE在搜刮选择性较高的值能用上索引。

第九，索引列值是不是可为空（NULL）。假如索引列值能够是空值，在SQL语句中那些必要前往NULL值的操纵，将不会用到索引，如COUNT（*），而是用全表扫描。这是由于索引中存储值不克不及为全空。

第十一，看是不是有效到并行查询（PQO）。并行查询将不会用到索引。如我们想要用到A表的IND_COL1索引的话，可接纳以下体例：

“SELECT/*+INDEX（AIND_COL1）*/*FROMAWHERECOL1=XXX;"

注重，正文符必需跟在SELECT以后，且正文中的“+”要紧随着正文肇端符“/*”或“--”，不然hint就被以为是一样平常正文，对PL/SQL语句的实行不发生任何影响。

一种是EXPLAINTABLE体例。用户必需起首在本人的形式（SCHEMA）下，创建PLAN_TABLE表，实行企图的每步骤都将纪录在该表中，建表SQL剧本为在${ORACLE_HOME}/rdbms/admin/下的utlxplan.sql。

翻开SQL*PLUS，输出“SETAUTOTRACEON”，然后运转待调试的SQL语句。在给出查询了局后，ORACLE将显现响应的“实行企图”，包含优化器范例、实行价值、毗连体例、毗连按次、数据搜刮路径和响应的一连读、物理读等资本价值。

假如我们不克不及断定必要跟踪的详细SQL语句，好比某个使用利用一段工夫后，呼应速率溘然变慢。我们这时候能够使用ORACLE供应的另外一个无力工具TKPROF，对使用的实行历程全程跟踪。

我们要先在体系视图V$SESSION中，可依据USERID或MACHINE，查出响应的SID和SERIAL#。

以SYS或其他有实行DBMS_SYSTEM程序包的用户毗连数据库，实行“EXECUTEDBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION（SID，SERIAL#，TRUE）；”。

然后运转使用程序，这时候在服务器端，数据库参数“USER_DUMP_DEST”唆使的目次下，会天生ora__xxxx.trc文件，个中xxxx为被跟踪使用的操纵体系历程号。

使用程序实行完成后，用命令tkprof对该文件举行剖析。命令示例：“tkproftracefileoutputfileexplain=userid/password"。在操纵体系ORACLE用户下，键进“tkprof”，会有具体的命令匡助。剖析后的输入文件outputfile中，有每条PL/SQL语句的“实行企图”、CPU占用、物理读次数、逻辑读次数、实行时长等主要信息。依据输入文件的信息，我们能够很快发明使用中哪条PL/SQL语句是成绩的关键地点。
”由于MySQL已经是一个运行了众多知名Web2.0网站的数据，包括Craigslist、Digg、Wikipedia和Google等，或许我们可以说每一个Web2.0公司实质上是一个使用MySQL数据库的公司。

总感觉自己还是不会SQL

SQLServer的异构移植功能个人感觉最好了。（如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

以前的DTS轻盈简单。但是现在的SSIS虽然功能强大了很多，但是总是让人感觉太麻烦。看看论坛中询问SSIS的贴子就知道。做的功能太强大了，往往会有很多用户不会用了

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

仓酷云

原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。