一、减少输入

　　程序员都喜欢使用通配符，如：

SELECT * FROM Person

　　又或者省略字段名：

　　INSERT INTO Person VALUES('10','张飞'...)

二、捷径会让你迷失方向

　　对于以上代码，如果你仅仅是在开发过程中用于查看一下数据库信息，又或者你只是写个小程序自己玩玩，这是没有什么问题的。

　　但是如果一旦你习惯于这样编写正式生产环境中的代码，那问题就随之而来了。

　　1、破坏代码重构

　　如果数据库更改了，比如增加了一列：

　　ALTER TABLE Person Add Age int

　　这下糟糕了，你程序中所有的

　　INSERT INTO Person VALUES(...)

　　语句都会报错。

　　早使用这种隐式模式执行INSERT时，输入必须严格按照定义表时的那些列的顺序，如果列变了，这条语句就会抛出一个错误，甚至有可能就会抛出一个错误，甚至有可能把数据写到错误的列里面去。

　　假设原本是使用隐式模式查询：

　　SELECT * FROM Person

　　但是加入删掉了中间的一个列:

ALTER TABLE Person DROP COLUMN Age

　　那么加入是使用DataTable的方式装载数据库内容，那么row[10]可能就已经不是第十个。在重命名、添加、删除列的时候，程序代码并不能适应查询结果的改变。如果使用了通配符，就无法预测这个查询会返回多少行。

　　2、隐藏的开销

　　在查询中使用通配符可能会影响性能和扩展性。一次性查询所获取的列越多，客户端程序和数据库之间的网络传输的字节也越多。

　　生产环境中的程序可能会有很多并发的查询请求。它们都共享同一个网络带宽。太多客户端同时查询返回上千条记录可能会造成阻塞。

　　3、合理使用反模式

　　在你只是为了快速地写几个脚本对一个解决方案进行测试，或者写临时SQL查询对当前数据进行查看时，使用通配符是合情合理的。只执行一两次的查询对可维护性没有任何要求。

　　当然，输入一张很多列的表的所有列名是很耗时的，对某些人来说，开发效率可能比程序运行效率更加重要。例如，当你开发的是较少用户量的小公司内部访问程序，这时候返回数据所使用的带宽比查询语句本身要多得多。这时候没必要纠结这些问题。

三、解决方案-明确列出列名

　　1、预防错误

　　每次查询都列出所有你需要用到的列，而不是使用通配符或者隐式列的列表。

　　SELECT Id,Name... FROM Person 　　INSERT INTO Person (Id,Name,Age...) VALUES(1,'张飞',22...)

　　这样做的好处如下：

• 　　如果这张表的某一列的位置被移动过，他不会对返回结果中这一列的位置造成影响。
• 　　如果这张表中新加入一列，它是不会出现在查询结果中的。
• 　　如果从这张表中删除一列，你的查询会得到一个错误，但是直接就能够找到问题所在，这是符合尽早出错原则的。

　　2、减少资源占用

　　如果必须关心软件的可扩展性和程序的吞吐量，你应该检查一下网络传输过程中可能造成的浪费。一旦在SQL中禁用通配符，那么就很自然地去除那些不需要的列，提高了带宽和内存的使用效率。