.Net+SQL Server企业应用性能优化笔记3——SQL查询语句

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
简介:

在上一篇文章中我们使用了几种方法来确定瓶颈,找到瓶颈,下面再回顾一下:

  • LoadRunner压力测试+Windows计数器,这种方法主要是找出大概的性能问题是在哪台服务器,主要是哪个资源紧张。
  • ANTS Profiler+SQL Server Profiler,这两个工具的完美搭配可以准确的定位性能是出在哪个函数,哪个SQL语句上。

如果性能问题是出在程序上,那么就要根据业务对程序中的函数进行调整,可能是函数中的写法有问题,算法有问题,这种调整如果不能解决问题的话,那么就要从架构上进行考虑,我们是不是应该使用这种技术,有没有替代的方案来实现同样的业务功能?举个简单的例子,假设经过跟踪发现,一个负责生成图表的函数存在性能问题,尤其是在压力测试情况下性能问题尤为严重。原来的图表生成是完全基于GDI+在Web服务器上根据数据进行复杂的绘图,然后将绘出的图片保存在磁盘上,然后在HTML中添加Img标签来引用图片的地址。现在使用GDI+会消耗大量内存和CPU,而算法上也没有太大的问题,那么这种情况下我们就需要考虑修改架构,不使用GDI+ 绘图的方式,或者是使用异步绘图的方式。既然绘图会消耗大量的服务器资源,那么一种解决办法就是将绘图的操作从服务器转移到客户端。使用SilverLight技术,在用户打开网页是只是下载了一个SilverLight文件,该文件负责调用Web服务器的Web服务,将绘图所需的数据获取下来,然后在客户端绘图展现出来。这样服务器只提供WebService的数据访问接口,不需要做绘图操作。

.net上的优化我暂时不表,今天主要讲数据库的优化。使用ANTS Profiler+SQL Server Profiler我们可以精确定位某个业务操作对应的数据库脚本或者存储过程。ANTS Profiler告诉我们一个方法在调用的时候花了10秒的时间,那么我们就可以使用VS打开源代码,找到该放入,然后找到对应调用的存储过程,这里也许一个方法里面调用了多个数据层方法,调用了多个存储过程。将调用的这些存储过程记下了,然后在SQL Server Provider的跟踪文件里面去找调用该存储过程花费的Duration。

ANTS Provider跟踪出调用该方法的时间-SUM(所有调用的存储过程的Duration)=C#中进行逻辑处理的时间+Web服务器和数据库服务器之间网络传输数据的时间

一般企业应用或小型应用中数据库服务器和Web服务器要不是就在同一个机房,同一个局域网,或者干脆是同一台机器,这种情况下网络传输速度是很快的,所以我们不考虑网络传送上面的时间。那么就得出:

C#中进行逻辑处理的时间=ANTS Provider跟踪出调用该方法的时间-SUM(所有调用的存储过程的Duration)

代码中的时间得到了,SQL Server中的时间(也就是Duration字段)得到了,那么就可以判断出打开该页面各个服务器所花费的时间,从而找到我们要优化的方向,是存储过程还是C#代码。如果是存储过程,那么通过查询SQL Server Profiler中内容可以找到具体是哪一个存储过程消耗的时间最长。

“射人先射马,擒贼先擒王。”多个存储过程被调用,如果性能出在数据库服务器上,那么进行性能优化时首先要调优的是最大Duration最大的存储过程,另外还有就是Reads很大的存储过程。如果Duration很大但是Reads和Writes都不算特别大,那么有可能是以下原因:

  1. 这个存储过程相关的资源正在被其他事务占用,也就是说该存储过程被阻塞所以才花了那么多时间。这种情况只需要把该存储过程提出,多执行几次,看是不是仍然Duration很大但Reads不大。
  2. 存储过程本身很复杂,里面的T-SQL语句就是五六百行,编译出的执行计划也是一堆,里面进行了大量的逻辑判断、大量函数的调用,这种情况下进行调优就比较痛苦了。实际上这次我调优的这个项目就是如此,抓取出来的存储过程尽是复杂的逻辑,少则两三百行代码,多则五六百行,里面还有大量的用户定义函数的调用。对于这种存储过程,我接下来会专门写篇博客介绍下我们这个项目是如何调优的。
  3. 程序读取的数据不多,但是需要对数据进行大量的运算。哈希联接、聚合函数、DISTINCT、UNION等都是比较耗CPU的。如果是这种情况那就看能不能建立索引或者改写法进行调优。

