当前位置:首页 » 编程语言 » sql语句执行效率
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

sql语句执行效率

发布时间: 2022-04-12 03:28:49

‘壹’ 如何提高sql语句执行效率

调整不良SQL通常可以从以下几点切入:
? 检查不良的SQL,考虑其写法是否还有可优化内容
? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写
? 检查优化索引的使用
? 考虑数据库的优化器

2. 避免出现SELECT * FROM table 语句,要明确查出的字段。

3. 在一个SQL语句中,如果一个where条件过滤的数据库记录越多,定位越准确,则该where条件越应该前移。

4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引,这样查询时只进行索引扫描,不读取数据块。

5. 在判断有无符合条件的记录时建议不要用SELECT COUNT (*)和select top 1 语句。

6. 使用内层限定原则,在拼写SQL语句时,将查询条件分解、分类,并尽量在SQL语句的最里层进行限定,以减少数据的处理量。

7. 应绝对避免在order by子句中使用表达式。

‘贰’ 如何查看sql执行效率

在点击某个按钮,执行完后,再执行下面语句,就可以知道系统运行什么Sql和多少次了,其主要慢语句是那些了;
--先清除sql
server的缓存dbcc
freeProcCache
SELECT
creation_time
N'语句编译时间'
,last_execution_time
N'上次执行时间'
,total_physical_reads
N'物理读取总次数'
,total_logical_reads/execution_count
N'每次逻辑读次数'
,total_logical_reads
N'逻辑读取总次数'
,total_logical_writes
N'逻辑写入总次数'
,execution_count
N'执行次数'
,total_worker_time/1000
N'所用的CPU总时间ms'
,total_elapsed_time/1000
N'总花费时间ms'
,(total_elapsed_time
/
execution_count)/1000
N'平均时间ms'
,SUBSTRING(st.text,
(qs.statement_start_offset/2)
+
1,
((CASE
statement_end_offset
WHEN
-1
THEN
DATALENGTH(st.text)
ELSE
qs.statement_end_offset
END
-
qs.statement_start_offset)/2)
+
1)
N'执行语句'FROM
sys.dm_exec_query_stats
AS
qsCROSS
APPLY
sys.dm_exec_sql_text(qs.sql_handle)
stwhere
SUBSTRING(st.text,
(qs.statement_start_offset/2)
+
1,
((CASE
statement_end_offset
WHEN
-1
THEN
DATALENGTH(st.text)
ELSE
qs.statement_end_offset
END
-
qs.statement_start_offset)/2)
+
1)
not
like
'%fetch%'ORDER
BY
total_elapsed_time
/
execution_count
DESC;

‘叁’ SQL语句效率优化

1. SQL优化的原则是:将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。

调整不良SQL通常可以从以下几点切入:

? 检查不良的SQL,考虑其写法是否还有可优化内容

? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写

? 检查优化索引的使用

? 考虑数据库的优化器

2. 避免出现SELECT * FROM table 语句,要明确查出的字段。

3. 在一个SQL语句中,如果一个where条件过滤的数据库记录越多,定位越准确,则该where条件越应该前移。

4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引,这样查询时只进行索引扫描,不读取数据块。

5. 在判断有无符合条件的记录时建议不要用SELECT COUNT (*)和select top 1 语句。

6. 使用内层限定原则,在拼写SQL语句时,将查询条件分解、分类,并尽量在SQL语句的最里层进行限定,以减少数据的处理量。

7. 应绝对避免在order by子句中使用表达式。

8. 如果需要从关联表读数据,关联的表一般不要超过7个。

9. 小心使用 IN 和 OR,需要注意In集合中的数据量。建议集合中的数据不超过200个。

10. <> 用 < 、 > 代替,>用>=代替,<用<=代替,这样可以有效的利用索引。

11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。

12. 对于复合索引要注意,例如在建立复合索引时列的顺序是F1,F2,F3,则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致,且必须包含第一列。只能是F1或F1,F2或F1,F2,F3。否则不会用到该索引。

13. 多表关联查询时,写法必须遵循以下原则,这样做有利于建立索引,提高查询效率。格式如下select sum(table1.je) from table1 table1, table2 table2, table3 table3 where (table1的等值条件(=)) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。

注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。

14. 子查询问题。对于能用连接方式或者视图方式实现的功能,不要用子查询。例如:select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替:select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。

15. 在WHERE 子句中,避免对列的四则运算,特别是where 条件的左边,严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。

16. 如果在语句中有not in(in)操作,应考虑用not exists(exists)来重写,最好的办法是使用外连接实现。

17. 对一个业务过程的处理,应该使事物的开始与结束之间的时间间隔越短越好,原则上做到数据库的读操作在前面完成,数据库写操作在后面完成,避免交叉。

18. 请小心不要对过多的列使用列函数和order by,group by等,谨慎使用disti软件开发t。

19. 用union all 代替 union,数据库执行union操作,首先先分别执行union两端的查询,将其放在临时表中,然后在对其进行排序,过滤重复的记录。

当已知的业务逻辑决定query A和query B中不会有重复记录时,应该用union all代替union,以提高查询效率。

数据更新的效率

1. 在一个事物中,对同一个表的多个insert语句应该集中在一起执行。

2. 在一个业务过程中,尽量的使insert,update,delete语句在业务结束前执行,以减少死锁的可能性。

数据库物理规划的效率

为了避免I/O的冲突,我们在设计数据库物理规划时应该遵循几条基本的原则(以ORACLE举例):

