通灵一下
问题是不是报表类啊
要全表或大量join大量计算的
资料少跑一下SQL就好
资料大跑到炸掉
会去想到资料大时会炸锅
表示有经验了啊
多的是新手没想过这种问题
不过不要紧了
等慢到一定程度
就会开始跑daily的过去统计
到时重构就好
先求功能出来且正常
未来再处理效能
没有足够filter条件的SQL
往往都是要重构的
别担心遇到了处理就好
只要确定目前储存的资料
未来有办法做重构即可
如果现在设计的schema不符合未来重构
那就要换schema来储存

推。既然想到了就能先设计好schema来为之后重构做准备

直接写个预存程序，让dba之后伤脑筋，如果没dba也可以让架构分离

那也是写SQL或产报表的人，也就是原原po的问题啊；再说table资料量多也有分段捞的通用改法，log类的胖table也可以多写个排程定期封存，不过不管哪个都是可以等遇到时再改