HoneyHoney

同事share了一本书，自己瞄了一眼，觉得不怎么样，就搁在一边了。老板后来会上提到这本书，然后挑了几个tip讲解一下，顿时豁然开朗。回来重新读这本书，很大部分读不懂，仅列出自己略微有点概念的部分。

为什么SELECT *会很糟糕？因为这意味着更多的数据，更多的IO和网络消耗。
公司项目里面有个订单管理系统，这个订单管理系统的瓶颈常常在于库存量更新的时候。当有很多人来注册的时候，会有很多订单，这些订单都需要去更新库存量，导致了后面数据库这边非常得慢。不知道把这个库存量存到application里面，到一定时间的时候再回写到数据库里面（有点像transaction log了），这样的话系统会不会好一点。

最近刚好遇到一个例子。之前的query里面用了一个游标，每个游标又去调一个存储过程，那简直是想死的心都有了。直接把那个存储过程里面的query剥离出来，然后去掉游标，性能哗啦啦从30+秒到10秒以内。当然我有时候还是会用游标，比如逐行更新记录，每条记录又都不一样的时候，但是还是尽量避免。

暂时不能够理解为什么，因为还没有遇到过。这也是这本书的缺点，缺乏足够的例子去阐述这些观点，这就需要别人需要有足够的经验才能够理解书里面的东西。

UNION会排序并去重，不是简单去重。曾经做过数据修复，数据修复的时候，需要找出需要修复的数据，而这些数据的顺序是不会影响后续过程的。我习惯性地加了一个ORDER BY，被DBA发现以后支出这个是没有必要的。


这个会有点有趣。这里有个详细的文章讨论Table variable: http://sqlhints.com/2014/02/10/difference-between-temporary-table-and-table-variable-in-sql-server/ 由于table variable上面没有statistics，SQL会认为它只有一条记录，对这个表操作都是table scan。数据小，表关联少的情况下，情况不是很严重，但是如果表关联多的时候，这个将是performance糟糕的原因。

这里有个局限，一次INSERT最多只能够有1000个VALUES。
PK上面创建clustered index是默认behavior，但是FK上面却不会自动创建index。一般情况下，我们是需要对FK创建index，除了一些情况，比如这张表很小。
再次建议读一次 http://sqlhints.com/2014/02/10/difference-between-temporary-table-and-table-variable-in-sql-server/。Table variable 同样可以创建index。