前面说的是Duration大而Reads小的情况,当然更常见的情况是Duration和Reads都很大。那么我们就将主要精力集中在如何减小Reads上。造成Reads很多的原因大概有以下几种:

  1. 没有建立相应的索引。对表t1进行查询,条件是where c2='abc'返回c1,c2,c3三个字段,那么这种情况下如果没有对c2建立非聚集索引(c1是主键,建立了聚集索引),那么这个查询将会进行“聚集索引扫描”,本来可能只查出几条记录的,结果要把表的所有记录都扫描一篇,自然Reads就高了。解决办法就是建立相应的索引,比如这里只需要对c2字段建立非聚集索引,然后将c3字段作为包行列就行了。如果只是最c2字段建立非聚集索引,那么前面说到的查找在进行了“非聚集索引查找”后还会进行“键查找”来找到c3列的值,所以要建立的正确的索引才行。
  2. 不符合SARG原则。查询如果不符合SARG原则,那么即使建立了索引也没法使用。SARG就是查询参数的意思,具体怎么写才符合SARG,大家可以百度,已经有很多相关文章了,我就不累述。
  3. 涉及的业务数据量大。也就是说即使建立了正确的索引,查询也符合SARG使用到了该索引,但是由于涉及的数据量太大了,所以Reads仍然很大。这种情况就不能再从索引和查询入手,而只能从数据库的设计入手。是否能够增加适当的冗余字段,对数据库进行反范式化,或者如果数据的实时性要求不高的话则可以建立中间汇总表,使用SQL作业来维护这个中间汇总表,查询的时候只查询该中间汇总表即可。或者是否可以建立索引视图或者计算列,然后在计算列中建立索引的方式进行一个预运算,减小实际查询时涉及的数据量。
  4. 使用了不当的视图。如果对视图的定义很复杂,涉及的表很多,在查询的时候使用了该视图,但是实际上只用到了视图中的一张或两张表,对视图的查询会造成系统根据视图定义查询其他与该查询不相关的表。所以在使用视图的时候一定要知道视图的定义,不用贪图一时的方便而随便使用视图。
  5. 不正确的使用了用户定义函数。一个存储过程中几百行代码,出于编写方便,大量的调用了一个用户定义表值函数,而该函数是进行了复杂的查询和运算才返回结果的。如果数次或者数十次的调用该用户定义表值函数,那么就会进行很多这种复杂的查询和运算,自然Reads也就很大了。解决办法是尽量减少对这种复制函数的调用,比如一次调用后就将解决保存在表变量或临时表中,接下来再使用的话就使用该表变量或临时表即可。

如果Duration并不大,但是Reads却很大的查询仍然需要需要进行优化。虽然表现出来消耗的时间并不大,但是由于Reads很多,那么说明要进行大量的IO,在高并发的情况下大量的IO处理不过来会加重磁盘的负担,造成CPU占用率上升,性能降低,这时其Duration就会变大。关于Duration不大但是Reads很大的情况仍然是前面说到的几点情况,建立相关索引、修改查询语句等便可解决。

