只是给个建议，这样的项目适合敏捷开发，具体项目的里程碑及提交物的裁剪可以根据你们组织内部的项目管理模板来做。 另外，项目需求很模糊，需要做产品的多次迭代发布，另外，我没有看见测试人员，测试计划应在编码开始前就提交给你，项目缺少风险分析和管理，沟通计划我只能说勉强过得去，但是你的项目干系人好像没有很明确的概念，另外，你担心人员资历的问题，可以通过项目正式的启动会和公司授权的项目章程来解决和明确，当然你自己还需要付出努力，让组员信服你的能力

GSP，很赚钱的啦，如果有关系的话。没关系就没市场。

[quote]winter-cn： 提点建议 也许有用： 1.选择合适的，成熟的项目管理方法，要加以合适的裁剪（比如Scrum） 2.把架构设计交给开发经理，文档化架构设计，设计不在详细，关键是组里的人都舒服就行了 3.设立确定的周期来更新和修正需求 4.量化工作量，以直观的方式定期向领导汇报进度（图表） 5.技术问题交给最合适的人去做，你不一定要做决定 6.确保会议的敏捷性，时刻保持会议上说的每一句话都是所有参会人都应该听的（比如2个人就某一细节争论时，你要及时以正确方式打断）[/quote] 补充： 1、让大家（组员及其他相关人员，而不单单是boss）都知道你现在负责这个项目了。 2、确定项目的边界，可能是lz现在急需的。

@winter-cn 很受用，谢谢

提点建议 也许有用： 1.选择合适的，成熟的项目管理方法，要加以合适的裁剪（比如Scrum） 2.把架构设计交给开发经理，文档化架构设计，设计不在详细，关键是组里的人都舒服就行了 3.设立确定的周期来更新和修正需求 4.量化工作量，以直观的方式定期向领导汇报进度（图表） 5.技术问题交给最合适的人去做，你不一定要做决定 6.确保会议的敏捷性，时刻保持会议上说的每一句话都是所有参会人都应该听的（比如2个人就某一细节争论时，你要及时以正确方式打断）

@小轰 不好意思，我们这边说惯了，MS Project定的项目

@navyliu 对，被看出来了，呵呵

@剁椒鱼头 这样啊，看来是我自己孤陋寡闻了。不过希望楼主能把表达能力提高。

[quote]小轰：项目和project有区别吗？把“项目project”连在一起写，是想说你英文很好还是时间太充裕？[/quote] 估计楼主是指的是用MS的Project做项目计划，做过的估计也都能看懂。

项目和project有区别吗？把“项目project”连在一起写，是想说你英文很好还是时间太充裕？

小项目还好做一些，大项目太折腾了，需要超强的组织能力。

和楼上兄弟有相同的问题,GSP框架,好熟悉的一个名词

浪潮通软的兄弟？

4）点错了，如果索引和数据都在同一个文件组，只能用到一个处理器的核心；或者一个单核处理器，分区意义不大，只剩下维护的意义。

个人理解： 1）分区包括水平分割和垂直分割 2)分区只有把数据分散在不同的服务器和物理存储设备上才可以大幅提高硬件性能。 3)如果分区在同一个硬件设备上，只是方便DBA维护某一个分区的数据，例如整理索引/碎片。 4）理论上分区的数据以文件组存放，在多处理器的服务器中，可以根据文件组的数量N，启用N个线程同时处理增删改查。不过SqlServer好像只支持索引文件组和数据文件组2个线程处理，如果索引和数据都在同一个文件组，或者一个单核处理器，分区意义不大。 5）分区就类似一个一级索引，表索引就好象二级索引。如果没有分区，并且一个表的记录量非常大，查询的时候加载索引到内存也需要时间；如果有分区，根据查询条件，可能只需要加载的1～N个分区的索引到内存。

加班的确很累，能够理解博主的一些想法。
当然，能够有策略的学会东西才是真正值得骄傲的地方。要坚持自己坚信的东西，这样才能保持清醒的头脑：）

