⑴ sql server 在占用服务器内存居高不下怎么办
SQL Server对服务器内存的使用策略是用多少内存就占用多少内存，只用在服务器内存不足时，才会释放一点占用的内存，所以SQL Server 服务器内存往往会占用很高。
清除SQL Server服务器内存的方法：
1、清除所有缓存
DBCC DROPCLEANBUFFERS
2、调整可使用物理内存
把最大服务器内存改成1G，确定后内存就会被强制释放，然后把最大服务器内存改成合适的值。
⑵ sql 同样一条查询脚本,在2个服务器里执行耗费的时间差很多,为什么
暂时能想到的：
一。有可能是服务器性能不一样。
二。有可能是数据库使用的数据引擎不一样，比如innodb引擎和myisam的数据处理结果是不一样的
⑶ 如何解决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 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
⑷ MSSQL数据库.MDF太大导致一查询服务器资源占用非常厉害，如何是好
有多少条记录？
如果mssql不行，可以用oracle
我不知道你的mssql有没有打补丁，如果中了sql蠕虫机器也会变慢的。
⑸ 大家有没有做过,定时sqlserver把sql查询出来的结果保存在服务器的一个文件夹下,用csv方式.
在sql管理器中，打开sqlserver代理，选择作业，--》新增作业。根据步骤，输入导出文件的语句，设置执行排程。启用就可以了
导出文件语句参考：http://wenku..com/link?url=I0tuXfQUM55qA2_RmY-DOGXrx21UgpXf2b7D_
⑹ sql数据库服务器，内存占用过大怎么办
SqlServer系统内存管理在没有配置内存最大值，很多时候我们会发现运行SqlServer的系统内存往往居高不下。这是由于他对于内存使用的策略是有多少闲置的内存就占用多少，直到内存使用虑达到系统峰值时（预留内存根据系统默认预留使用为准，至少4M），才会清除一些缓存释放少量的内存为新的缓存腾出空间。
这些内存一般都是SqlServer运行时候用作缓存的，例如你运行一个select语句，执行个存储过程，调用函数；
1.数据缓存：执行个查询语句，SqlServer会将相关的数据页（SqlServer操作的数据都是以页为单位的）加载到内存中来，下一次如果再次请求此页的数据的时候，就无需读取磁盘了，大大提高了速度。
2.执行命令缓存：在执行存储过程，自定函数时，SqlServer需要先二进制编译再运行，编译后的结果也会缓存起来，再次调用时就无需再次编译。
在我们执行完相应的查询语句，或存储过程，如果我们不在需要这些缓存，我可以将它清除，DBCC管理命令缓存清除如下：
--清除存储过程缓存
DBCCFREEPROCCACHE
--注：方便记住关键字FREEPROCCACHE可以拆解成FREE(割舍，清除)PROC（存储过程关键字简写），CACHE（缓存）
--清除会话缓存
DBCCFREESESSIONCACHE
--注：FREE(割舍，清除)SESSION（会话）CACHE（缓存）
--清除系统缓存
DBCCFREESYSTEMCACHE('All')
--注：FREESYSTEMCACHE
--清除所有缓存
DBCCDROPCLEANBUFFERS
--注：DROPCLEANBUFFERS
⑺ SQL数据库容量大，查询速度慢，有何解决方案
首先应该确定是谁慢的，往往是程序处理方面的问题而不是数据库的问题。
程序方面应该尽可能的减少数据查询返回的内容，比如可以查询返回ID，然后再根据ID一条一条的查询具体内容，看似慢了，在数据量达的时候快很多
对于数据可以参照下面几点
1、优化SQL语句，SQL语句对查询速度影响最大
2、对于经常查询的字段作索引。但是这样会增加修改时的压力
4、优化SQLServer，比如给其分配固定的内存，预先分配查询内存，调整CPU使用率等。
5、优化硬件资源，比如使用更高的服务器或者硬盘，独立安排数据库的数据文件和索引文件，将数据文件分布于不同的物理硬盘上等等
6、考虑使用分布数据库或者对大表进行拆分
另外，2G的数据库应该不算很大了，我处理过18G的数据库，8000万条记录，查询速度可以被接受
⑻ 服务器负载量过大，怎样处理
一，确认服务器硬件是否足够支持当前的流量。
二，优化数据库访问。
服务器的负载过大，一个重要的原因是CPU负荷过大，降低服务器CPU的负荷，才能够有效打破瓶颈。而使用静态页面可以使得CPU的负荷最小化。前台实现完全的静态化当然最好，可以完全不用访问数据库，不过对于频繁更新的网站，静态化往往不能满足某些功能。
缓存技术就是另一个解决方案，就是将动态数据存储到缓存文件中，动态网页直接调用这些文件，而不必再访问数据库，WordPress和Z-Blog都大量使用这种缓存技术。
如果确实无法避免对数据库的访问，那么可以尝试优化数据库的查询SQL.避免使用Select *from这样的语句，每次查询只返回自己需要的结果，避免短时间内的大量SQL查询。
三，禁止外部的盗链。
外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗链，Apache自己就可以通过配置来禁止盗链，IIS也有一些第三方的ISAPI可以实现同样的功能。当然，伪造refer也可以通过代码来实现盗链，不过目前蓄意伪造refer盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。
四，控制大文件的下载。
大文件的下载会占用很大的流量，并且对于非SCSI硬盘来说，大量文件下载会消耗CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大文件下载，如果需要提供，建议将大文件放在另外一台服务器上。
⑼ sql如何查询一段时间内每个周期里面数值最大的数据
10秒计算公式如下
select
sysdate,sysdate+
10/24/60/60
from
al；
select
*
from
table_name
where
字段>=sysdate
and
字段
<=
sysdate+
10/24/60/60
;
如果要进行10秒为周期查询一次数据，数据需要写入到临时表，数据库会专压力很大
需要做个定时运
属行
就可以了