有没有办法解决 MS SQL 2005 占用CPU100%？

[qq303781721]

一台数据库服务器，上面只运行sql server 2005

四台网页服务器，调用数据库服务器的数据，程序是ASP

现在在白天上班时间 数据库服务器 sql server 占用 CPU100%

检查过病毒、攻击、ASP代码、用sql server 自带的优化顾问优化过，都没有明显变化。

请高手帮忙！

[dawugui]

这个？参考一下：

CPU占用率高的九种可能 
1、防杀毒软件造成故障 
由于新版的KV、金山、瑞星都加入了对网页、插件、邮件的随机监控，无疑增大了系统负担。处理方式:基本上没有合理的处理方式，尽量使用最少的监控服务吧，者，升级你的硬件配备。 
2、驱动没有经过认证，造成CPU资源占用100% 
大量的测试版的驱动在网上泛滥，造成了难以发现的故障原因。 处理方式:尤其是显卡驱动特别要注意，建议使用微软认证的或由官方发布的驱动，并且严格核对型号、版本。 
3、病毒、木马造成 
大量的蠕虫病毒在系统内部迅速复制，造成CPU占用资源率据高不下。解决办法:用可靠的杀毒软件彻底清理系统内存和本地硬盘，并且打开系统设置软件，察看有无异常启动的程序。经常性更新升级杀毒软件和防火墙，加强防毒意识，掌握正确的防杀毒知识。 
4、控制面板—管理工具—服务—RISING REALTIME MONITOR SERVICE点鼠标右键，改为手动。 
5、开始->；运行->；msconfig->；启动，关闭不必要的启动项，重启。 
6、查看“svchost”进程。 
svchost.exe是Windows XP系统的一个核心进程。svchost.exe不单单只出现在Windows XP中，在使用NT内核的Windows系统中都会有svchost.exe的存在。一般在Windows 2000中svchost.exe进程的数目为2个，而在Windows XP中svchost.exe进程的数目就上升到了4个及4个以上。 
7、查看网络连接。主要是网卡。 
8、查看网络连接 
当安装了Windows XP的计算机做服务器的时候，收到端口 445 上的连接请求时，它将分配内存和少量地调配 CPU资源来为这些连接提供服务。当负荷过重的时候，CPU占用率可能过高，这是因为在工作项的数目和响应能力之间存在固有的权衡关系。你要确定合适的 MaxWorkItems 设置以提高系统响应能力。如果设置的值不正确，服务器的响应能力可能会受到影响，或者某个用户独占太多系统资源。 
要解决此问题，我们可以通过修改注册表来解决:在注册表编辑器中依次展开[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserver ]分支，在右侧窗口中新建一个名为“maxworkitems”的DWORD值。然后双击该值，在打开的窗口中键入下列数值并保存退出: 
9、看看是不是Windows XP使用鼠标右键引起CPU占用100% 
在资源管理器里面，当你右键点击一个目录或一个文件，你将有可能出现下面所列问题: 
任何文件的拷贝操作在那个时间将有可能停止相应 
网络连接速度将显著性的降低 
所有的流输入/输出操作例如使用Windows Media Player听音乐将有可能是音乐失真成因: 
当你在资源管理器里面右键点击一个文件或目录的时候，当快捷菜单显示的时候，CPU占用率将增加到100%，当你关闭快捷菜单的时候才返回正常水平。 

[qq303781721]

是SQL SERVER程序占用的CPU 100%，大哥你不要从网上复制呀。

[obuntu]

CPU 瓶颈
当没有额外负载，突然发生的CPU瓶颈通常由于没有查询计划，不良的配置或设计因素和不足的硬件资源所引起。在购买更快或更多处理器前，你需要首先确定CPU的最大处理能力带宽并查看是否他们都在使用中。
系统监视器一般是确定CPU资源的最好工具。你应该查看Processor:% Processor Time计数器是否偏高；该计数器值超过80%一般被认为是瓶颈。你也可以使用sys.dm_os_schedulers视图来监视是否正在运行的任务不是0。非0的值预示有任务需要等待时间切片来运行；这个数值高表明一个CPU瓶颈的征兆。你可以用下列查询列出所有的调度器并产看等待运行的任务数量。
select
    scheduler_id,
    current_tasks_count,
    runnable_tasks_count
from
    sys.dm_os_schedulers
where
    scheduler_id < 255
