为何SQL视图定义不建议SELECT *而指定列名？

从语法层面看，在SQL视图定义中使用SELECT *绝对不构成错误。但从设计层面审视，这几乎等同于主动放弃了对于输出结构应有的掌控权——视图一旦创建，其列名、列序、列数理应是确定的，而*却让这一切变成了运行时才揭晓的悬念。

视图列结构会被底层表变更悄悄破坏

一个关键点在于：视图定义本身并不存储字段的元数据，它仅仅保存了原始的SQL文本。这意味着，当你用SELECT *创建视图后，隐患就埋下了。

设想一下，后续你对源表执行ALTER TABLE ADD COLUMN updated_at DATETIME，直接后果是什么？视图的查询结果会立刻凭空多出一列，但你的视图定义里压根没出现这行代码。更麻烦的是，下游应用可能正按位置取值（比如rs.getString(2)），或者BI工具正依赖列名进行自动映射。那么，它们拿到的数据就会错位，甚至直接报错中断。

此外，不同数据库平台对*的解析逻辑也存在差异，比如SQL Server和Access的处理方式就大相径庭。这在跨平台迁移时，很容易导致列序不一致，进而引发一系列意想不到的问题。

JOIN多表时SELECT *必然触发列名冲突

当视图涉及两张或更多表的JOIN时，SELECT *的危害会变得更加直接。只要两个表存在同名字段，比如都有id、name或created_at，数据库就会当场抛出Column 'id' is ambiguous的报错。

要规避这个问题，你不得不显式地进行限定：

• 使用表别名添加前缀，例如将users.id重命名为user_id，将orders.id重命名为order_id。这是最基础的做法。
• 对于那些包含空格或特殊字符的字段名（比如[E-mail Address]），必须加上方括号，否则解析过程就会失败。
• 更重要的是，语义上相同的字段，应当统一使用别名。比如，将users.full_name和admins.display_name都映射为name，避免下游系统因硬编码依赖原始名而出现混乱。

性能与执行计划会被*拖垮

SELECT *带来的影响远不止“读取的字段太多”这么简单。更关键的是，它让数据库的优化器“捉摸不透”你真正需要什么。

• 一个本来可以利用覆盖索引的高效查询（例如在WHERE status = 1字段上建立索引），一旦改用SELECT *，优化器发现索引里并没有覆盖全部字段，就会被迫进行回表操作。在EXPLAIN的输出结果中，你会看到Extra列从理想的Using index，变成了代价高昂的Using where; Using index; Using temporary。
• 如果表中包含TEXT或BLOB这类大字段，单行的物理大小会急剧膨胀。SELECT *会把一整页的数据都读入buffer pool，即使你仅仅关心id和title这两个小字段，也逃不掉巨大的I/O开销。
• 在MySQL中，还有一个实际限制：max_allowed_packet的默认值通常是4MB。当大字段与*结合使用时，很容易触发Packets larger than max_allowed_packet are not allowed的错误，导致查询失败。

工具链和ORM映射会因*失效

像MyBatis的resultMap、JPA的@Column注解、以及Power BI的自动列推断功能，所有这些工具都依赖于一个稳定、可预测的列名和顺序。

一旦源表新增了字段，或者通过ALTER TABLE … FIRST / AFTER改变了字段位置（这在MySQL中尤为常见），SELECT *视图返回的列序就可能发生变化。这会引发一系列连锁反应：MyBatis可能把新字段的值错误地映射到旧的字段属性上；Power BI刷新报表时会提示“column not found”或者列类型错乱；而Java应用如果用ResultSet.getObject(i)按索引取值，则会拿到完全无关的数据。

最令人头疼的是，这类问题往往不会直接报错，而是静默地发生数据错位。这好比查数据时一切都显示正常，直到系统正式上线运营数天后，你才猛然发现统计口径完全偏了。