最近我发现在上次Release中,由于时间太紧,个人水平有限,在许多存储过程中用了这么一个子查询,用以过滤用户没有权限访问的交易业务,类似这种形式:

DECLARE @IDs TABLE(GroupID INT)
--填充该用户无权限的组ID
SELECT * FROM Deals WHERE GroupID NOT IN (SELECT GroupID FROM @IDs) 

 当时加上这个子查询时,因为前面还有很多连接操作,认为慢也正常。但是当我要将这段逻辑扩展到其他功能上时,我犹豫了,有些很常用的查询也要等个近一分钟,就算用户能忍受,我自己都接受不了,于是我试着把(SELECT GroupID FROM @IDs)换成(3,4,5,...)这种直接数字。结果一试,大吃一惊,原来时间几十秒的执行,一秒内跑完!

自己太天真了,原来SQL Server根本不会去优化子查询,将结果缓存下来并内联。

不想用动态SQL,于是google一下,找到子查询(in not )转化为连接查询的方法,上面语句转化为:

SELECT * FROM Deals d
LEFT JOIN @IDs i ON i.GroupID = d.GroupID 
WHERE i.GroupID IS NULL

也基本是一秒内完成。

了解这个后,心情又沉重又悲痛。悲痛的是我工作了这么多年,SQL还是菜鸟,而且同事中没有一个能指出来这么简单的问题。沉重的是从SQL Server 2000到2012,还是老样子,除了不能优化子查询,还是定义集合变量,依然笨拙的聚合操作,可怜的SQL复用性支持,难于调试。其实,不只是SQL Server,这是所有关系型数据库,积重难返的通病,是已经严重滞后的SQL语言对生产力的巨大桎梏。

在我经历以数据驱动的系统,可能SQL开发代码量只占一小部分,但其工作量要数倍于面向对象语言,而且Bug的集中营,还集中了几乎全部系统性能的勒索。SQL不但谋杀程序员的青春,更绑架了无数程序员的思想,不会学习新技术,不会复用代码,不会单元测试,就是被SQL绑架的程序员。

在一个崭新的系统你们不会觉得,这时数据库像一个温顺可爱的小猫,但随着它一天天长大,数据一天天增加,你会发现它变成了一头可怕的老虎,不是只有程序员,还有用户,部署人员,DBA,都要小心翼翼的伺候着。

看着被吃掉的时间和金钱,我们不能再养虎为患了。那么我们现在应该怎么做呢?

小型服务器系统和中小型客户端系统,比如手机上的一个应用,仍然可以用关系型数据库,但一定要把它放在ORM的笼子里,而且要提防它长大。

区别是否该用RDBMS,有一个直观标准可以作参考,就是用Visual Studio或SharpDevelop中的Entity Model设计器,如果对象排满了一页,关系七零八落看不清楚,就该考虑No-SQL数据库。

对于大型客户端系统,应该用强对象型数据库,比如db4o。对于中大型服务器系统,应该采用分布式对象数据库,比如MongoDB。

或者,根据系统性能需要,开发专门的存储格式。

对于巨型服务器系统,比如Google/Facebook,除了Hadoop这类分布文件系统,没有第二选择。

那种几百个表,几千个存储过程的系统,是时候进入历史的垃圾堆了。我还算庆幸,手头这个项目再用一年左右就会淘汰了,如果你的现在的工作或新工作也是这种项目,请好好考虑一下自己的职业发展吧。

posted on 2013-03-22 19:53  小城故事  阅读(785)  评论(3编辑  收藏  举报