下列查询给你一个查看当前缓存中最耗费CPU的批或过程高级别视图。查询根据具有相同plan handle（意味着属于同一个批或过程）的语句聚合CPU的调用。如果给出的plan handle对应多个语句，你将不得不继续找到在整个CPU使用中最占用资源的查询。
select top 50
    sum(qs.total_worker_time) as total_cpu_time,
    sum(qs.execution_count) as total_execution_count,
    count(*) as  number_of_statements,
    qs.plan_handle
from
    sys.dm_exec_query_stats qs
group by qs.plan_handle
order by sum(qs.total_worker_time) desc
本节剩下的部分将讨论一些其他的在SQL Server 中CPU敏感的操作，也有有效的检查和解决这些问题的方法。
过多的编译和重编译
当批或远端过程调用(RPC)被提交到SQL Server，在开始执行前，服务器检查查询计划的有效性和正确性。如果这些检查中的一个失败时，批将被再次编译声称不同的查询计划。这种编译就是所说的重编译。当服务器确认当底层数据改变时有更优化的查询计划时，重编译确认正确性再完成编译。编译是CPU敏感的，因此过多的重编译将导致在系统中的CPU 性能问题。
在SQL Server 2000中，当SQL Server重编译一个存储过程，整个存储过程都被重编译，不仅是触发重编译的语句。SQL Server 2005引入了语句级的存储过程的重编译。当SQL Server 2005重编译存储过程，只有导致重编译的语句被编译-而不是整个存储过程。这减少了CPU的负载并减少了对例如COMPILE锁的资源争用。重编译可以有多种原因出发，例如：
•        架构变化
•        统计变化
•        延期编译
•        Set属性改变
•        临时表改变
•        存储过程创建时使用了RECOMPLIE查询提示或使用了OPTION （RECOMPILE）。
检测
你可以使用系统监视器（PerfMon）或SQL Trace(SQL Server Profiler)来检测过多的编译和重编译。
系统监视器(Perfmon)
SQL Statistics对象提供了监视重编译的计数器和发送到SQL Server实例的请求类型。你必须监视查询编译和重编译的数量以及相关联的接受的批的数量来找出是否这个编译是最耗费CPU资源。理想环境下，SQL Recompilations/sec和Batch Request/sec的比值应该很低，除非用户提交了大量的单独查询。
下列显示了关键的数据计数器。
•        SQL Server: SQL Statistics: Batch Requests/sec
•        SQL Server: SQL Statistics: SQL Compilations/sec
•        SQL Server: SQL Statistics: SQL Recompilations/sec
更多信息请看SQL Server联机丛书中的 “SQL Statistics Object”
SQL 跟踪
如果PerfMon计数器显出了很高的重编译数量，编译将在SQL Server中占用很多的CPU资源。我们将需要查看Profiler 跟踪并从中找到找到被重编译的存储过程。SQL Server Profiler跟踪给出我们重编译原因的信息。你可以使用下列事件。
SP:Recompile和SQL:StmtRecompile事件类指出了哪个存储过程和语句被重编译。当你编译一个存储过程，一个事件为这个存储过程生成，其中每条语句将被编译。然而，当存储过程重编译时，只有导致重编译的语句被重编译（在SQL Server 2000中将是整个存储过程）。下面列出了SP:Recompile事件类更多重要的数据列。特别是EventSubClass数据列决定重编译的原因。 SP:Recompile当存储过程或触发器被重编译被触发一次，但不会被独立查询引发。在SQL Server 2005中，监视SQL:StmtRecompiles也非常有用，该事件类在所有类型的重编译中都会被触发，包括批，独立查询，存储过程和触发器。如下是我们关系的事件中关键的数据列：
•        EventClass
•        EventSubClass
•        ObjectID (represents stored procedure that contains this statement)
•        SPID
•        StartTime
•        SqlHandle
•        TextData
更多信息，请见SQL Server 联机丛书中“SQL:StmtRecompile Event Class”。
如果你有保存的跟踪文件，你可以使用下列查询查看所有捕捉的重编译事件。
select
    spid,
    StartTime,
    Textdata,
    EventSubclass,
    ObjectID,
    DatabaseID,
    SQLHandle
from
    fn_trace_gettable ( 'e:\recompiletrace.trc' , 1)
where
    EventClass in(37,75,166)
