[计算机]简述数据库的优化查询.docVIP

简述数据库的优化查询规则 摘要：数据库系统作为管理信息系统的核心，各种基于数据库的联机事务处理以及联机分析处理正慢慢的转变成为计算机应用的最为重要的部分，根据以往大量的应用实例来看，在数据库的各种操作中，查询操作所占的比重最大，而在查询操作中基于SELECT语句在SQL语句中又是代价最大的语句。如果在使用中采用了优秀的查询策略，往往可以降低查询的时间，提高查询的效率，由此可见查询优化在数据库中的重要性。本文就数据库查询优化中的策略进行介绍及探索。 关键词：数据库 查询 优化 正文： 随着计算机应用的深入，计算机技术的成熟，各种应用软件的普及，应用数据也随着日常工作而迅速增长，作为数据仓库的数据库的重要性也日益显著。同时随着各个应用领域信息化程度日益提高，数据库中的数据量迅猛增长，导致数据库系统的查询性能下降。但是一个数据库应用系统的查询性能直接影响到系统的推广和应用，因此数据库系统性能和查询优化成为数据库应用领域备受关注的热点问题。 影响数据库系统性能的因素很多，包括数据库连接方式、应用系统架构、数据库设计、管理等。其中最本质又至关重要的是数据库管理系统本身的查询优化技术。在数据库系统开发中，用户业务逻辑必须转换成数据库查询语言执行，或将数据库查询语言嵌入在宿主语言程序中执行。 数据库查询是指从数据库中提取数据的一系列活动，包括：将高级数据库语言表示的查询语句翻译为能在文件系统这一物理层次上实现的表达式，为优化查询进行各种转换，生成可供执行的查询计划。对于数据库的查询要求可通过关系代数的运算(操作)表达，而在SQL语言中通过SELECT语句实现查询要求。 数据库的优化查询主要有以下几个规则： 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num=0 应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。 应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。 in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了 如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。　　 应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。 应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。 在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。 并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。 应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。 尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索