个人博客网站的设计与实现,百度信息流投放,怎样学做企业网站,住房和城乡建设部网站打不开T1表 10000000万条数据,(插入时间36分钟#xff0c;count(*)查询19秒#xff0c;空间占用670M左右)sql1.真正充分的利用索引好比like 张% 就是符合SARG(符合扫描参数)标准而like %张 就不符合该标准数据库通配符%在字符串首字符的使用会致使索引没法使用#xff0c;虽然实际…T1表 10000000万条数据,(插入时间36分钟count(*)查询19秒空间占用670M左右)sql1.真正充分的利用索引好比like 张% 就是符合SARG(符合扫描参数)标准而like %张 就不符合该标准数据库通配符%在字符串首字符的使用会致使索引没法使用虽然实际应用中很难避免这样用但仍是应该对这种现象有所了解至少知道此种用法性能是很低下的。函数**********************************************sqlserver2.“非”操做符不知足SARG形式使得索引没法使用不知足SARG形式的语句最典型的状况就是包括非操做符的语句如NOT、!、、!、NOT EXISTS、NOT IN、NOT LIKE等。若是使用not 或者 ,最好转换成别的方法好比例子以下性能T1表 10000000万条数据,构建以下:(插入时间36分钟count(*)查询19秒空间占用670M左右)测试DECLARE i INTSET i 1WHILE i1000000BEGININSERT INTO t1 VALUES (zhangCONVERT(char(50), i),3.2,77);SET i 1;END优化三种查询方式编码SELECT * FROM t1 WHERE id 300000SELECT * FROM t1 WHERE id NOT IN (300000)SELECT * FROM t1 WHERE id 299999 AND id 在执行计划中能够明显看出使用最后一种方式而不是前面两种方式进行查询。网上是这么说的但本身作的试验100W条数据开销计划是同样的。server*********************************************3. 函数运算不知足SARG形式使得索引没法使用例下列SQL条件语句中的列都建有恰当的索引但执行速度却很是慢select * from record where substring(card_no,1,4)′5378′(13秒)select * from record where amount/30select * from record where convert(char(10),date,112)′19991201′(10秒)分析where子句中对列的任何操做结果都是在SQL运行时逐列计算获得的所以它不得不进行全表扫描而没有使用该列上面的索引若是这些结果在查询编译时就能获得那么就能够被SQL优化器优化使用索引避免表搜索所以将SQL重写成下面这样select * from record where card_no like ′5378%′(select * from record where amount select * from record where date ′1999/12/01′ (你会发现SQL明显快不少待测试.......**********************************************4.尽可能不要对创建了索引的字段做任何的直接处理select * from employs where first_name last_name beill cliton;没法使用索引改成select * from employee wherefirst_name substr(beill cliton,1,instr(beill cliton, )-1)andlast_name substr(beill cliton,instr(beill cliton, )1)则可使用索引***********************************************5.不一样类型的索引效能是不同的应尽量先使用效能高的好比数字类型的索引查找效率高于字符串类型定长字符串charnchar的索引效率高于变长字符串varchar,nvarchar的索引。应该将where username张三 and age20改进为where age20 and username张三注意此处SQL的查询分析优化功能能够作到自动重排条件顺序但仍是建议预先手工排列好。**************************************************6.某些状况下IN 的做用与OR 至关 且都不能充分利用索引例表stuff有200000行id_no上有非群集索引请看下面这个SQLselect count(*) from stuff where id_no in(′0′,′1′) (23秒)我 们指望它会根据每一个or子句分别查找再将结果相加这样能够利用id_no上的索引但实际上,它却采用了OR策略即先取出知足每一个or子句的 行存入临时数据库的工做表中再创建惟一索引以去掉重复行最后从这个临时表中计算结果。所以实际过程没有利用id_no 上索引而且完成时间还要 受tempdb数据库性能的影响。实践证实表的行数越多工做表的性能就越差当stuff有620000行时执行时间会很是长若是肯定不一样的条件不会产生大量重复值还不如将or子句分开select count(*) from stuff where id_no′0′select count(*) from stuff where id_no′1′获得两个结果再用union做一次加法合算。由于每句都使用了索引执行时间会比较短select count(*) from stuff where id_no′0′unionselect count(*) from stuff where id_no′1′从实践效果来看使用union在一般状况下比用or的效率要高的多而exist关键字和in关键字在用法上相似性能上也相似都会产生全表扫描效率比较低下根据未经验证的说法exist可能比in要快些。***************************************************7.使用变通的方法提升查询效率like关键字支持通配符匹配但这种匹配特别耗时。例 如select * from customer where zipcode like “21_ _ _”即便在zipcode字段上已创建了索 引在这种状况下也可能仍是采用全表扫描方式。若是把语句改 为select * from customer where zipcode “21000”在执行查询时就会利用索引大大提升速度。但 这种变通是有限制的不该引发业务意义上的损失对于邮政编码而 言zipcode like “21_ _ _” 和 zipcode “21000” 意义是彻底一致的。*********************************************************人各有志,但富贵在天人生容许彷徨,但不容许蹉跎.8.order by按汇集索引列排序效率最高排序是较耗时的操做应尽可能简化或避免对大型表进行排序如缩小排序的列的范围只在有索引的列上排序等等。咱们来看(gid是主键fariqi是聚合索引列)select top 10000 gid,fariqi,reader,title from tgongwen用时196 毫秒。 扫描计数 1逻辑读 289 次物理读 1 次预读 1527 次。select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc用时4720毫秒。 扫描计数 1逻辑读 41956 次物理读 0 次预读 1287 次。select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc用时4736毫秒。 扫描计数 1逻辑读 55350 次物理读 10 次预读 775 次。select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc用时173毫秒。 扫描计数 1逻辑读 290 次物理读 0 次预读 0 次。select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc用时156毫秒。 扫描计数 1逻辑读 289 次物理读 0 次预读 0 次。同时按照某个字段进行排序的时候不管是正序仍是倒序速度是基本至关的。********************************************************9.关于节省数据查询系统开销方面的措施(1)使用TOP尽可能减小取出的数据量(2)字段提取要按照“需多少、提多少”的原则避免“select *”字段大小越大数目越多select所耗费的资源就越多好比取int类型的字段就会比取char的快不少。咱们每少提取一个字段数据的提取速度就会有相应的提高。提高的幅度根据舍弃的字段的大小来判断(3)count(*) 与 count(字段) 方法比较用 count(*)和用 count(主键)的速度是至关的而count(*)却比其余任何除主键之外的字段汇总速度要快并且字段越长汇总速度就越 慢。若是用 count(*) SQL SERVER会自动查找最小字段来汇总。固然若是您直接写count(主键)将会来的更直接些(4)有嵌套查询时尽量在内层过滤掉数据若是一个列同时在主查询和where子句中出现极可能当主查询中的列值改变以后子查询必须从新查询一次。并且查询嵌套层次越多效率越低所以应当尽可能避免子查询。若是子查询不可避免那么要在子查询中过滤掉尽量多的行(5)多表关联查询时需注意表顺序并尽量早的过滤掉数据在使用Join进行多表关联查询时候应该使用系统开销最小的方案。链接条件要充份考虑带有索引的表、行数多的表并注意优化表顺序说的简单一点就是尽量早的将以后要作关联的数据量降下来。通常状况下sqlserver 会对表的链接做出自动优化。例如select name,no from Ajoin B on A. idB.idjoin C on C.idA.idwhere namewang尽 管A表在From中先列出而后才是B,最后才是C。但sql server可能会首先使用c表。它的选择原则是相对于该查询限制为单行或少数几行就可 以减小在其余表中查找的总数据量。绝大多数状况下sql server 会做出最优的选择但若是你发觉某个复杂的联结查询速度比预计的要慢就可使 用SET FORCEPLAN语句强制sql server按照表出现顺序使用表。如上例加 上SET FORCEPLAN ON…….SET FORCEPLAN OFF 表的执行顺序将会按照你所写的顺序执行。在查询分析器中查看2种执行效 率从而选择表的链接顺序。SET FORCEPLAN的缺点是只能在存储过程当中使用原文http://hi.baidu.com/mayw1985/item/2092f0427fcdf5e6dc0f6cab
