正如上一篇文章SqlServer性能优化——Partition（创建分区）中所述，分区并不是一个一劳永逸的操作，对一张表做好分区仅仅是开始，接下来可能需要频繁的变更分区，管理分区。在企业管理器中，虽然有“管理分区”的菜单，里面的内容却可能与你的预想不同，这里并没有提供直接对分区进行操作的方法，所以一些普通的操作，比如“增加分区”、“删除分区”之类的操作就需要通过脚本实现了。增加分区（Split Partition）“增加分区”事实上就是将现有的分区分割开，基于此，在SQL Server中应用的是Split操作。在分离分区的时候，不仅仅要在Partition Function上指定分割的分界点， Read More
虽然对数据库进行分区本身就能提高查询的性能，结合压缩，也能减少每次查询的IO。但如果数据持续增长，过于久远的历史数据就成了一个包袱，它们从来不在查询结果中出现，却或多或少的影响着每次查询的时间，成了一个挥之不去的阴影。此外，由于一个分区表的分区是有上限的（在2005中这一上限是1000），我们也并不能在一张表上一直分区下去。所以在这种情况下，我们一般需要同时拥有两张表，一张保存了最近的数据，用来应付所有的查询，这张表要足够精简，在其上的查询要足够敏捷；同时有另一张表，保存所有过时的数据——我们并不能把过时的数据一删了事。这里面的关键问题是，既然数据是随着时间持续增长的，那么当下有用的数据可能在 Read More
和压缩（Compression）相比，数据库分区（Partition）的操作更为复杂繁琐。而且与Compression一次操作，终身保持不同，分区是一项需要长期维护周期变更的操作。分区的意义在于将大数据从物理上切割为几个相互独立的小部分，从而在查询时只取出其中一个或几个分区，减少影响的数据；另外对于置于不同文件组的分区，并行查询的性能也要高于对整个表的查询性能。事实上，在SQL Server 2005中就已经包含了分区功能，甚至在2005之前，还存在一个叫做“Partitioned Views”的功能，能通过将同样结构的表Union在一个View中，实现类似现在分区表的效果。而在SQL Ser Read More
该方案产生于2005年,当时我接手了某产业库的设计.我们在开发这个产品时,在数据库中引入了100万条记录作为开发版数据库.开发过程非常顺利,前台程序的测试速度也非常好.但我们在后来将当前的5亿条数据库追加到开发库进行测试时,发现无论什么情况,都无法从数据库中取出记录,发现在读取数据库时,磁盘灯一直在亮,而性能性能监视器里的CPU使用率很底.此时的SQLSERVER服务器会呈的假死状态. 后来我想我们的数据库为优化而预留的空间被填满后,数据会被追加到数据库文件的最后页.会不会是因为这个原因,导至了磁盘的磁头寻道,读取的效率下降?而造成了一个高I/O的假象?基于这个想法,我再次到查询分析器中运行了 Read More
以下是SQL 日期截取 & SQL Server日期比较日期查询常用语句select CONVERT(varchar, getdate(), 120 )2004-09-12 11:06:08select replace(replace(replace(CONVERT(varchar, getdate(), 120 ),'-',''),' ',''),':','')20040912110608select COUNVRT(varchar(12) , getdate(), 23 )2008-04 Read More