专注,勤学,慎思。戒骄戒躁,谦虚谨慎

just do it

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

随笔分类 -  SQL Server 优化

上一页 1 2

SQL Server 并行操作优化,避免并行操作被抑制而影响SQL的执行效率
摘要:为什么我也要说SQL Server的并行: 这几天园子里写关于SQL Server并行的文章很多,不管怎么样,都让人对并行操作有了更深刻的认识。我想说的是:尽管并行操作可能(并不是一定)存在这样或者那样的问题,但是我们不能否认并行,仍然要利用好并行。但是,实际开发中,某些SQL语句的写法会导致用不到 阅读全文

posted @ 2016-07-12 08:45 MSSQL123 阅读(3459) 评论(8) 推荐(14) 编辑

SQL Server创建复合索引时,复合索引列顺序对查询的性能影响
摘要:说说复合索引 写索引的博客太多了,一直不想动手写,有一下两个原因: 一是觉得有炒剩饭的嫌疑,有兄弟曾说:索引吗,只要在查询条件上建索引就行了,真的可以这么暴力吗? 二来觉得,索引是个非常大的话题,很难概括出所有的情况,你不整出点新意来,倒是有抄袭照搬的嫌疑 既然写了,就写一点稍微不一样的东西出来,好 阅读全文

posted @ 2016-06-21 17:43 MSSQL123 阅读(11681) 评论(8) 推荐(7) 编辑

Sql Server 聚集索引扫描 Scan Direction的两种方式------FORWARD 和 BACKWARD
摘要:最近发现一个分页查询存储过程中的的一个SQL语句,当聚集索引列的排序方式不同的时候,效率差别达到数十倍,让我感到非常吃惊由此引发出来分页查询的情况下对大表做Clustered Scan的时候,不同情况下会选择FORWARD 或者 BACKWARD差别,以及建立聚集索引时,选择索引列的排序方式的一些思 阅读全文

posted @ 2016-06-02 14:36 MSSQL123 阅读(3776) 评论(12) 推荐(2) 编辑

通过手动创建统计信息优化sql查询性能案例
摘要:本质原因在于:SQL Server 统计信息只包含复合索引的第一个列的信息,而不包含复合索引数据组合的信息 来源于工作中的一个实际问题, 这里是组合列数据不均匀导致查询无法预估数据行数,从而导致无法选择合理的执行计划导致性能低下的情况 我这里把问题简单化,主要是为了说明问题 进行如下查询,就是查询那 阅读全文

posted @ 2016-04-24 17:51 MSSQL123 阅读(1678) 评论(2) 推荐(1) 编辑

sqlserver 存储过程中使用临时表到底会不会导致重编译
摘要:曾经在网络上看到过一种说法,SqlServer的存储过程中使用临时表,会导致重编译,以至于执行计划无法重用,运行时候会导致重编译的这么一个说法,自己私底下去做测试的时候,根据profile的跟踪结果,存储过程中使用临时表,如果不是统计信息变更导致导致的重编译,并不会导致重编译,但是现实情况下,对于一 阅读全文

posted @ 2015-09-08 23:01 MSSQL123 阅读(3183) 评论(1) 推荐(4) 编辑

上一页 1 2
点击右上角即可分享
微信分享提示