※ 引述《ripple0129 (perry tsai)》之铭言：
: 通灵一下
: 问题是不是报表类啊
: 要全表或大量join大量计算的
: 资料少跑一下SQL就好
: 资料大跑到炸掉
: 会去想到资料大时会炸锅
: 表示有经验了啊
: 多的是新手没想过这种问题
: 不过不要紧了
: 等慢到一定程度
: 就会开始跑daily的过去统计
: 到时重构就好
: 先求功能出来且正常
: 未来再处理效能
: 没有足够filter条件的SQL
: 往往都是要重构的
: 别担心遇到了处理就好
: 只要确定目前储存的资料
: 未来有办法做重构即可
: 如果现在设计的schema不符合未来重构
: 那就要换schema来储存
以前遇过是客户要的报表有可预料的效能问题(不要在数据库对海量数据
进行recursive string concat). 但经理已经答应了客户.
当时的做法是:
1) 要经理向客户解释情况, 最好说股客户不要会出问题的部份. 不过这被经理否决了
2) 让经理另外找人做, 别说我故意做差这功能.
结果代我做这报表的同事写出来的东西, 即使在demo data量下也要跑十多分钟
才能显示.
后来我用我的方式重做, 也不过是把时间压到一分钟左右. 但留意这是在demo data
的环境下. 实际使用的话一年半载后不把那部份去后谁也别想救. 经理没办法下
也只能用我写的去交差了.
当然, 一年半载后我已经离职了, 也没看到后续如何.
重点是: 没实作相应环境证明你说的情况, 上司不见得会听进去.
Clone一个环境, dummy fill一堆数据把量撑大, 让上司实际看情况比较重要.
而更重要的是过程要loud, 要确定相关人物都知道你已经事先警告过了,
也花时间实业证明了, 这也要继续的话, 日后出问题就和你没关系了.