--引用--------------------------------------------------
丁学: 呵呵，就当是交学费了
我一直坚持一个原则：问朋友，网上查，然后直奔目标，商家推荐一概不理
--------------------------------------------------------
某也是这原则，不过还是先看看推荐，当然基本不会影响之前的计划。随便看看，有个底比较好：）

@Eric zhou
其实分区文件放在一个盘上，分区的意义就不大

@丁学
恩，就算交学费了，呵呵

破网速测出惊人BUG，我找DUDU去~~~

呵呵，就当是交学费了
我一直坚持一个原则：问朋友，网上查，然后直奔目标，商家推荐一概不理
虽然有错过更好东西的可能性，但是绝对可以防止忽悠

呵呵，就当是交学费了
我一直坚持一个原则：问朋友，网上查，然后直奔目标，商家推荐一概不理

有班加总比没得做强，经济不景气，好多人待业在家啊

加班不是一件好事,身体重要
拼命也是讲策略的,加油

大哥，别说了问题，不说解决方案啊？

不好意思，各位，上边第三个查询中应该为：
USE Northwind;
GO
SELECT CustomerID,OrderID,ShipName FROM orders WHERE CustomerID = 'vinet' OR OrderID = 10356
不小心写错了，误解了朋友们，抱歉啊

@金色海洋（jyk）
推荐您个文章：
http://geeks.netindonesia.net/blogs/kasim.wirama/archive/2008/04/20/logical-and-physical-read-in-sql-server-performance.aspx

@金色海洋（jyk）
逻辑读取平均比物理读取快15倍左右
逻辑读取时来自数据库缓冲池中的数据，缓冲池也是8K的页面内存。
缓冲池中的数据觉得多数为索引。

没事，不着急，您先忙。

还有一个问题，查看第10000业的记录的时候，发现Row_Number得到的记录集和表变量、颠倒Top的记录集明显不一致。

而表变量和颠倒Top的记录集是一致的。

记录太多了，我也数不过来了，不知道哪个是正确的了。

@金色海洋（jyk）

不好意思，今天手头比较忙，这个问题可不可以先放一放，到时一起研究一下
MSN：ererer6@hotmail.com

更正：是显示第5000页，不是第500页。

向楼主问个问题，我执行了三个SQL语句，得到了下面的几种情况，想麻烦楼主帮忙分析一下，出现这种情况的原因。

目的：对 Products 进行分页处理，表里面有二百五十多万条记录，以显示第500页为例，分析三种算法的效率。

ProductID ：主键，聚集索引。

UnitPrice,ProductID desc ：非聚集索引。


1、表变量，分页用的SQL语句。

SET STATISTICS IO ON

dbcc freeproccache
set nocount on declare @tt table(id int identity(1,1),nid int) insert into @tt(nid) select top 75000 ProductID from Products order by UnitPrice,ProductID desc select * from Products t1, @tt t2 where t1.ProductID =t2.nid and t2.id between 74986 and 75000 order by t2.id set nocount off

分析结果：

清空缓存的结果：

表 '#68487DD7'。扫描计数 0，逻辑读取 75157 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 1，逻辑读取 172 次，物理读取 0 次，预读 167 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 0，逻辑读取 45 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 '#68487DD7'。扫描计数 1，逻辑读取 158 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。


没有清空缓存的结果：

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
表 '#6477ECF3'。扫描计数 0，逻辑读取 75157 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 1，逻辑读取 172 次，物理读取 0 次，预读 67 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 0，逻辑读取 45 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 '#6477ECF3'。扫描计数 1，逻辑读取 158 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

用时：小于1秒。

疑问：一个表怎么变成了四个表呀？怎么没有物理读取？

====================================

2、颠倒Top，分页用的SQL语句。

SET STATISTICS IO ON

dbcc freeproccache
select * from Products where productid in ( select top 15 productid from ( select top 75000 unitprice,productid from Products order by unitprice,productid desc ) as t order by t.unitprice desc,t.productid )order by unitprice,productid desc

分析结果：

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

(15 行受影响)
表 'Products'。扫描计数 1，逻辑读取 217 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

用时：小于1秒。
疑问：怎么只有一个表了，颠颠倒倒好几回了，逻辑读取也很少哇，上面的有75157 次之多，这里只有 217 次。

