sql优化记录

sql优化记录

一句话：用union all 而用or！

谢谢DBA MM

--分析比较执行时间
--加锁与不加锁的区别！

--查看执行时间和cpu的占用时间
SET STATISTICS TIME ON
SELECT COUNT(1) FROM SCM..Clothes(NOLOCK)
SET STATISTICS TIME OFF

SET STATISTICS TIME ON 
SELECT COUNT(1) FROM SCM..Clothes
SET STATISTICS TIME OFF


--结果：
/*
 
(1 行受影响)

 SQL Server 执行时间:
   CPU 时间 = 94 毫秒，占用时间 = 344 毫秒。

(1 行受影响)

 SQL Server 执行时间:
   CPU 时间 = 125 毫秒，占用时间 = 133 毫秒。

*/

--查看对io的操作情况
/*
  第一次查询：
  表 'ExpressCompany'。扫描计数 1，逻辑读取 92 次，物理读取 3 次，预读 82 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
  后面的几次查询：
  表 'ExpressCompany'。扫描计数 1，逻辑读取 92 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
  
  这里我们还要确定，到底是选择
  
  分析具体的：
  扫描计数：索引扫描或者表扫描次数
  逻辑读取：数据缓存中读取的页数
  物理读取：从磁盘中读取的页数
  预读：查询过程中，从磁盘放入缓存的页数
  
  lob逻辑读取：从数据缓存中读取，image text，ntext 或大型数据的页数；
  lob物理读取：从磁盘中读取img，text，ntext，或大型数据的页数；
  lob预读：查询过程中从磁盘放入到缓存中image，text，ntext或大型数据页数；
  
  
  如果物理读取次数和预读次说比较多，可以使用索引进行优化。
  也可以使用我们slq profile 来进行简单的分析和优化滴呀
  
  
  --这些就是最基本的数据比较滴滴呀
  
*/
SET STATISTICS IO ON
SELECT COUNT(1) FROM SCM..ExpressCompany(NOLOCK)
SET STATISTICS IO OFF


/*
  关于select的基本优化滴呀
  1.尽量避免select * 的存在，使用具体的列来代表*，避免多余的列；
  2.使用where限定需要查询的数据，避免多余的数据行
  3.使用top，distinct，关键字减少重复的行
*/

/*
   慎用用我们的distinct关键字；
   distinct 在查询一个字段或者很少字段的情况下使用，会避免重复数据的出现，
   给查询带来优化效果，但是查询
   
   满足union语句的条件：
   列数相同
   对应列数的数据类型要保持兼容；
*/


 --判断数据是否存在;
 SELECT COUNT(*) FROM SCM..Storage
 GO
 SELECT TOP(1) ProductCode FROM SCM..Storage
 --很明显，第二种的效率要高一些滴呀
 --INSERT 语句的优化；
 
 CREATE TABLE #TB
 (
   ID INT,
   NAME NVARCHAR(30)
 )
 GO
 DECLARE @I INT
 DECLARE @SLQ VARCHAR(1000)
 SET @I=0
 WHILE(@I<100000)
 BEGIN
   SET @I=@I+1
   SET @SLQ='INSERT INTO #TB VALUES('+CONVERT(VARCHAR(10),@I)+',''JACK'+CONVERT(NVARCHAR(30),@I)+''')';
   EXEC(@SQL) --这样循环一次，执行一次的效率不高
 END
 --可以拼接好所有的sql语句之后，我们统一的一次执行；
 
 
 
 --优化后的额语句;



 --分析说明：insert into select批量插入，明显提升效率。所以以后尽量避免一个个循环插入。