事件类37是 Sp:Recompile， 75 是 CursorRecompile， 166是SQL:StmtRecompile
你可以通过SqlHandle和ObjectID列或其他列将这个查询的结果分组，也可以查看是否最多的重编译类型是存储过程或其他原因（例如SET选项改变等）。
Showplan XML For Query Compile.
Showplan XML For Query Compile事件发生于Microsoft SQL Server编译或重编译一段SQL语句时。该事件有关于语句编译或重编译的信息。信息包括查询计划和过程的对象ID。捕获这些事件是有性能开销的，因为它捕获了每次编译或重编译。如果你在系统监视其中看到很高的SQL Compilations/sec计数器值，你应该监视这个事件。通过这些信息，你可以看到那条语句被频繁的重编译。你可以使用这些信息改变这些语句的参数。这将影响重编译的数量。
DMVs.
当你使用sys.dm_exec_query_optimizer_info DMV，你可以得到SQL Server花费在优化的时间。如果获取了这个DMV的2个快照，你可以得到在给定的时间段内花费在查询优化的时间。
select *
from sys.dm_exec_query_optimizer_info

counter          occurrence           value               
---------------- -------------------- ---------------------
optimizations    81                   1.0
elapsed time     81                   6.4547820702944486E-2

特别是查看elapsed time，该时间由于优化而产生。因为优化过程的时间基本上就是用户优化操作的CPU时间（因为优化处理是CPU时间的主要部分），你可以得到一个好的度量，找到那段编译时间占用了大量的CPU时间。
其他包含有用信息的DMV有：
sys.dm_exec_query_stats.
你希望查看的数据列有 :
•        Sql_handle
•        Total worker time
•        Plan generation number
•        Statement Start Offset
更多信息请查看SQL Server 联机丛书相关主题
sys.dm_exec_query_stats.
特别是plan_generation_num预示了查询编译时的次数。下面是示例给你展示了被重编译次数最多的25个存储过程。
select *
from sys.dm_exec_query_optimizer_info

select top 25
    sql_text.text,
    sql_handle,
    plan_generation_num,
    execution_count,
    dbid,
    objectid
from
    sys.dm_exec_query_stats a
    cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
where
    plan_generation_num >1
order by plan_generation_num desc
更多信息请见Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005
解决
如果你监测到过多的编译/重编译，考虑下列选项。
•        如果重编译因为SET选项改变而发生，使用SQL Server Profiler确定哪个SET选项被改编。避免在存储过程中改变SET选项。如果改变最好在连接级别设置。确认在该连接的生存周期内不要改变SET选项。
在临时表上重编译的阀值比在普通表上的低。在临时表上的重编译时由于统计改变而引起，你可以降临时表改为使用表变量。表变量的改变不会引起重编译。这种方法的确定是查询优化器不识别表变量，因为统计不会被创建或维护表变量。这将导致没有查询计划。你可以测试不同的选项，并选择最好的方法。另外一个选项时使用KEEP PLAN查询提示。设置临时表的这个阀值与使用永久表相同。EventSubclass 列预示了在临时表上的”Statistics Changed”的操作。
•        为避免由于改变统计而产生的重编译（例如，因为数据统计导致计划不理想），特别是KEEPFIXED PLAN查询提示。根据设置的影响，重编译可以仅因为相关正确的原因（例如，当底层表结构改变导致计划不再适用），而不根据统计的变化。如果语句引用的表的架构改变时或者表是被标记为sp_recompile的存储过程，重编译将发生。
•        关闭自动更新索引统计和表或视图的统计，防止由于对象的统计改变而产生的重编译。注意，通过使用这种方法关闭”auto-stats”特性不是一个好的想法。这是因为查询优化器不再为在这些对象上的数据改变而敏感，将导致不良的查询计划。使用这种方法仅在尝试了所有其他选择之后，做为最后的手段。
•        批应该尽量使用对象全名（例如，dbo.Table1）避免重编译并避免不明确的对象。
•        为避免由于延期编译导致的重编译，不要混杂DML和DDL或从条件结构创建DDL，例如IF语句。
•        运行Database Engine Tuning Advisor(DTA)查看改变索引是否可以改善编译时间和查询的执行时间。
•        检查是否存储过程通过WITH RECOMPILE选项创建或使用了RECOMPILE查询提示。如果过程通过WITH RECOMPILE选项创建，在SQL Server 2005中，如果在过程中特殊的语句需要被重编译，我们可以利用语句级的RECOMPILE提示。这将避免在每次执行的时候对整个过程重编译，而同时允许个别语句被编译。更多有关RECOMPILE提示的信息，请查看SQL Server联机丛书。
效率低的查询计划
当为一个查询生成查询计划时，SQL Server查询优化器尝试选择一个计划为查询提供最快的响应时间。注意最快的查询时间并不意味最小的I/O开销，也不意味使用最少的CPU资源-它会在各种资源中平衡。
某些操作类型比其他操作对CPU更敏感。Hash操作和Sort操作扫描他们各自的输入数据。使用扫描向前读取（prefetch）时，在需要操作页面前，页面几乎都在缓存中。因此可以减少或消除物理I/O操作。这使这些操作的类型将不被物理I/O所限制。与之相比，嵌套循环连接有很多索引查找，如果索引查找使用很多不同的表以至于页面不适合缓存的大小，将导致生成I/O负载。
最有意义的输入优化用于评估为每中操作生成不同查询计划开销的评估，你可以在Showplan（EstimateRows和EstimateExecution属性）中看到结果。没有精确的评估，用于优化的主输入是有缺陷的。
为获取SQL Server优化器如何使用统计的详细信息，请查看 Statistics Used by the Query Optimizer in Microsoft SQL Server 2005 。该白皮书讨论了优化器如何使用统计，维护和更新统计的最佳实践，以及一些常见的查询设计问题。

