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)按索引取值，则会拿到完全无关的数据。

最令人头疼的是，这类问题往往不会直接抛出错误，而是静默地发生数据错位。这就像查询数据时一切看似正常，直到系统正式上线运营数天后，你才猛然发现统计口径已经完全偏离了预期。