相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情: https://www.aliyun.com/product/rds/sqlserver
目录
相关文章
|
2天前
|
SQL 数据采集 监控
14个Flink SQL性能优化实践分享
本文档详细列举了Apache Flink SQL的性能调优策略。主要关注点包括:增加数据源读取并行度、优化状态管理(如使用RocksDB状态后端并设置清理策略)、调整窗口操作以减少延迟、避免类型转换和不合理的JOIN操作、使用广播JOIN、注意SQL查询复杂度、控制并发度和资源调度、自定义源码实现、执行计划分析、异常检测与恢复、监控报警、数据预处理与清洗、利用高级特性(如容器化部署和UDF)以及数据压缩与序列化。此外,文档还强调了任务并行化、网络传输优化、系统配置调优、数据倾斜处理和任务调度策略。通过这些方法,可以有效解决性能问题,提升Flink SQL的运行效率。
|
6天前
|
SQL 关系型数据库 数据库
阿里云数据库 RDS SQL Server版实战【性能优化实践、优点探析】
本文探讨了Amazon RDS SQL Server版在云数据库中的优势,包括高可用性、可扩展性、管理便捷、安全性和成本效益。通过多可用区部署和自动备份,RDS确保数据安全和持久性,并支持自动扩展以适应流量波动。可视化管理界面简化了监控和操作,而数据加密和访问控制等功能保障了安全性。此外,弹性计费模式降低了运维成本。实战应用显示,RDS SQL Server版能有效助力企业在促销高峰期稳定系统并保障数据安全。阿里云的RDS SQL Server版还提供了弹性伸缩、自动备份恢复、安全性和高可用性功能,进一步优化性能和成本控制,并与AWS生态系统无缝集成,支持多种开发语言和框架。
36 2
|
6天前
|
SQL JSON atlas
实时计算 Flink版产品使用合集之SQL Server CDC是否支持抽取SQL Server视图
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
7天前
|
SQL 资源调度 监控
Flink SQL性能优化实践
Apache Flink流处理性能优化指南:探索数据源读取并行度、状态管理、窗口操作的优化策略,包括设置默认并行度、使用RocksDB状态后端、调整窗口大小。调优方法涉及数据源分区、JOIN条件优化、使用Broadcast JOIN。注意SQL复杂度、并发控制与资源调度,如启用动态资源分配。源码层面优化自定义Source和Sink,利用执行计划分析性能瓶颈。异常检测与恢复通过启用检查点,监控任务性能。预处理数据、使用DISTINCT去重,结合UDF提高效率。选择高效序列化框架和启用数据压缩,优化网络传输和系统配置。处理数据倾斜,均衡数据分布,动态调整资源和任务优先级,以提升整体性能。
38 2
|
7天前
|
SQL 关系型数据库 MySQL
sql性能优化及实战
sql性能优化及实战
15 0
|
13天前
|
SQL 数据库
SQL数据库基础语法-查询语句
SQL数据库基础语法-查询语句
|
13天前
|
SQL 关系型数据库 MySQL
【MySQL系列笔记】常用SQL
常用SQL分为三种类型,分别为DDL,DML和DQL;这三种类型的SQL语句分别用于管理数据库结构、操作数据、以及查询数据,是数据库操作中最常用的语句类型。 在后面学习的多表联查中,SQL是分析业务后业务后能否实现的基础,以及后面如何书写动态SQL,以及完成级联查询的关键。
216 6
|
13天前
|
SQL 存储 关系型数据库
【MySQL系列笔记】SQL优化
SQL优化是通过调整数据库查询、索引、表结构和配置参数等方式,提高SQL查询性能和效率的过程。它旨在减少查询执行时间、减少系统资源消耗,从而提升数据库系统整体性能。优化方法包括索引优化、查询重写、表分区、适当选择和调整数据库引擎等。
240 3
|
13天前
|
SQL 存储 Oracle
《SQL必知必会》个人笔记
《SQL必知必会》个人笔记
18 1
|
13天前
|
SQL Java 数据库连接
Java从入门到精通:2.3.2数据库编程——了解SQL语言,编写基本查询语句
Java从入门到精通:2.3.2数据库编程——了解SQL语言,编写基本查询语句