检测
低效率的查询计划通常可以被检测出来。低效率的查询计划可以导致增加CPU的消耗。
查询sys.dm_exec_query_stats是确定哪个查询累计使用CPU时间最多的有效方法。
select
    highest_cpu_queries.plan_handle,
    highest_cpu_queries.total_worker_time,
    q.dbid,
    q.objectid,
    q.number,
    q.encrypted,
    q.[text]
from
    (select top 50
        qs.plan_handle,
        qs.total_worker_time
    from
        sys.dm_exec_query_stats qs
    order by qs.total_worker_time desc) as highest_cpu_queries
    cross apply sys.dm_exec_sql_text(plan_handle) as q
order by highest_cpu_queries.total_worker_time desc
还可以选择，也可以查询sys.dm_exec_cached_plans并通过使用过滤器查找可疑的类似于‘%Hash Match%’, ‘%Sort%’这样CPU敏感的各种操作。
解决
如果你监测到效率低的查询计划，考虑下列选项。
•        使用Database Engine Tuning Advisor调节查询，查看是否生成对修改索引的建议
•        检查有问题的评估。
编写的查询中使用的更有限制性的WHERE从句是否合适？无限制条件的查询是资源敏感的。
在查询中涉及的表上运行UPDATE STATISTICS，检查是否还有这种问题。
是否查询使用的构造导致优化器不能精确的评估？
考虑是否可以将查询修改为其他的方法，避免这种问题。
•        如果不能修改架构或查询，SQL Server 2005有一个新的查询计划特性，允许你将指定查询提示添加到满足某种文本的查询中。这可以用在独立查询中，也可以用在存储过程内。例如 OPTION(OPTIMIZE FOR)这样的提示允许你影响评估而忘记所有列出的潜在计划。其他的提示，类似OPTION(FORCE ORDER)或 OPITON(USE PLAN)允许你改变控制查询计划的程度。

[obuntu]

