session的 阻塞会引起 CPU负荷很高 吗？

[samyp1234]

看到数据库里，CPU负荷很高，达到了95%以上；
发现多个sessin，都是如下的语句 （向同一个表里，插入数据，语句都一样）
insert into t1(a1,a2) values( @P1 , @P2 ) ;
该t1表上有主键、而且多个索引；

发现这些多个同时并发的sesison，其中一个session，阻塞了其他多个session；
也就是，多个同时插入t1表的语句，语句一样，其中一个session的执行，阻塞了其他session的执行；

说明：这个session执行时间很短，虽然有阻塞，但是很快阻塞就结束了；但是新的类似的阻塞产生了；这样循环下去；

能否大家帮助分析一下，什么原因呢？

[OwenZeng_DBA]

1.你检查阻塞和被阻塞的语句是不是足够优化，包括索引和语句本身的写法 2.检查事务隔离级别是不是默认的 3.从程序逻辑入手去优化

[吉普赛的歌]

SELECT TOP 10 OBJECT_NAME(qt.objectid, qt.dbId)  AS procName,
       DB_NAME(qt.dbId)                   AS [db_name],
       qt.text                            AS SQL_Full,
       SUBSTRING(
           qt.text,
           (qs.statement_start_offset / 2) + 1,
           (
               (
                   CASE statement_end_offset
                        WHEN -1 THEN DATALENGTH(qt.text)
                        ELSE qs.statement_end_offset
                   END 
                   - qs.statement_start_offset
               ) / 2
           ) + 1
       )                                  AS SQL_Part --统计对应的部分语句
       ,
       qs.creation_time,
       qs.last_execution_time,
       qs.execution_count,
       qs.last_elapsed_time / 1000000     AS lastElapsedSeconds,
       qs.last_worker_time / 1000000      AS lastCpuSeconds,
       CAST(
           qs.total_elapsed_time / 1000000.0 / (
               CASE 
                    WHEN qs.execution_count = 0 THEN -1
                    ELSE qs.execution_count
               END
           ) AS DECIMAL(28, 2)
       )                                  AS avgDurationSeconds,
       CAST(qs.last_logical_reads AS BIGINT) * 1.0 / (1024 * 1024) * 8060 AS 
       lastLogicReadsMB,
       qs.last_logical_reads,
       qs.plan_handle
FROM   sys.dm_exec_query_stats qs
       CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS p
WHERE  qs.last_execution_time >= CONVERT(CHAR(10),GETDATE(),120)+' 08:00'	--今天8点之后的慢SQL
       AND qs.last_elapsed_time >= 3 * 1000 * 1000							--只取执行时间大于 3 秒的记录
       AND qt.[text] NOT LIKE '%Proc_DBA%'
ORDER BY
       qs.last_worker_time DESC

在服务器上执行一下， 看到底是哪个SQL引起了cpu高， 而不是盲目地猜测