SQL Performance Improvement Techniques(转)

原文地址:http://www.codeproject.com/Tips/1023621/SQL-Performance-Improvement-Techniques

This article provides various options to improve the performance in database.

1) Re-Write Query:

If any query is taking much time to execute then the first step is to rewrite the query. Perform thorough analysis and move towards identifying the root cause. The below are few guidelines to improve the performance of a query.

  • Avoid * in SELECT and specify the column names when dealing with JOINs on multiple tables.

  • Avoid repeated logic, unnecessary subqueries and unnecessary JOINs
  • Some cases EXIST will benefit instead of JOIN
  • Use UNION ALL instead of UNION
  • Use EXISTS instead of IN when necessary
  • Use WITH clause (Oracle) or Common Table Expressions(Sql Server)
  • Order or position of the columns in WHERE clause would play vital role to improve the performance and ensure the proper index is being used by the query.
  • In Sql server, Adopt using SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED or WITH(NOLOCK).
  • Use hints if necessary. There are table hints, query hints and plan hints.

2) Create a Highly Selective Index:

Index helps to retrieve the data fast and basically to speed up the searches/queries. The below are the few guide lines to create index.

  • When the table is large and frequent selectivity of a table is less than 10%.

  • Do not create index on low cardinality columns and also the index is not required for small tables.
  • Frequently used columns in the WHERE clause and Columns used in joins for multiple tables.
  • Order or position of a column in an index also plays a vital role. In general, you should put the column expected to be used most often first in the index.
  • Limit the number of indexes on a table. The more indexes more overhead as the indexes need to be updated on every DML operation.

3) Limit the Number of Columns and Rows:

In some cases the applications may not use all the columns and rows fetched from the database. Means pull only the required columns and required rows.

Example if query (SELECT *) is pulling more than 100 column and the application may not use those 100 column in the application. And if any application is displaying data in page wise format then better to retrieve the corresponding records of the page instead of retrieving all the records.

4) Temporary tables:

The temporary tables should be used when there is a strong reason. Basically if any long running query is used in many places in procedure/function then better we store the results of long running query in a temporary table and reuse it later. Once it is completed then delete it to free the memory and do not wait for the table to be automatically deleted when the connection is ended. Using index on the temporary tables will help when you deal with very large tables. The temporary table can be used as the alternative for the cursors.

5) Pre-Stage data:

There are some applications do large imports from database and perform selectivity based on the information stored in flat file. The data import is done for every 1000/2000 records which would result in to perform SELECT with JOINs on large tables multiple times. These JOINs would be executed multiple times i.e. the same operation is executing several times. This can be improved by loading the flat file data into a stage table and then perform SELECT with JOINs only once based on the data exist in stage table. This would significantly improve the performance.

6) Indexed/Materialized Views:

This technique is very much helpful when there is a search operation on multiple large tables and on various columns. Obviously when you perform search on multiple tables would take lot of time to complete the search operation. This can be improved by creating single indexed/materialized view which would load and consolidate the key columns data into one or two columns. Here search is performed on one/two columns of large view instead of various columns on multiple large tables. In case of materialized views an index needs to be created on the key columns explicitly to get better performance.

7) Index Optimization:

Over a period of time the data size keep on increasing and at the same time the index size is keep on increasing. The index would become more fragmented and database engine would perform unnecessary data reads. So the heavy fragmentation of an index would lead to slow down the performance. There are two options to reduce the fragmentation of the index.

  • Rebuild: Rebuild would drop the existing index and create a new index with updated data in the columns. It takes more server resources to perform the rebuild.

  • Reorganize: Reorganize is more light weight and performs the defragmentation of the index. The existing index is used to update the leaf pages. It is better to do reorganize on periodic basis instead of rebuild.

8) Index Statistics:

The creation of statistics would enable the database engine to use a highly efficient execution plan for a query. Basically index statistics maintains the distribution of the values of an index column i.e. the cardinality of different column values. This information is used by the database engine to determine execution plan that can be used for processing a query. The statistics would need regular/periodical updates as the distribution of the values changes.

9) Archive key tables:

As you are already know, the data and index size will keep on increasing day by day. When the application is functioning since many years then index optimization may not be a good choice to improve the performance as each key table might have billions of records with different indexes on those tables. It is time to archive the key tables and this solution is suitable only if the application is not using the very old records. Create a new archive table for storing the very old records with the same structure of the key table and then move all the old records into the new archive table.