内部查询的并行
当为一个查询生成执行计划时，SQL Server优化器尝试为该查询选择最快的相应计划。如果查询的开销超过了在cost threshold for parallelism选项中指定的值，并行不会被禁用，优化器尝试生成一个可以用于并行的计划。并行查询计划使用多线程处理查询，每个线程分布在可用的 CPU上并同时利用每个CPU的时间资源。最大的并行度可以通过服务器上的max degree of parallelism选项或每个查询使用OPTION(MAXDOP)提示限制。
用于执行实际并行度（DOP）的结果——度量有多少线程将在给定的操作上并行——是知道执行时才能确定。在执行查询前，SQL Server 2005决定有多少个调度器未充分利用并为查询选择DOP来充分利用剩余的调度器。一旦一个DOP被选择了，直到完成，查询将使用这个选择的并行度来运行。并行查询的使用时CPU有一些偏高，但是它在elapsed time上的时间很短。如果没有其他瓶颈，类似于物理I/O等待，并行计划将会使用所有处理器的100%资源。
查询开始执行后，一个关键的因素（系统有多空闲）可以导致运行并行计划的改变。例如，如果查询运行在空闲时间，服务器可以选择使用并行计划并使用DOP为 4，在4个不同的处理器上产生线程。一旦这种线程开始执行，现存的连接可以提交其他需要大量CPU的查询。在这种情况，所有不同的线程将共享可用的CPU 的时间切片，导致更高的查询持续时间。
通过并行计划运行不是一定是不好的，并行可以为查询提供最快的响应时间。然而，给定查询的响应时间必须与整体的吞吐量和系统其他查询的响应进行衡量。并行查询一般最适合批处理和决策支持系统，而不适合一个事务处理环境。
检测
内部查询的并行问题可以通过下列方法检测。
系统监视器(Perfmon)
考虑SQL Server:SQL Statistics – Batch Requests/sec 计数器，并查看SQL Server联机丛书中的“SQL Statistics Object”获取更多信息。
因为在考虑使用并行计划前，查询必须评估开销超过为并行配置设置的开销阀值（默认被设置为5），服务器每秒处理的批小于运行在并行计划中的批。运行很多并行查询的服务器一般配置为较小的每秒批请求数（例如，小于100的值）。
DMVs
在运行的服务器上，你可以使用下列查询确认在给定会话中是否可以并行运行任何活动的请求。
select
    r.session_id,
    r.request_id,
    max(isnull(exec_context_id, 0)) as number_of_workers,
    r.sql_handle,
    r.statement_start_offset,
    r.statement_end_offset,
    r.plan_handle
from
    sys.dm_exec_requests r
    join sys.dm_os_tasks t on r.session_id = t.session_id
    join sys.dm_exec_sessions s on r.session_id = s.session_id
where
    s.is_user_process = 0x1
group by
    r.session_id, r.request_id,
    r.sql_handle, r.plan_handle,
    r.statement_start_offset, r.statement_end_offset
having max(isnull(exec_context_id, 0)) > 0
通过这些信息，查询的文本可以通过使用sys.dm_exec_sql_text轻松获取，而查询计划可以使用sys.dm_exec_cached_plan获取。
你也可以搜索符合运行在并行的计划。这可以通过搜索缓存的计划来查看如果关系操作符有Parrallel属性为非零的值。这些计划也许可以不运行在平行中，但是他们如果系统不忙，他们也适合这样做。
--
-- Find query plans that may run in parallel
--
select
    p.*,
    q.*,
    cp.plan_handle
from
    sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_query_plan(cp.plan_handle) p
    cross apply sys.dm_exec_sql_text(cp.plan_handle) as q
