[size=large] 最近在搞一个政府项目的压力测试,200个并发访问的场景,在后台监控数据库CPU占用率老是居高不下,于是查看到底哪些执行的SQL语句占用资源大,发现这些SQL语句都有一些普遍的问题,不是没用索引就是没使用绑定变量...导致原本计划压力测试一周结束,没想到拖了差不多一个月。根据我经历,我对基于数据库的软件开发为什么如此频繁地遭遇失败有一些看法。先来澄清一下,这里提到的这些项目可能一般不算失败,但是启用和部署所需的时间比原计划多出许多,原因是需要大幅重写,重新建立体系结构,或者需要充分调优。我个人把这些延迟的项目称为“失败”,因为它们原本可以按时完成(甚至可以更快完成)。
数据库项目失败的常见的一个原因是对数据库的实际认识不足,缺乏对所用基本工具的了解。主管有意让开发人员对数据库退避三舍,甚至鼓励开发人员根本不要学习数据库!在很多情况下,开发人员没有充分利用数据库。这种方法的出现,原因可以归结为FUD[恐惧(fear)、不确定(uncertainty) 和怀疑(doubt)]。一般都认为数据库“很难”,SQL、事务和数据完整性都“很难”。所以“解决方法” 就是:不要卷入难题中,要知难而退,SQL语句完成业务逻辑就可以了,优化等到DBA去做就行了。
我一直很难理解这种数据库开发方法,原因有二:一个原因是对我来说,学习Java和C比学习数据库基本概念要难多了。现在我对Java和C已经比较熟悉,但是在能熟练使用Java和C之前我经受了许多磨炼,而掌握数据库则没有这么费劲。对于数据库,你要知道它是怎么工作的,但无需了解每一个细节。用 C或Java编程时,
数据库项目失败的常见的一个原因是对数据库的实际认识不足,缺乏对所用基本工具的了解。主管有意让开发人员对数据库退避三舍,甚至鼓励开发人员根本不要学习数据库!在很多情况下,开发人员没有充分利用数据库。这种方法的出现,原因可以归结为FUD[恐惧(fear)、不确定(uncertainty) 和怀疑(doubt)]。一般都认为数据库“很难”,SQL、事务和数据完整性都“很难”。所以“解决方法” 就是:不要卷入难题中,要知难而退,SQL语句完成业务逻辑就可以了,优化等到DBA去做就行了。
我一直很难理解这种数据库开发方法,原因有二:一个原因是对我来说,学习Java和C比学习数据库基本概念要难多了。现在我对Java和C已经比较熟悉,但是在能熟练使用Java和C之前我经受了许多磨炼,而掌握数据库则没有这么费劲。对于数据库,你要知道它是怎么工作的,但无需了解每一个细节。用 C或Java编程时,