视图中使用 select * 会导致列结构不可控，引发元数据丢失、列序不一致、字段冲突、查询性能下降及工具链映射失效等问题。
视图里用 SELECT * 会让列结构变成运行时黑盒
视图定义不保存字段元数据，只存 SQL 文本。一旦底层表 ALTER TABLE ADD COLUMN，视图查询结果立刻多出一列，但代码里没有任何提示——你根本不知道它变了。
下游如果按位置取值（比如 rs.getString(2)），或者 BI 工具靠列名自动映射，轻则数据错位，重则直接报错。
SQL Server 和 MySQL 对 * 的字段顺序解析逻辑不同，跨库迁移时同一张视图可能返回完全不同的列序。
SELECT * 在视图中必然触发列名冲突
两个表都有 id、name、created_at？SELECT * 会让数据库当场报错：Column 'id' is ambiguous。
必须显式加表别名前缀，比如 users.id AS user_id、orders.id AS order_id；
含空格或特殊字符的字段（如 [E-mail Address]）不加方括号会解析失败；
同语义字段（如 users.full_name 和 admins.display_name）若不统一别名，下游硬编码就容易绑定错。
视图 + SELECT * 让优化器“猜不透”你要什么
哪怕外层只查 id 和 title，视图里写了 SELECT *，数据库仍可能扫描所有列，尤其当基表有 TEXT/BLOB 字段时：
– 回表不可避免：覆盖索引失效，EXPLAIN 里 Extra 从 Using index 变成 Using where; Using index; Using temporary
– 单行物理大小暴涨，buffer pool 被大量无效数据占满
– max_allowed_packet 容易被突破，报错 Packets larger than max_allowed_packet are not allowed
工具链和 ORM 因 SELECT * 视图静默失效
MyBatis 的 resultMap、JPA 的 @Column、Power BI 的列推断，全都依赖稳定可预测的列名与顺序。
源表新增字段后：
– MyBatis 可能把新字段值错映射到老字段属性上
– Power BI 刷新时报 column not found 或类型错乱
– Java 应用用 ResultSet.getObject(i) 按索引取值，拿到完全无关的数据
最麻烦的是：这类问题往往不报错，只静默错位——查的时候看着都对，跑几天才暴露。
SELECT * 把结构不确定性放大了两层：一层是表变更，一层是视图定义。真正难处理的不是语法能不能过，而是它让“谁在用这个字段”“这个字段生命周期多长”“变更成本几何”全部变成盲区。
