昨天本来想写一篇文章来说说开发的 select * 的问题，为什么DBA特别讨厌 select * 的出现。估计开发的同学都能背的出来
1 select * 影响数据库的性能，无关的字段造成无用的数据的提取，会造成SQL 语句性能低下。
2 select * 在多个表 JOIN 或者子查询，用 星号造成SQL无法被正常辨别，例如两个表都有字段 name ，要SQL 来怎么解释没有标识的 name 字段到底出自哪个表，这样的歧义，可能SQL 会报错，有的数据库则给你选出一个他认为对的，可这样真的好吗，所以DBA 在很多时候都是不待见 select * 的出现。
其实这些东西在我的脑子里面早就熟记入心，和开发的同学来掰扯也是很顺手的。
可这样说和Argument,和原来的老路又有什么不同，偶然想起多年的一句，屁股决定脑袋，当时是在是无知，这样一句中性的话让我理解成为一句“”恶言恶语“”。
如何能成为一个合格的数据库架构师，而不再是DBA，在遇到这样的情况我又有什么好的方法来化解习以为常的问题呢？
这时屁股决定脑袋的这句话在我脑子里面围绕，我需要从开发的角度来说明这样做的危害性，换一个角度理解开发，或许他们并不知道这样写的害处，出了性能的问题，和规范的问题以外的 “”另一篇天空“。站的位置变了，想的问题也必须开始多起来。否则这脑袋如何配的上“屁股”。
OK， 从开发的角度来说，写select * 也有如下的尴尬
1 程序在读取数据的时候，还是有字段的限制的，例如原来的程序设置了 5个变量，来承接你这 5个字段，但你写成select * ，当你添加了，或剔除了，在或者是改变了字段的位置，个数，甚至是名字，你的程序会莫名的报错，而你还不知道哪里错误了。
2 在视图中使用select * 也会造成某些不必要的麻烦，例如你变动了表的结构，认为你写了select * 视图的结构就会和你的改变的表结构一样改变，那就大错特错了，很可能结果让你大跌眼镜，视图还是会保持原来的表结构，同时你的错误理解也会造成不必要的系统故障和错误的数据展示等问题。
凑够了这两条和开发有关的错误提示，感觉瞬间和开发的举例又近了一步，为他们着想，互相理解自然双方都会有 双赢的结局，皆大欢喜。
看来我已经享用了“”屁股“”给我脑袋的力量，放弃DBA的思维模式，往“屁股”的层次努力着ing.
