‘壹’ sql Server 2005 某个表中，其中一列存储的值比较多， 第一次查询很慢，怎么解决
查询语句可以优化一下
SELECT Tem_Detail
FROM Core_Flow_Approve_InstanceFlow
WHERE Tem_Detail != '' AND Instance_ID = ''
SQL语句过滤条件是从右到左的，
有两个条件如果有一千条数据，第一条件要比较1000次（索引除外）。
第一条件滤过了900，第二条件比较就只比较100：总比较次数就是1100.
如果第一条件过滤100，第二条件比较900次，总次数就是1900了！
‘贰’ （问题解决再追加100分）sql server存储过程实现查询数据条数过大，分页查询怎么实现
按说5-8w这样数量级的数据没有问题，写入Excel是布比较耗性能，主要还是要通过优化写入Excel的代码效率上去考虑。你可以考虑利用分批查询写入的方式来避免一次写太多的数据到Excel：将你的查询结果分段，比方你的语句中能不能用时间来认为分段，每次返回部分结果。
回到你的问题，对大数据量查询的解决方案有以下两种：
（1）、将全部数据先查询到内存中，然后在内存中进行分页，这种方式对内存占用较大，必须限制一次查询的数据量。
（2）、采用存储过程在数据库中进行分页，这种方式对数据库的依赖较大，不同的数据库实现机制不通，并且查询效率不够理想。以上两种方式对用户来说都不够友好。
2．解决思路
通过在待查询的数据库表上增加一个用于查询的自增长字段，然后采用该字段进行分页查询，可以很好地解决这个问题。下面举例说明这种分页查询方案。
（1）、在待查询的表格上增加一个long型的自增长列，取名为“queryId”,mssql、sybase直接支持自增长字段，oracle可以用sequence和trigger来实现。然后在该列上加上一个索引。
添加queryId列的语句如下：
Mssql: [QUERYID] [bigint] IDENTITY (1, 1)
Sybase: QUERYID numeric(19) identity
Oracle:
CREATE SEQUENCE queryId_S
INCREMENT BY 1
START WITH 1
MAXVALUE 999999999999999 MINVALUE 1
CYCLE
CACHE 20
ORDER;
CREATE OR REPLACE TRIGGER queryId_T BEFORE INSERT
ON "test_table"
FOR EACH ROW
BEGIN
select queryId_S.nextval into :new.queryId from al;
END;
（2）、在查询第一页时，先按照大小顺序的倒序查出所有的queryId，
语句如下：select queryId from test_table where + 查询条件 +order by queryId desc 。
因为只是查询queryId字段，即使表格中的数据量很大，该查询也会很快得到结果。然后将得到的queryId保存在应用服务器的一个数组中。
（3）、用户在客户端进行翻页操作时，客户端将待查询的页号作为参数传递给应用服务器，服务器通过页号和queyId数组算出待查询的queyId最大和最小值，然后进行查询。
算出queyId最大和最小值的算法如下,其中page为待查询的页号，pageSize为每页的大小，queryIds为第二步生成的queryId数组：
int startRow = (page - 1) * pageSize
int endRow = page * pageSize - 1;
if (endRow >=queryIds.length)
{
endRow = this.queryIds.length - 1;
}
long startId =queryIds[startRow];
long endId =queryIds[endRow];
查询语句如下：
String sql = "select * from test_table" + 查询条件 + "(queryId <= " + startId + " and queryId >= " + endId + ")";
3．效果评价
该分页查询方法对所有数据库都适用，对应用服务器、数据库服务器、查询客户端的cpu和内存占用都较低，查询速度较快，是一个较为理想的分页查询实现方案。经过测试，查询4百万条数据，可以在3分钟内显示出首页数据，以后每一次翻页操作基本在2秒以内。内存和cpu占用无明显增长。
以上也仅仅是分页查询结果查看的问题，你需要写入到Excel的话还需要考虑Excel写入代码的执行效率，这部分是很值得研究的。
‘叁’ SQL SERVER一个数据库中使用大量的存储过程，会影响性能吗
一、在SQL Server中存储过程不会影响性能。x0dx0a1、只会大大的减轻服务器的压力，而不会增加，只有不合理的存储过程才会槐辩纳造成服务器性能下降的恶果。一个大型的数据库，一般存储过程也不会超过几千个，对当前的数据库及它依附的硬件来说，这点儿负载是大象身上的老鼠，负载基本可以_略不计。x0dx0a2、但是，存储过程是批量的SQL语句的合成，如果设计上混乱，引发死循环、死锁、大范围查询、临时表没有及时清理释放等问题的情况下，是会严重影响服务器性能的，但这根子不在存储过程上，而在于存储过程的设计上。错误的SQL代码指挥服务器，无论它的形式是存储过程，还是客户端及时发向数据库的请求，都会使服务器出现问题。x0dx0ax0dx0a二、相关扩展x0dx0a1、在当前，针对数据库的编程设计，没有存储过程是不可想象的，这就象某个公司的大型货品仓库中没有仓库保管员一样，所有的货品进出都得进货员或销售员去临时取放，会严重降低工作效率。x0dx0a2、存储过程在数据库中无论是否编译好，其效率都要比客户端临时向数据库发送指令调数据来得要高，因为至少减少了发向服务器的指令的量。况且很多的中间值、临时值如果不通过存储过程来实现的话，就只能先全取到客户端铅没，这样会大大增加网络负担与服务器的负钽。x0dx0a3、正如微软所说，存储过程来实现，可以使得很多中间量不必传入到客户上，客户端只能得到需要的结果，所以同灶历时可以提高安全。