Better to rebuild/reorganize the indexes on all the key tables once the old records are moved to the newly created archive table as it would free lot of memory occupied for storing indexes. This activity can performed periodically (once/twice in year) during the off hours.

Enjoy faster SQL!!

Please remember to evaluate each situation individually to see which method works best.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

时间: 2024-10-11 18:03:07

SQL Performance Improvement Techniques(转)的相关文章

PatentTips - Control register access virtualization performance improvement

BACKGROUND OF THE INVENTION A conventional virtual-machine monitor (VMM) typically runs on a computer and presents to other software the abstraction of one or more virtual machines. Each virtual machine may function as a self-contained platform, runn

实战:ORACLE SQL Performance Analyzer

通过 SPA,您能够依据各种更改类型(如初始化參数更改.优化器统计刷新和数据库升级)播放特定的SQL 或整个 SQL 负载,然后生成比較报告,帮助您评估它们的影响. 在 Oracle Database 11g 之前的版本号中,我必须捕获全部 SQL 语句,通过跟踪执行这些语句,然后得到运行计划 - 这是一项极其耗时又极易出错的任务.新版本号中,我们不须要再那样做了,我改用很easy而有效的 SQL Performance Analyzer. ---使用场景 1.数据库升级2.实施优化建议3.更改

30 分钟快快乐乐学 SQL Performance Tuning

转自:http://www.cnblogs.com/WizardWu/archive/2008/10/27/1320055.html 有些程序员在撰写数据库应用程序时,常专注于 OOP 及各种 framework 的使用,却忽略了基本的 SQL 语句及其「性能 (performance) 优化」问题.版工曾听过台湾某半导体大厂的新进程序员,所组出来的一段 PL/SQL 跑了好几分钟还跑不完:想当然尔,即使他的 AJAX 及 ooxx 框架用得再漂亮,系统性能也会让使用者无法忍受.以下是版工整理出

PLSQL_PLSQL调优健康检查脚本SQLHC(案例)(通过运行脚本输出SQL Performance的HTML报表)

2014-08-23 BaoXinjian 一.摘要 网上流传的一个用以查询单一SQL查询的效率并导出为HTML报表的脚本,功能与DBMS_PROFILER类似 通过session查询SQL_ID,只有运行脚本,导出为HTML报表 该SQL脚本下载地址:http://files.cnblogs.com/eastsea/sqlcheck.zip 二.案例 - 使用该脚本数据SQL Performance HTML报表 1. 输入需查询SQL 2. 上传脚本 3. 查询参数SQL_ID 4. 调用脚

使用showplan.sql分析sql Performance

在HelloDBA网站找到一个分析sql性能的工具-showplan,记录一下 showplan.sql下载路径:http://www.HelloDBA.com/Download/showplan.zip 使用方式就是调用该工具,传入SQL_ID作为参数. SQL> @/dmp/showplan.sql 26xj87b2f8g6u Usage: @showplan <SQL_ID> [Plan Hash Value] [Details: [+](B)inds|SQL (T)ext|(Pe

转://使用showplan.sql分析sql Performance

在HelloDBA网站找到一个分析sql性能的工具-showplan,记录一下 showplan.sql下载路径:http://www.HelloDBA.com/Download/showplan.zip 使用方式就是调用该工具,传入SQL_ID作为参数. SQL> @/dmp/showplan.sql 26xj87b2f8g6u ---showplan.sql -- ################################################################

【SQL Performance】实时SQL监控功能(Real-Time SQL Monitoring)

概述 使用条件 监视对象 查看实时SQL监控结果的方法 DBMS_SQLTUNE包的以下子程序包 动态视图 Enterprise ManagerEM 相关参数 各版本变化 实时SQL监控使用的例子 参考 概述 实时SQL监控功能(Real-Time SQL Monitoring)是Oracle11g推出的功能,通过这个功能可以实时地监视执行中的SQL性能. 使用条件 要想使用实时SQL监控功能(Real-Time SQL Monitoring),必须满足以下几个条件 ?EE版本,购买了Diagn

sql performance Kill Lock

sp_who2 active sp_lock 76 select object_name(261575970,16) select %%lockres%%,* from SessionLock(nolock)  --from reporttempdb select * from SessionData where SessionID='scaszk45rrhlqureb1pvbp45' kill 71

1.6 Performance

1.6 performance Assessing the performance  of computers can be quite challenging. The scale and intricacy of modern software systems, together with the wide range of performance improvement techniques employed by hardware designers,have made performa