我有个“歧视”，就是开发写的视图基本都是有问题的。这来自于我多年的实际工作。视图是数据库的一个工具，但是绝大部分开发不是从数据库角度出发来写的。所以一般来说写的并不会让数据库很舒服，甚至是痛苦。
今天有一个开发拿SQL找到我，我一眼看到一个V_XXX。不用问，这就是一个视图，我对开发说你打开它，我看看。我极度怀疑这个写的不合格。打开一看，果然没让我失望。写的异常复杂就不说了，都这样。我们今天说点与众不同的。就是结尾的地方我眼前一亮看到group by 列1，列2，列3.。。。。。。我就往下看，很多。多的超过我见过的记录了。我饶有兴致的数了一下134个。也就是说前面多复杂我先不管，最后group by 了130多列。好家伙，我从业十多年着实没见过这样的。
group by是分组，130多个字段组合的分组我也是生平第一次见。这种分组排序消耗是很大的，其实就是严重的设计问题。我建议是重新梳理需求，我们重写查询，选择合适的基表来完成。不要在这个上面继续错下去了。
我想起我第二家公司时候看到一个之前的人写了4000多行的存储过程，为的就是为了给表定时增加一个分区。可怜的人，不知道数据库有自动分区的功能。一句话就搞定了。每次想到这个时候我就想到，TiDB是没有存储过程、触发器和函数的。可能即使是国产第一的数据库考虑到如果让开发自己DIY的话，对数据库的冲击太大。还是别给他们这种自由了。
我一般写视图和存储过程这种，基本10行解决。10行解决不了，要么需求问题，要么设计问题（表设计或者逻辑设计）。
有的时候真的佩服数据库，这种“垃圾”SQL居然也执行下来没有奔溃，数据库也真不容易。而且还运行了10年以上了，当然换一种数据库是不是还是能支持，还真不一定。大概率可能会奔溃。毕竟不是每个数据库都这么惯着的。
想起一句耳熟能详的话：在糟糕的设计下，一切优化都是无能为力的。（也许强大的硬件，比如一体机那种能解决）。所以设计（表、视图）是至关重要的，需要有专业的人士来完成。
