数据库的优化查询
⑴ 数据库的查询优化方法分析
尽量不要使用 or 使用or会引起全表扫描 将大大降低查询效率
alice like % &abigale& % 会使索引不起作用(针对sqlserver)
经过实践验证 charindex()并不比前面加%的like更能提高查询效率 并且charindex()会使索引失去作用（指sqlserver数据库）
字段提取要按照 需多少 提多少 的原则 避免 select * 尽量使用 select 字段 字段 字段 实践证明 每少提取一个字段 数据的提取速度就会有相应的提升 提升的速度还要看您舍弃的字段的大小来判断
order by按聚集索引列排序效率最高 一个sqlserver数据表只能建立一个聚集索引 一般默认为ID 也可以改为其它的字段
能使用exists和not exists尽量使用 避免使用in或not in
能使用表连接尽量使用 避免使用exists和not exists
SET NOCOUNT ON
正确使用UNION和UNION ALL
慎用SELECT DISTINCT
少用游标
使用表的别名(Alias)
当在SQL语句中连接多个表时 请使用表的别名并把别名前缀于每个Column上 这样可以减少解析的时间并减少那些由Column歧义引起的语法错误
尽量少使用游标
原因很简单;就是游标的算法是最原始的计算机算法(和for if等语句一样 一条条搜索来算;效率极低);
而sql语句用的是集合运算;速度则快的多;如果用索引速度则很快(用了指针)
创建索引
a 聚集索引:
聚集索引是磁盘存储和逻辑显示是一样的
mssql表的主键一般是聚集索引;主键(每一条记录唯一确定);
创建的主键自动会是聚集索引;
如有一个非常大的表(有百万行);很长时间磁盘存储上会有类似碎片(磁盘填充率效率低;一般是频繁删除造成的);
要提高它的性能的最简洁办法是:把这个表的主键去掉再保存后;然后重新设主键再保存;
(这个表就会在磁盘上重新整理排序;性能当然会提高哟)
b 非聚集索引:
非聚集索引是在外面建立小的附加表(一种树形结构;大多数是B或B+树);
读(遍历select等sql语句)表特快;但写(update;delete insert等sql语句)表性能会略微下降
针对数据量大的表建议非聚集索引不要超过 个(节省额外磁盘负担)
不要给类似 性别 列创建索引
死锁:
是指有线程在读一条记录;别的线程读这条记录就要等待;
在mssql中只要长期占那条记录的线程去掉;死锁就会解除
在mssql中锁是针对每一行记录(所以性能不错)
经常产生锁的原因有:
a 在sql语句中使用事务语句(特别是事务中当查询比较耗时)
b 在前台的应用程序的connetion冲突(未关闭)
c 多表联合查询(尤其是在打开大的数据集时)
sql语句优化
a is null not or in 不会用索引
b 避免在索引列上使用计算或函数处理(索引会大失性能) 还有 % ;有的甚至会全失索引性能
c SELECT中避免使用 * (宁可把需要字段列出来;而不要用*去把所有的字段都列出来)
d 避免相关子查询(select中套select)
e where的条件中 =＞exists＞in (指性能)
f order by group by having distinct 等语句要慎用(因为它们效率不高;它们是先把数据到临时表中再进行处理的)
g 聚集索引如有 个字段组成(tt 和tt );tt 在前面;where的条件中如只用tt 字段来判断;就会用到一半的聚集索引;
where的条件中如tt 和tt 字段都用来判断了;就会全用到聚集索引;
where的条件中如只用tt 字段来判断;就会用不到聚集索引了;
尽量不要使用TEXT数据类型
除非你使用TEXT处理一个很大的数据 否则不要使用它 因为它不易于查询 速度慢 用的不好还会浪费大量的空间
一般的 VARCHAR可以更好的处理你的数据
尽量不要使用临时表
尽量不要使用临时表 除非你必须这样做 一般使用子查询可以代替临时表 使用临时表会带来系统开销
如果前台的代码你是使用数据库连接池而临时表却自始至终都存在 SQL Server提供了一些替代方案 比如Table数据类型
尽量少使用外键和触发器
因为在mssql中这些功能的性能做得不是很好;随便动一下表(它就会到相关的表去搞判断;有很多情况并不需要);在后台消耗资源大
lishixin/Article/program/Oracle/201311/16744
⑵ 数据库查询优化
你要问什么？分页当然要用存储过程了。
菜
⑶ 怎么样操作数据库的查询优化技术
在一个关系数据库中提高和优化查询方法。很多人都将数据库看成神奇的圣人，即能够解决人们提出的各种问题。任何关系数据库都有一套解决查询的规则，而各种关系数据库查询的过程稍有所区别，但是基本的操作思想和过程是一致的。本文将为你介绍查询分析器解决查询的方法和过程。查询优化的目标在查看分析器查询的步骤之前，理解查询优化目标相当重要。显然，查询操作的其中一个目标是尽可能地减少使用资源。从数据库的角度看，这就意味着尽可能地减少I/O操作的次数。在对I/O操作的判断上，查询分析器经常做出错误的结果。而I/O操作次数必须满足磁盘的读取容量。这样从磁盘I/O读取的角度看，必须做出合理的选择条件。索引基于表格的索引是关系数据库用于解决查询的重要技术，也是数据库同时预先将数据分类导入到多表格的方式。通过索引中的字段和实际数据存放的指针可以完成以上的过程。除了集簇索引（Clustered Index），每一索引的使用都以磁盘容量作为代价。集簇索引是真正意义上与磁盘读取和磁盘容量代价无关的方法，因为集簇索引是真正按照顺序将数据存储到表格。当使用一个索引，数据库引擎必须执行两个数据读取，这两个数据读取是数据库记录所必需的。第一个数据被读取到实际数据指针的索引。第二个数据被读入到指针指定的位置。此时必须通过数据库服务器来查询，所以考虑系统资源消耗是有必要的。这也是查询分析器不使用索引的主要原因。在后面的部分中，即Covering Indices，你将学会不使用这两种读取的方法——然而，在很多时候使用索引即意味着每一记录可以完成两次读取。统计页统计页（Statistics page）是SQL Server用于决定是否使用索引时必需的信息。每一索引都有一个信息表，以将表格所有数据的索引关键值分布告诉查询优化器。统计页可用于大致估计从一个查询返回的行数。查询分析器必须知道返回的行数，由此确定是否值得使用索引方式。如果查询优化器从索引统计页中得知将返回几行，它就会选择使用索引；如果从统计页中得知将返回大数量的行数，索引查询优化器将有可能使用一个表扫描来解决查询。字段顺序当使用到索引时，字段顺序(Field order)代表众多字段的顺序。当判断是否使用索引时，服务器必须从第一字段到最后字段扫描。任何与查询无关的字段都将该索引清除掉。当进行索引安排时，你应该将最经常使用到的查询排列在索引最顶端，不属于查询范围的字段可以使查询优化器忽略整个索引。 使用WHERE语句WHERE语句是确定索引的选择语句的重要组成部分。WHERE语句过滤了显示记录的数量，也是查询优化器查找索引值的最容易的方法。WHERE语句的使用方法有很多种，以下为通常使用到的几种形式：匹配(相等)WHERE语句最为常用的例子就是一个记录或多个记录的匹配。当你指定一个特定字段等于一个值时，查询优化器将获知它要查询的索引入口，并识别满足查询条件的记录。这就大大地过滤读取记录的数量，从而减少查询所需要的时间。并且，查询分析器将可找到包含与匹配操作有关的字段索引的位置。大于或小于虽然匹配和相等是最为普通的选择方式，而WHERE语句中的查询范围要求也是经常见到的。在这种情况下，查询分析器获知大于或者小于指定值的索引范围。通常，查询分析器可从多个独立语句中确定被读取的索引百分含量，并决定是否值得使用索引技术。函数在WHERE语句中使用函数可以限制索引查询的范围。查询分析器的查询结果难于确定，尤其在执行非常量字段的时候。所以，使用WHERE语句的函数将尽可能减少查询次数。使用ORDER BY语句一旦查询分析器以WHERE语句来判断，它将以ORDER BY语句而开始查询。如果查询优化器找到正确顺序行的相应索引，并且这一索引与WHERE条件相符合，优化器将会直接使用到索引技术。为了方便使用索引，ORDER BY语句不应该包含不必要的字段。查询分析器不能识别一个字段的表面意思，而ORDER BY语句可实现按照字段来排序。由此，如果你的ORDER BY语句中包括字段，优化器将会找到包含所有这些字段的索引。在ORDER BY语句中列出每一字段将有效地阻止查询优化器使用索引。详细索引（Covering indices）以上我提到查询分析器使用索引也会带来负面，所以有时候我们将不使用索引技术，特别是对于已经确定顺序的索引。比如，如果你从一个用户记录中选择User ID,First Name,LastName以及EmailAddress，你可获得包含所有这些字段的一个索引，然后查询分析器可以直接使用索引并读取数据表。此时，使用一个双向对照表(cross reference table)将特别有用。你可以在一个方向上使用一个集簇索引，然后在相反方向建立一个带有字段的索引。这样SQL服务器的第一个方向上可以使用物理表查询，而在相反方向上使用到索引技术。由于长关键字的原因，详细索引需要额外的空间和更多的时间。然而，如果你有一个参考表，详细索引能够有助于查询分析器更好地工作。帮助查询优化器当你提交一个查询之后，查询分析器的执行都必须通过很多环节。这些环节将有助于快速地获得结果。然而，通过在查询中指定你所需要的内容和建立正确的索引，即帮助查询优化器的操作，以上过程才能顺利完成。
⑷ 超详细MySQL数据库优化
数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.
1. 优化一览图
2. 优化
笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.
2.1 软优化
2.1.1 查询语句优化
1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.
2.例:
显示:
其中会显示索引和查询数据读取数据条数等信息.
2.1.2 优化子查询
在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.
2.1.3 使用索引
索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:
2.1.4 分解表
对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,
2.1.5 中间表
对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.
2.1.6 增加冗余字段
类似于创建中间表,增加冗余也是为了减少连接查询.
2.1.7 分析表,,检查表,优化表
分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.
1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;
2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]
option 只对MyISAM有效,共五个参数值:
3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.
2.2 硬优化
2.2.1 硬件三件套
1.配置多核心和频率高的cpu,多核心可以执行多个线程.
2.配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.
3.配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.
2.2.2 优化数据库参数
优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.
2.2.3 分库分表
因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。另外一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。
2.2.4 缓存集群
如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
一个完整而复杂的高并发系统架构中，一定会包含：各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.
⑸ 数据库中查询优化的一般规律是什么
查询检索的优化首先想到你检索条件中的字段是不是索引字段，不是的话，建立索引
然后是sql语句的优化，select其实就是循环，循环的次数越多，检索效率越慢，子查询可以有，但是不要超过三层，超过三层，估计就是检索sql有问题，要重新梳理逻辑
避免笛卡尔积，几个表关联的时候，要用主键或者逻辑主键去关联
聚合函数的用法，要注意重复数据的过滤
where条件尽量写详细，条件越多，就能过滤掉更多的数据，这样就会提高效率
对于百万级别或者千万级别的数据量的检索，就不是sql优化那么简单了，要用到数据库本身的一些优化机制，有些数据库带有临时表，这是很好的优化方法
存储过程也是可以优化sql的，一些循环或者条件判断都可以用存储过程来实现
纯手打。。。。。。。。。。。。。。。。。。。。。。。。。大家可以补充
⑹ 数据库查询性能优化方式有哪些
1、1、调整数据结构的设计。这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。
2、2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。
3、3、调整数据库SQL语句。应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row-level manager）来调整优化SQL语句。
4、4、调整服务器内存分配。内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（PGA区）的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用操作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。
5、5、调整硬盘I/O，这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。
6、6、调整操作系统参数，例如：运行在UNIX操作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。
实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。
ORACLE数据库性能优化工具
常用的数据库性能优化工具有：
1、1、ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。
2、2、操作系统工具，例如UNIX操作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现在什么地方有时候很有用。
3、3、SQL语言跟踪工具（SQL TRACE FACILITY），SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文件，管理员可以使用TKPROF工具查看这些文件。
4、4、ORACLE Enterprise Manager（OEM），这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。
5、5、EXPLAIN PLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。
ORACLE数据库的系统性能评估
信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。
1、1、在线事务处理信息系统（OLTP），这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数：
l l 数据库回滚段是否足够？
l l 是否需要建立ORACLE数据库索引、聚集、散列？
l l 系统全局区（SGA）大小是否足够？
l l SQL语句是否高效？
2、2、数据仓库系统（Data Warehousing），这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数：
l l 是否采用B*-索引或者bitmap索引？
l l 是否采用并行SQL查询以提高查询效率？
l l 是否采用PL/SQL函数编写存储过程？
l l 有必要的话，需要建立并行数据库提高数据库的查询效率
SQL语句的调整原则
SQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAIN PLAN语句来比较各种实现方案，并选出最优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则：
1、1、尽量使用索引。试比较下面两条SQL语句：
语句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN
(SELECT deptno FROM emp);
语句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS
(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);
这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。
2、2、选择联合查询的联合次序。考虑下面的例子：
SELECT stuff FROM taba a, tabb b, tabc c
WHERE a.acol between :alow and :ahigh
AND b.bcol between :blow and :bhigh
AND c.ccol between :clow and :chigh
AND a.key1 = b.key1
AMD a.key2 = c.key2;
这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。
3、3、在子查询中慎重使用IN或者NOT IN语句，使用where (NOT) exists的效果要好的多。
4、4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询最好都分解为对数据表的直接查询效果要好一些。
5、5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。
6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。
CPU参数的调整
CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90％以上。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。
使用操作相同命令可以看到CPU的使用情况，一般UNIX操作系统的服务器，可以使用sar –u命令查看CPU的使用率，NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。
数据库管理员可以通过查看v$sysstat数据字典中“CPU used by this session”统计项得知ORACLE数据库使用的CPU时间，查看“OS User level CPU time”统计项得知操作系统用户态下的CPU时间，查看“OS System call CPU time”统计项得知操作系统系统态下的CPU时间，操作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占操作系统总的CPU时间90％以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。
数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。
出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。
1、数据库管理员可以执行下述语句来查看SQL语句的解析情况：
SELECT * FROM V$SYSSTAT
WHERE NAME IN
('parse time cpu', 'parse time elapsed', 'parse count (hard)');
这里parse time cpu是系统服务时间，parse time elapsed是响应时间，用户等待时间
waite time = parse time elapsed – parse time cpu
由此可以得到用户SQL语句平均解析等待时间＝waite time / parse count。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句
SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA
ORDER BY PARSE_CALLS;
来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。
2、数据库管理员还可以通过下述语句：
SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA;
查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。
3、3、数据库管理员可以通过v$system_event数据字典中的“latch free”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latch free查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。
内存参数的调整
内存参数的调整主要是指ORACLE数据库的系统全局区（SGA）的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。
1、 1、 共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句：
select (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache;
来查看共享SQL区的使用率。这个使用率应该在90％以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句：
select (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache;
查看数据字典缓冲区的使用率，这个使用率也应该在90％以上，否则需要增加共享池的大小。
2、 2、 数据缓冲区。数据库管理员可以通过下述语句：
SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');
来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。
这个命中率应该在90％以上，否则需要增加数据缓冲区的大小。
3、 3、 日志缓冲区。数据库管理员可以通过执行下述语句：
select name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率：
申请失败率＝requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。
⑺ 数据库表数据量大怎么优化查询速度
下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。
1．合理使用索引
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：
●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。
●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。
2．避免或简化排序
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
●索引中不包括一个或几个待排序的列；
●group by或order by子句中列的次序与索引的次序不一样；
●排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
3．消除对大型表行数据的顺序存取
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。
4．避免相关子查询
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
5．避免困难的正规表达式
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。
6．使用临时表加速查询
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然后以下面的方式在临时表中查询：
SELECT ＊ FROM cust_with_balance
WHERE postcode>“98000”
临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。
7．用排序来取代非顺序存取
非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。
有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。
⑻ 数据库的多表大数据查询应如何优化
1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：x0dx0aselect id from t where num is nullx0dx0a可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：x0dx0aselect id from t where num=0x0dx0a2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。x0dx0a3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：x0dx0aselect id from t where num=10 or num=20x0dx0a可以这样查询：x0dx0aselect id from t where num=10x0dx0aunion allx0dx0aselect id from t where num=20x0dx0a4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：x0dx0aselect id from t where num in(1,2,3)x0dx0a对于连续的数值，能用 between 就不要用 in 了：x0dx0aselect id from t where num between 1 and 3x0dx0a5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。 x0dx0a见如下例子： x0dx0aSELECT * FROM T1 WHERE NAME LIKE ‘%L%’ x0dx0aSELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’ x0dx0aSELECT * FROM T1 WHERE NAME LIKE ‘L%’ x0dx0a即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。x0dx0a6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：x0dx0aselect id from t where num=@numx0dx0a可以改为强制查询使用索引：x0dx0aselect id from t with(index(索引名)) where num=@numx0dx0a7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：x0dx0aSELECT * FROM T1 WHERE F1/2=100 x0dx0a应改为: x0dx0aSELECT * FROM T1 WHERE F1=100*2x0dx0aSELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’ x0dx0a应改为: x0dx0aSELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’x0dx0aSELECT member_number, first_name, last_name FROM members x0dx0aWHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21 x0dx0a应改为: x0dx0aSELECT member_number, first_name, last_name FROM members x0dx0aWHERE dateofbirth < DATEADD(yy,-21,GETDATE()) x0dx0a即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。x0dx0a8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：x0dx0aselect id from t where substring(name,1,3)='abc'--name以abc开头的idx0dx0aselect id from t where datediff(day,createdate,-11-30')=0--‘2005-11-30’生成的idx0dx0a应改为:x0dx0aselect id from t where name like 'abc%'x0dx0aselect id from t where createdate>=-11-30' and createdate<-12-1'x0dx0a9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。x0dx0a10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。x0dx0a11.很多时候用 exists是一个好的选择：x0dx0aelect num from a where num in(select num from b)x0dx0a用下面的语句替换：x0dx0aselect num from a where exists(select 1 from b where num=a.num)x0dx0aSELECT SUM(T1.C1)FROM T1 WHERE( x0dx0a(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0) x0dx0aSELECT SUM(T1.C1) FROM T1WHERE EXISTS( x0dx0aSELECT * FROM T2 WHERE T2.C2=T1.C2) x0dx0a两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。
⑼ 浅谈数据库查询优化的几种思路
应尽量避免全表扫描，首先应考虑在 where 及 order by ,group by 涉及的列上建立索引
可以帮助选择更好的索引和优化查询语句， 写出更好的优化语句。 通常我们可以对比较复杂的尤其是涉及到多表的 SELECT 语句， 把关键字 EXPLAIN 加到前面， 查看执行计划。例如： explain select * from news;
用具体的字段列表代替“*” ， 不要返回用不到的任何字段。
mysql innodb上的理解。
1，不需要的字段会增加数据传输的时间，即使mysql服务器和客户端是在同一台机器上，使用的协议还是tcp，通信也是需要额外的时间。
2，要取的字段、索引的类型，和这两个也是有关系的。举个例子，对于user表，有name和phone的联合索引，select name from user where phone= 12345678912 和 select * from user where phone= 12345678912 ，前者要比后者的速度快，因为name可以在索引上直接拿到，不再需要读取这条记录了。
3，大字段，例如很长的varchar，blob，text。准确来说，长度超过728字节的时候，会把超出的数据放到另外一个地方，因此读取这条记录会增加一次io操作。
比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
使用 procere analyse()函数对表进行分析， 该函数可以对表中列的数据类型提出优化建议。 能小就用小。 表数据类型第一个原则是： 使用能正确的表示和存储数据的最短类型。 这样可以减少对磁盘空间、 内存、 cpu 缓存的使用。
使用方法： select * from 表名 procere analyse();
通过拆分表可以提高表的访问效率。 有 2 种拆分方法
1.垂直拆分
把主键和一些列放在一个表中， 然后把主键和另外的列放在另一个表中。 如果一个表中某些列常用， 而另外一些不常用， 则可以采用垂直拆分。
2.水平拆分
根据一列或者多列数据的值把数据行放到二个独立的表中。
创建中间表， 表结构和源表结构完全相同， 转移要统计的数据到中间表， 然后在中间表上进行统计， 得出想要的结果。
选择多核和主频高的 CPU。
使用更大的内存。 将尽量多的内存分配给 MYSQL 做缓存。
4.3.1 使用磁盘阵列
RAID 0 没有数据冗余， 没有数据校验的磁盘陈列。 实现 RAID 0至少需要两块以上的硬盘， 它将两块以上的硬盘合并成一块， 数据连续地分割在每块盘上。
RAID1 是将一个两块硬盘所构成 RAID 磁盘阵列， 其容量仅等于一块硬盘的容量， 因为另一块只是当作数据“镜像”。使用 RAID-0+1 磁盘阵列。 RAID 0+1 是 RAID 0 和 RAID 1 的组合形式。 它在提供与 RAID 1 一样的数据安全保障的同时， 也提供了与 RAID 0 近似的存储性能。
4.3.2 调整磁盘调度算法
选择合适的磁盘调度算法， 可以减少磁盘的寻道时间
对 MySQL 自身的优化主要是对其配置文件 my.cnf 中的各项参数进行优化调整。 如指定 MySQL 查询缓冲区的大小， 指定 MySQL 允许的最大连接进程数等。
它的作用是存储 select 查询的文本及其相应结果。 如果随后收到一个相同的查询， 服务器会从查询缓存中直接得到查询结果。 查询缓存适用的对象是更新不频繁的表， 当表中数据更改后， 查询缓存中的相关条目就会被清空。
⑽ 分布式数据库的查询优化
指在执行分布式查询时选择查询执行计划的方法和关系运算符的实现算法。根据系统环境的不同，查询优化所使用的算法也有所不同，通常分为远程广域网环境和高速局域网环境，其区别主要在网络的带宽。对于一元运算符可以采用集中式数据库中的查询优化方法。而对于二元运算符，由于涉及场地间的数据传输，因此必须考虑通信代价。分布式查询中常见的连接运算执行策略包括：
（1）半连接方法：利用半连接运算的转换方法R∞S=（RµS）∞S。假设场地1和场地2上分别有关系R和关系S，首先在S上执行连接属性上的投影并将结果传输至场地1，在场地1上执行关系R与投影的连接操作，再将结果传输至场地2与关系S执行连接操作。这种方法能够降低执行连接运算时的网络通信代价，主要适用于带宽较低的远程广域网络。
（2）枚举法方法：指枚举关系运算符的物理执行计划，通过对比执行计划的代价选择执行算法的方法。其中，连接运算符的物理执行计划包括嵌套循环方法、哈希连接法和归并连接法。枚举法主要适用于以磁盘IO代价为主的高速局域网环境。
