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

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.238.59.15 (香港) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1578398227.A.351.html