解惑

对Sql Server彻底失望

Cherami — Tue, 29 Apr 2008 10:38:30 +0000

今天为QA写一个报表，使用了存储过程，在里面定义了一个临时表，然后向临时表插入数据，插入数据的顺序和临时表的字段定义的顺序不一样，结果出来的结果乱七八糟，查了半天也没有想到什么原因，后来突然想到是不是和顺序有关，修改了insert语句里面的字段插入顺序，问题搞定。
唉，不知道是我对SQL了解太少还是SQL server确实很烂。

例子如下：
DECLARE @TEMP_TABLE TABLE (id int,count int)

insert INTO @TEMP_TABLE
select x.id as id, count(x.id) as count
from xxx x group by x.id

insert INTO @TEMP_TABLE
select count(x.id) as count), x.id as id
from xxx x group by x.id

上面的那个insert可以工作，下面的不能，得到的结果和期望的是不一致的

作者: 解惑/Cherami
原载: 对Sql Server彻底失望
版权所有。转载时必须以链接形式注明作者和原始出处及本声明。
分类: 软件开发

SQL Server性能问题

Cherami — Tue, 11 Mar 2008 06:27:10 +0000

昨天遇到一个奇怪的性能问题，一个SQL对于某些用户特别的慢，需要2分钟以上，但是把那个SQL抓出来，把参数填进去直接运行又非常的快，只要不到2秒，猜测可能是和SQL Server的执行计划出了问题，以前遇到过类似的问题，在某些状况下，SQL Server的执行计划很糟糕，稍稍修改了下SQL，把参数中的一个常量值0直接写到SQL中，问题解决。
修改前的SQL片段（rfpId的值是0,1234两个值，修改后等于1234）：
and x.yId in (:rfpId)
修改后：
and x.yId in (0,:rfpId)

原来遇到的一个性能问题类似，就是一个很复杂的SQL，对于某些用户也是非常的慢（该用户相关的数据比较多），查询可能需要2分钟，后来把复杂的SQL切分成两个SQL，总共的查询时间只需要不到1秒。

所以在使用SQL SERVER的时候，能够直接在SQL里面固定的值直接写到SQL里面，不要写太复杂的SQL，SQL Server的执行计划优化器存在很多的问题。

作者: 解惑/Cherami
原载: SQL Server性能问题
版权所有。转载时必须以链接形式注明作者和原始出处及本声明。
分类: 软件开发

Inner join的问题

Cherami — Fri, 21 Dec 2007 13:27:51 +0000

这个是最近感觉最有成就的一个发现了。
我们的系统有一个存储过程执行一个很核心的查询功能，但是在某些情况下非常的慢，而且最近QA一直在做性能测试，每天发送大量的数据，导致系统的性能越来越慢，我原来也曾经优化过这个存储过程，建了很多索引，解决了那个时候管理员用户的问题，但是现在很多普通用户的问题更加的严重，经过调试发现第一步的查询非常的慢，打印出结果来发现那个查询会产生9千万条纪录，而且会使用多达6G的硬盘空间来存储临时数据，后来加了个distinct解决了空间问题，空间使用不到6M，但是速度还是很慢，使用Tuning Advisor优化也没有什么帮助，后来我想了下为什么会产生那么多相同的数据呢？仔细看了下SQL，发现它用6个表进行inner join，但是只从其中的四个表各取一个字段，我就把另外的两个表从inner join移到where条件了，查询时间从6分钟（问题最大的一个用户）减少到6秒，呵呵

作者: 解惑/Cherami
原载: Inner join的问题
版权所有。转载时必须以链接形式注明作者和原始出处及本声明。
分类: 软件开发

Impossible Is Nothing

Cherami — Thu, 22 Nov 2007 10:06:13 +0000