====================================

3、Row_Number，分页用的SQL语句。

SET STATISTICS IO ON

--dbcc freeproccache
with t_pager as (select myIndex = ROW_NUMBER() OVER (ORDER BY UnitPrice,ProductID desc ),* from Products ) select * from t_pager where myIndex between 74986 and 75000


（限执行了一下 dbcc freeproccache ，然后再执行的 SQL语句）

分析结果：

清空缓存的结果：

(15 行受影响)
表 'Products'。扫描计数 1，逻辑读取 230304 次，物理读取 660 次，预读 184 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。


没有清空缓存的结果：

(15 行受影响)
表 'Products'。扫描计数 1，逻辑读取 229868 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

疑问：逻辑读取还是很高！
====================================



三种SQL语句得到的记录集都是一样的，差别最大的地方就是逻辑读取 次数，为什么差这么多呀？

@金色海洋（jyk）
逻辑读取次数越多，说明执行的成本就高，速度是否越慢，这个需要具体情况具体分析。

表 '#2D27B809'。扫描计数 0，逻辑读取 255 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 1，逻辑读取 4 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 0，逻辑读取 45 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 '#2D27B809'。扫描计数 1，逻辑读取 1 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。


表 '#3E52440B'。扫描计数 0，逻辑读取 150495 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 1，逻辑读取 340 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Products'。扫描计数 0，逻辑读取 45 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 '#3E52440B'。扫描计数 1，逻辑读取 316 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。


========================================


(15 行受影响)
表 'Products'。扫描计数 1，逻辑读取 384 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(15 行受影响)
表 'Products'。扫描计数 1，逻辑读取 3402 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。


是不是 逻辑读取 次数越多，速度就越慢呀。

最后一个忽悠人的 不在于是不是or 而在于lower函数无法利用索引

@Eric zhou
你可以gg一下 sql server recompile 这几个关键字，以及recompile的诱因。
sql server是以什么样的策略在应对选择度不高的索引。
可以参考 with(recompile)选项， optimize for (@x=12)等选项。你会明白更多。

已经加你了

使用了UNION来代替OR就会更好吗？不一定吧，要看具体的情况了，具体问题具体分析。

好的，谢谢。

@金色海洋（jyk）
执行SQL前先执行
SET STATISTICS IO ON
就可以了

表 'Orders'。扫描计数 1，逻辑读取 15 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。


这些数据是怎么得出来的呀？

@PerfectDesign
在客户实际环境中，经常要对查询增加索引，当然在允许的条件下，很多SQL中的where条件都是以变量的形式，所以第一次执行后很编译成执行计划，当你加上索引后，有可能还是调用原有的执行计划，所以清空下过程缓存，对比执行成本。

@PerfectDesign
学习了，谢谢您的赐教。您说的书签查找是index seek么？如果'VINET' 占99%，肯定不会这个了，所以还是您说的对，具体环境下具体分析，模拟环境和客户实际环境还是不同啊。可以交个朋友么，MSN：ererer6@hotmail.com。谢谢

你测试中也没有插入数据，新建索引，改变表结构，没有变更查询选项，咋的引起重编译？
也没有测试同一条语句，怎么使上了这个语句呢？

or和union的举例比较牵强，具体环境下具体分析，本质应该跟大家说清楚，是在你这个测试环境下的书签查找成本要少于扫描成本，所以选择了书签查找，如果要是 'VINET' 占99%，那还会是这个吗？

另外，如果表内数据不足以跨区，那还会是书签查找吗？

@PerfectDesign
在客户实际应用中，不会执行这个的，用 DBCC FREEPROCCACHE 清除过程缓存，这样重新执行sql编译成不同的执行计划，可以对比成本。

唉，平时就知道随便写个语句，从来没有考虑这么多。

废话一下，你执行
dbcc freeproccache 这些语句不要乱执行哦。

你又没有打开时间统计，干嘛要这个呢？

顶多写个recompile就可以了。

生产环境下可别执行那玩意，会出人命的。

sf~

@金色海洋（jyk）

已更新SQL调优说明讲解。