?? table和index分离:table和index应该分别放在不同的tablespace中。

?? Rollback Segment的分离:Rollback Segment应该放在独立的Tablespace中。

?? System Tablespace的分离:System Tablespace中不允许放置任何用户的object。(mssql中primary filegroup中不允许放置任何用户的object)

?? Temp Tablesace的分离:建立单独的Temp Tablespace,并为每个user指定default Temp Tablespace

??避免碎片:但segment中出现大量的碎片时,会导致读数据时需要访问的block数量的增加。对经常发生DML操作的segemeng来说,碎片是不能完全避免的。所以,我们应该将经常做DML操作的表和很少发生变化的表分离在不同的Tablespace中。

当我们遵循了以上原则后,仍然发现有I/O冲突存在,我们可以用数据分离的方法来解决。

?? 连接Table的分离:在实际应用中经常做连接查询的Table,可以将其分离在不同的Taclespace中,以减少I/O冲突。

?? 使用分区:对数据量很大的Table和Index使用分区,放在不同的Tablespace中。

在实际的物理存储中,建议使用RAID。日志文件应放在单独的磁盘中。

‘肆’ 如何提高SQL语句的执行效率

需要提高效率,可以从以下考虑:
第一,建立搜索条件对应的索引
第二,尽量不要使用 select * ,应该改成 select 列1,列2,...
第三,升级SQL版本,SQL2008比SQL2000的速度提高是很多的
第四,如果表有大容量的字段,如 图片,文档,应该考虑用FTP来做,不是把数据放在数据库

‘伍’ mysql查看sql执行效率

Explain命令在解决数据库性能上是第一推荐使用命令,大部分的性能问题可以通过此命令来简单的解决,Explain可以用来查看 SQL 语句的执行效 果,可以帮助选择更好的索引和优化查询语句,写出更好的优化语句。
Explain语法:explain select … from … [where ...]
例如:explain select * from 表名;

‘陆’ 以下哪种方法执行SQL语句最有效率

优化sql语句执行效率的方法:
1)尽量选择较小的列
2)将where中用的比较频繁的字段建立索引
3)select子句中避免使用‘*’
4)避免在索引列上使用计算、not in 和<>等操作
5)当只需要一行数据的时候使用limit 1
6)保证单表数据不超过200W,适时分割表。
针对查询较慢的语句,可以使用explain 来分析该语句具体的执行情况。

‘柒’ sql语言的执行效率

使用explain命令,写在执行的sql前面,即可查看执行过程,看看索引使用情况

‘捌’ 如何提高sql语句的执行效率

1、使用ordered提示

Oracle必须花费大量的时间来剖析多表的合并,用以确定表合并的最佳顺序。SQL表达式涉及七个乃至更多的表合并,那么有时就会需要超过30分钟的时间来剖析,Ordered这个提示(hint)和其他的提示一起使用能够产生合适的合并顺序。

2、使用ordered_predicates

ordered_predicates提示在查询的WHERE子句里指定的,并被用来指定布尔判断(Booleanpredicate)被评估的顺序。在没有ordered_predicates的情况下,Oracle会使用下面这些步骤来评估SQL判断的顺序:子查询的评估先于外层WHERE子句里的Boolean条件。

所有没有内置函数或者子查询的布尔条件都按照其在WHERE子句里相反的顺序进行评估,即最后一条判断最先被评估。每个判断都带有内置函数的布尔判断都依据其预计的评估值按递增排列。

3、限制表格合并评估的数量

提高SQL剖析性能的最后一种方法是强制取代Oracle的一个参数,这个参数控制着在评估一个查询的时候,基于消耗的优化器所评估的可能合并数量。

(8)sql语句执行效率扩展阅读:

1、表设计的优化,数据行的长度不要超过8020字节,如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片,降低查询效率。

2、语句的查询优化,保证在实现功能的基础上,尽量减少对数据库的访问次数;

3、建立高效的索引创建索引一般有以下两个目的:维护被索引列的唯一性和提供快速访问表中数据的策略。

大型数据库有两种索引即簇索引和非簇索引,一个没有簇索引的表是按堆结构存储数据,所有的数据均添加在表的尾部,而建立了簇索引的表,其数据在物理上会按照簇索引键的顺序存储。个表只允许有一个簇索引。

4、强制查询转换,有时候oracle 的优化器未必能走正确的查询路线,这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了,这个未必是最好的处理方案。因为虽然现在走这个路线是对的,以为因为数据的变化到这这个HINT 变得不可取。

‘玖’ sql查询语句效率提问 对小弟来说非常高深!!!

答案是
:
效率是不同的
From
后面的表:效率最高(记录少,有索引)的表在最后,效率低的表在最左(记录多,无索引)
From
一般都是逆序,比如你的sql语言,数据库会先处理你的table_2
Where
后面的条件:从左到右的顺序,将效率高的比较放在前面(可以过滤更多的数据,从而减少后面条件的处理)
Where
条件一般都是顺序。表连接条件执行效率是比较高的,应该放在前面
所以你的两句sql语言,前者的效率更高。
并且可以改变table_1和Table2的位置让你的效率更高

‘拾’ SQL语句 怎样提高select语句的执行效率

需要提高效率,可以从以下考虑:
第一,建立搜索条件对应的索引
第二,尽量不要使用
select
*
,应该改成
select
列1,列2,...
第三,升级SQL版本,SQL2008比SQL2000的速度提高是很多的
第四,如果表有大容量的字段,如
图片,文档,应该考虑用FTP来做,不是把数据放在数据库