今天才算切身的体会到这句话的含义。
最近在进行性能调优，前几天的机会已经非常的好了，从前天开始，很多请求丢失了，使用JMeter做压力测试，很多登陆后请求的页面转向登陆页面了，看了服务器的错误日志，很多都是数据库连接被关闭的问题，刚好前几天性能调优的时候修改了一些相关的东西，就把自己的那些修改都回滚了，但是测试的结果越来越差，到今天早上终于水落石出了：服务器的后台错误日志充斥了如下的错误：
The transaction log for database ‘tempdb’ is full.
上网搜索了下，说一般是磁盘空间不足引起的，远程登陆到数据库服务器一看，什么磁盘空间不足啊，就是没有，剩余磁盘空间为0！！！
把tempdb的数据全部清除，重启，重新测试，结果Perfect，前几天报的一些性能不佳的问题全部没有了，请求丢失的问题也没有了，登出的问题也没有了！
呵呵，一个问题引发无数的问题，在没有严重到磁盘空间满之前，还是其它的错误信息，最终才水落石出。
对了，我们用的数据库是SQL Server，无语

作者: 解惑/Cherami
原载: Impossible Is Nothing
版权所有。转载时必须以链接形式注明作者和原始出处及本声明。
分类: 软件开发

保持开放的思想

Cherami — Tue, 29 May 2007 09:30:42 +0000

今天突然发现自己原来对Ruby和RoR的抵触是完全没有道理的，因为自己理想中的Java开发框架和RoR的很多思想其实是相同的，可能是太喜欢Java，使用的时间也太长，任何对它可能构成威胁的东西都会有本能的反应了？
其实Java语言本来也是吸取其他语言的精华而创建出来的，每当有一种新的语言诞生的时候，也同时意味着它必定有什么优势，否则是很难被人接受并被广泛使用的，如果本着学习的精神，我们其实可以从这些新兴的语言身上学习和借鉴这些优点，并努力借用到Java的开发中，除了语言本身的限制，我们应该是可以借鉴很多。
我想如果一个掌握OO设计的高手去使用汇编或者C语言做开发，那么他在OO中学习到的一些东西肯定可以借用到这些语言中。

PS：Java世界一直没有出现我期望的框架，我自己也在尝试做一个，需要研究研究RoR了，很多规则或者思想可以借鉴过来

Bug无处不在

Cherami — Wed, 09 May 2007 00:31:46 +0000

最近在玩Travian，一个web浏览器的升级游戏，纯粹就是闲着没事的时候打发时间
今天发现一个bug，当然，任何软件系统有bug都是正常的，这里只是感觉比较有意义，就是数据量大的时候的数据的有效性最容易犯的错误。

软件开发过程思考之一：人

Cherami — Sun, 29 Apr 2007 00:32:18 +0000

人，是软件开发过程中最重要的部分，因为软件是一个智力密集型的产业，在基于差别不大的硬件设施上，我们要作出满足不同需求的系统，而目前的计算机系统还不够智能，不能创造出新的系统来满足我们的需求。
在软件开发的整个过程中，只有很少的一些关键环节可能不太需要人的主动干预（例如Daily Build），其它的部分，都是需要发挥人的能力来完成的。
这群人，就是程序员或者软件工程师，在局外人的眼中，这群人是拿着高薪做一些轻松的工作，但是真实的情况只有这个圈子内的人才真正知道。
软件系统的成功与否依赖很多因素，但是没有一个因素不是和人相关的，所有软件系统的成功与否，完全是由涉及其中的人来决定的。也正因为如此，一个软件系统的成功与否是很难预见的，人太不稳定了，可预见性太差了，而且，作为一个特定的群体，程序员是比较难于管理的，因为很多程序员是聪明的、喜欢无拘无束、内向的、敏感的。
也正式因为人是最大的因素，而每个人都是有差异的，每个人的人生观不同，工作态度不同，学习能力不同，沟通能力不同，要想将项目中的每个人的最大能力发挥出来几乎是不可能的任务，单纯的依靠物质奖励在一段时间内是有效的，但是经过一段时间以后，物质奖励并不能继续发挥太大的作用，特别是对于能力特别突出的人而言，或者对于特别有野心的人而言，因为很多这样的人可能都想自己创业，不想继续被盘剥，想证明自己是不一样的。

人，这个因素太复杂了，并没有想得很充分，随时再更新吧。