where
    cp.cacheobjtype = 'Compiled Plan' and
    p.query_plan.value('declare namespace p="http://schemas.microsoft.com/sqlserver/2004/07/showplan";
        max(//p:RelOp/@Parallel)', 'float') > 0

一般来说，查询的持续时间长于CPU时间总量，因为一些时间花费在等待资源上例如锁或物理I/O。查询使用CPU时间长于持续时间的唯一场景是当查询运行在并行计划例如多线程并发使用CPU。注意并不是所有并行查询将证明这种行为（CPU时间大于持续时间）。
select
    qs.sql_handle,
    qs.statement_start_offset,
    qs.statement_end_offset,
    q.dbid,
    q.objectid,
    q.number,
    q.encrypted,
    q.text
from
    sys.dm_exec_query_stats qs
    cross apply sys.dm_exec_sql_text(qs.plan_handle) as q
where
    qs.total_worker_time > qs.total_elapsed_time
SQL Trace
Look for the following signs of parallel queries, which could be either statements or batches that have CPU time greater than the duration.

select
    EventClass,
    TextData
from
    ::fn_trace_gettable('c:\temp\high_cpu_trace.trc', default)
where
    EventClass in (10, 12)        -- RPC:Completed, SQL:BatchCompleted
    and CPU > Duration/1000        -- CPU is in milliseconds, Duration in microseconds
Or can be Showplans (un-encoded) that have Parallelism operators in them
select
    EventClass,
    TextData
from
    ::fn_trace_gettable('c:\temp\high_cpu_trace.trc', default)
where
    TextData LIKE '%Parallelism%'

解决
任何运行在并行计划的查询被查询优化器认为是成本昂贵的，并会超过并行阀值，默认为5（粗略的是在涉及的机器上5秒执行一次）。任何通过上述方法确认的查询都是以后要调节的候选者。
•        使用Database Engine Tuning Advisor查看是否任何索引改变，改变索引视图或分区改变能减少查询的开销
•        检查实际值和评估集的重要不同因为评估集在评估查询开销中是重要因素。如果找到重要的不同：
如果auto create statistics数据库设置被禁用，确认在Showplan输出的Warnings列中没有MISSING STATS项。
尝试在关闭评估的表上运行UPDATE STATISTICS。
验证查询没有使用优化器无法精确评估的查询构造，例如多语句表值函数或CLR函数，表值或Transact-SQL变量比较（参数比较是可以的）。
•        评估是否可以使用不同的Transact-SQL语句或表达式将查询写的更有效率
拙劣游标使用
SQL Server 2005之前的SQL Server 版本仅支持在每个连接上有单个活动的操作。一个查询正在执行或有了结果等待发送到客户端时将被认为是活动的。在一些情形中，客户端应用程序也许需要从结果中读取并向SQL Server提交其他基于刚刚从结果集中读取的行的查询。这在默认的结果集中是不能实现的，因为还有其他等待的结果。一般的解决方法是改变连接属性是用服务器端游标。
当使用服务器端游标，数据库客户端软件(OLE DB提供者或ODBC驱动)显然会封装客户端请求在特殊的扩展存储过程中，例如sp_cursoropen，sp_cursorfetch等等。这提到了 API游标（而不是TSQL游标）。当用户执行查询，查询文本通过sp_cursoropen被发送到服务器，请求读取从sp_cursorfetch指示服务器进发送某些数量的行。通过控制获取行的数量，可以为ODBC驱动或OLE DB提供者缓存行。这阻止发生服务器等待客户端都区所有发送的行的情形。因此，服务器可以在这个连接上接受新的请求。
一次性打开游标并获取1行（或少量行）的应用程序能被网络延时的网络瓶颈影响，特别是在广域网（WAN）。在有快速网络并有不同用户连接时，处理很多游标请求的开销变得更重要。因为开销来自于游标位置的变化来适应在结果集上的位置改变，预请求的处理开销，类似的处理，服务器处理1个请求返回100行必处理 100不同请求相同的100行但是每次1行更有效率。
检测
你可以使用下列方法为拙劣游标使用排错。
系统监视器(Perfmon)
通过考虑SQL Server:Cursor Manager By Type – Cursor Requests/Sec计数器，你可以通过这个性能计数器知道有多少游标在系统中使用。系统还有很高的CPU利用率，因为小量的读取通常会有每秒数百个游标请求。这里没有特殊的计数器告诉你关于获取的缓存大小。
DMVs
接下来的查询可以用于测定使用API游标（不是TSQL游标）连接获取一行使用的缓存大小。它对于大的获取缓存更有效，例如100行。
select
    cur.*
from
    sys.dm_exec_connections con
    cross apply sys.dm_exec_cursors(con.session_id) as cur
where
    cur.fetch_buffer_size = 1
    and cur.properties LIKE 'API%'        -- API cursor (TSQL cursors always have fetch buffer of 1)

SQL 跟踪
使用包括RPC:Completed事件类的跟踪用于搜索sp_cursorfetch语句。第4个参数的值是通过获取返回的行数。请求返回的最大行数是被指定为与RPC:Starting事件类关联的参数。
解决
•        确定游标是完成操作的最佳方法或是否基于集合这种更有效的操作是可行的。
•        当连接到SQL Server 2005，考虑使用多活动结果集(MARS)
•        参考你使用的API文档决定如何指定游标的获取缓存大小：
ODBC - SQL_ATTR_ROW_ARRAY_SIZE
OLE DB – IRowset::GetNextRows or IRowsetLocate::GetRowsAt

[cjzm83]

看着眼熟，学习

[luoyefeng1022]

学习学习！

[bingchengwinni]

上面的粘贴的方法很正确也很全面，如果这些方法还解决不了话，就只能请专业人士优化网站，我们是正规的网站优化公司，有优秀人士研发出的优化体系，也是目前针对此类问题唯一的一家优化机构，保证优化后cpu占有率能降至百分之十左右，咨询qq1220911866

[vgmocheng]

学习！学习！