A. 如何释放sql server占用的资源内存
sql server 在查询大数据量的数据时，总会占用大量的内存，并且居高不下，一不小心就会死机。
下面这个是我从网上找到的：
当你查询数据的数据量比较大时，sqlserver会把查询结果缓存在内存中，保证你下次查询同样的记录时会很快得到结果，所以内存使用量会激增。
在你完成此次查询后，sqlserver不会马上释放内存，数据会仍然放在内存中，这是sqlserver的优化策略，sqlserver会不断地占用你的系统内存，来加快sqlserver的运行速度，当你的系统中的其它服务也需要内存时，它才会自动释放部分内存。一句话，sqlserver不会让你的系统有闲置的内存，除非你设置sqlserver的最大内存使用量。这样也没什么不好，如果你的系统很大，单独给sqlserver一台机器，这样会提高它的性能。
如果你只是开发用，要想让sqlserver释放内存，重启sqlserver的服务就行了。如果不想让sqlserver占用太多内存，设置sqlserver的最大内存占用量.
B. 如何做SqlServer 数据查询优化！
一、建立索引
二、建立存储过程
三、只查询您所需要的数据，不要把所有数据都查询出来，防止数据冗余。
四、对于大量及海量数据一般还要建立分区
C. 怎样进行sql数据库的优化
1、数据库空间是个概述，在sqlserver里，使用语句 exec sp_spaceused 'TableName' 这个语句来查。
D. 如何对sqlserver进行简单的优化
SQL Server数据库查询速度慢的原因有很多，常见的有以下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是数据库设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好，没有优化
●可以通过以下方法来优化查询 :
1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要。
2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)
3、升级硬件
4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段。
E. sql server数据库查询慢怎么优化
在安装有SQLServer数据库的计算机上，我们在使用数据库的过程中，有时候会在任务管理器里发现sqlservr.exe这个进程的内存和CPU占用率较高。
接下来我们来看一下，如何解决上面这个问题，需要设置SQLServer数据库的内存配置。登录数据库，这里使用的是SQLServer2008,右键点击最上方的服务器名，在弹出的菜单中，点击【属性】
打开服务器属性窗口。默认显示的是第一项【常规】内容，点击第二项【内存】进行内存配置。
点击【内存】后，打开服务器内存选项配置界面。这里的【使用AWE分配内存】可以对内存进行扩展支持，我们要做的是更改下方的最大服务器内存。这个数值根据自己服务器内存大小来做适当设置。
5
个人建议设置本机内存的一半或稍微高一点，如机器内存为2G，那么我们这里填写1000。需要注意的是内存设置调小以后，在数据库执行较复杂SQL语句的时候，可能会比较慢，出现这种情况，我们再适当上调最大内存配置大小。
F. SQL优化问题
问题1，2，3，其实效率是一样高的，因为现在的sqlserver,oracle,都有sql语句优化分析器，语句不同的写法，到最后编译之后，其实是一样的。
4，如果对字段like，而且是%key%这样的方式，索引就不起作用了，所以加上索引也没用。
G. 如何优化Windows OS使SQL Server性能最优化
怎样查出SQLServer的性能瓶颈QLServer性能监控这套性能优化的清单将至少准科学的帮助你找出你的SQLServer任何明显的性能问题。说是这样说，SQLServer的性能调优仍然是很困难的。我试图用这套清单去找出“容易”的sqlserver性能问题，困难的留待稍后。我这样做是因为很容易将容易和困难的的性能调优问题搞混。通过列出一个“容易”的性能调优范围，就很容易的将这些问题解决，一旦解决了这些容易的问题，那么你就能集中去解决更困难的问题。使用这个SQLServer性能调优清单的一个好处是，它将不仅仅告诉你目前最容易解决的性能问题是什么，而且还帮助你正确的去解决。在某种程度上，你可以选择不同的顺序进行。换句话说，你可以故意做出特殊的决定而不是按照清单通常的顺序进行。某种意义上说你是对的，不是所有的性能调优建议都适合所有的情形。另外，你的决定是基于你的资源限制，例如没有足够的钱去买满足负荷的硬件。如果真是那样的话，你就别无选择了。还有，你的决定可能基于一些政治原因，那是你不得不作出的改变。不管怎样，你需要知道你能做什么，使用这个性能调优清单找出你能改变的范围并做出相应的改变提升你的SQLServer的性能。一般来说，你将在你的每一个SQL服务器上执行这个清单。如果遇到清单中的一些问题，这会花掉你一些时间。我建议你从目前性能问题最多的的服务器开始，然后当你有时间的时候按照自己的思路去解决其他服务器。一旦你完成了，可仍然有很多事情要去做。记住，这些只是一些容易的。一旦你完成了这些容易的，接下来你需要花时间去解决更困难问题。这个是另一篇文章要解决的问题了。怎样进行你的SQLServer性能调优呢?为了使其变得容易，我把它们分成了以下几个部分：？使用性能监视器找出硬件瓶颈？SQLServer硬件性能监控列表？操作系统性能监控列表？SQLServer2000配置性能监控列表？数据库配置设置性能监控列表？索引性能监控列表？应用程序和T-SQL性能监控列表？SQLServer数据库作业性能监控列表？使用Profiler找出低效的查询？怎样最好的实现SQLServer性能监控管理你的SQLServe性能的最好方法是首先回顾上面每一部分的内容，把它们打印出来。然后完成每一部分的内容，写下你收集到的结果。你也可以按照你喜欢的顺序进行。上面的步骤仅仅列出了我执行的顺序，因为那样通常能达到一个比较好的效果。性能监控列表计数器名称均值最小值最大值Memory:Pages/secMemory:AvailableBytesPhysicalDisk:%DisktimePhysicalDisk:Avg.DiskQueueLengthProcessor:%ProcessorTimeSystem:::UserConnections在上表输入你的结果.使用性能监视器找出SQLServer硬件瓶颈开始SQLServer性能调优的最佳地方就是从性能监视器（系统监视器）开始。通过一个24小时的周期对一些关键的计数器进行监控，你将对你SQLServer服务器的硬件瓶颈了如指掌。一般来说，使用性能监视器去创建一个一些关键的计数器的24小时周期的监控日志。当你决定创建这个日志的时候，你需要选择一个典型的24小时的周期，例如，选择一个典型的比较忙的日期，而不是周日或节假日。一旦你将这些捕获的数据形成日志后，在性能监视器的图形界面下会显示计数器的推荐值。你在上表中记下均值、最小值、峰值。做完这些后，用你的结果跟下面的分析比较。通过你的结果和下面的建议值进行比较，你将能快速的找到你的SQLServe正在经历的潜在的硬件瓶颈。
H. sql server速度慢影响因素
首先应该确定是谁慢的，往往是程序处理方面的问题而不是数据库的问题。
程序方面应该尽可能的减少数据查询返回的内容，减少IO压力，磁盘IO和网络IO是非常非常慢的。比如可以查询返回ID，然后再根据ID一条一条的查询具体内容，看似慢了，在数据量大的时候快很多
对于数据可以参照下面几点
1、优化SQL语句，SQL语句对查询速度影响最大的
2、对于经常查询的字段作索引。但是这样会增加修改时的压力
4、优化SQLServer，比如给其分配固定的内存，预先分配查询内存，调整CPU使用率等。SQL Server 可以占用几乎所有Windows的内存，但是申请内存开销很大。因此可以设定其使用固定大小内存，比如启动就分配1G以上内存。
5、优化硬件资源，比如使用更高的服务器或者硬盘，独立安排数据库的数据文件和索引文件，将数据文件分布于不同的物理硬盘上等等
6、考虑使用分布数据库或者对大表进行拆分
I. 求优化sqlserver语句，使它查询效率提高。（要求：分组查询每组最新的一条数据，数据量非常大，几十万）
关于题主的SQL语句提高效率的问题，请留意一下几点
1) 输出的字段列表里只有来自表“dbo.tunnel_online_monitoring ”里的字段信息，没有任何来字段取自表“dbo.Threshold_ElectronicPool”，而且语句也没为这两张表指定连接条件，因此将表“dbo.Threshold_ElectronicPool”引入语句中就没有任何必要，加入该表只会大大增加系统开销，而无得益，应予以剔除；
2）row_number()函数的系统开销是比较大的，能不用尽量别用它。
如果dbo.tunnel_online_monitoring.Id是唯一的,可以不使用row_number()函数，建议语句修改如下：
selectId,CreationDate,LastUpdate,tunnel_name,
SDMC,DT,DZSC1,DZSC2,DZSC3from
tunnel_online_monitoringwhereidin(
selectmax(a.id)fromdbo.tunnel_online_monitoringa,
(selecttunnel_name,max(CreationDate)asCreationDatefrom
dbo.tunnel_online_monitoringgroupbytunnel_name)b
wherea.tunnel_name=b.tunnel_nameanda.CreationDate
=b.CreationDategroupbyb.tunnel_name);
如果dbo.tunnel_online_monitoring.Id是自增ID，那么可以根据ID的大小来判定那条记录是最新的，这样就不需要比对时间字段的先后了，语句可简化如下：
selectId,CreationDate,LastUpdate,tunnel_name,
SDMC,DT,DZSC1,DZSC2,DZSC3from
tunnel_online_monitoringwhereidin(
selectmax(id)fromdbo.tunnel_online_monitoring
groupbytunnel_name);
如果dbo.tunnel_online_monitoring.Id不是唯一的，那就还是得利用回row_number()函数了。
J. 如何解决SQL查询速度太慢
1. 执行计划中明明有使用到索引，为什么执行还是这么慢？
2. 执行计划中显示扫描行数为 644，为什么 slow log 中显示 100 多万行？
a. 我们先看执行计划，选择的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。结合 sql 来看，因为有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能会更差，优化器选择这个索引避免了排序。
那为什么不选 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很简单，TASK_DATE 字段区分度太低了，走这个索引需要扫描的行数很大，而且还要进行额外的排序，优化器综合判断代价更大，所以就不选这个索引了。不过如果我们强制选择这个索引（用 force index 语法），会看到 SQL 执行速度更快少于 10s，那是因为优化器基于代价的原则并不等价于执行速度的快慢；
b. 再看执行计划中的 type:index，"index" 代表 “全索引扫描”，其实和全表扫描差不多，只是扫描的时候是按照索引次序进行而不是行，主要优点就是避免了排序，但是开销仍然非常大。
Extra:Using where 也意味着扫描完索引后还需要回表进行筛选。一般来说，得保证 type 至少达到 range 级别，最好能达到 ref。
在第 2 点中提到的“慢日志记录Rows_examined: 1161559，看起来是全表扫描”，这里更正为“全索引扫描”，扫描行数确实等于表的行数；
c. 关于执行计划中：“rows：644”，其实这个只是估算值，并不准确，我们分析慢 SQL 时判断准确的扫描行数应该以 slow log 中的 Rows_examined 为准。
4. 优化建议：添加组合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
优化过程：
TASK_DATE 字段存在索引，但是选择度很低，优化器不会走这个索引，建议后续可以删除这个索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在这个 sql 中 REL_DEVID 字段从命名上看选择度较高，通过下面 sql 来检验确实如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 组合选择度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在测试环境添加 REL_DEVID，TASK_ID 组合索引，测试 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引后执行计划：
这里还要注意一点“隐式转换”：REL_DEVID 字段数据类型为 varchar，需要在 sql 中加引号：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
执行时间从 10s+ 降到 毫秒级别：
1 row in set (0.00 sec)
结论
一个典型的 order by 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。