SELECT * 让 ALTER TABLE 变成线上事故，因其在存储过程中不固化元数据，运行时动态解析表结构，导致新增/删除/重排序字段引发静默错位、运行时错误或隐性不一致；显式列名可实现编译时校验，切断结构变更传播链。
存储过程里 SELECT * 为什么会让 ALTER TABLE 变成线上事故
因为 MySQL 在创建存储过程时只固化执行逻辑，不固化字段元数据——SELECT * 是运行时才去查 information_schema.COLUMNS 拿当前列名、顺序和类型。一旦表结构变更，存储过程本身不报错、不失效，但结果集已悄然错位。
- 新增字段：存储过程照常执行，但返回多一列；下游用
rs.getString(2)这类按位置取值的代码，直接拿到新字段值，老逻辑崩了 - 删除字段：报错
Unknown column 'xxx' in field list，但堆栈可能指向调用它的另一个存储过程，根因难定位 - 字段重排序（如
ALTER TABLE ... MODIFY COLUMN xxx VARCHAR(255) FIRST）：列序一变，所有依赖位置的客户端全错乱，且无任何语法预警
视图 + 存储过程嵌套时，SELECT * 的错误会藏得更深
当存储过程查询一个用 SELECT * 定义的视图，等于两层动态解析叠加：底层表加字段 → 视图定义没更新 → 存储过程查该视图，结果集列数 ≠ 底层表列数，但不报错。这种静默不一致比直接报错更危险。
- 视图删字段后，存储过程调用失败，日志显示“调用
proc_name时字段不存在”，实际问题出在视图定义里，排查路径被拉长 - 字段类型变更（如
VARCHAR(50)→TEXT）：某些 JDBC 驱动可能截断或转换失败，但错误信息模糊，容易误判为网络或超时问题 - 两个表 JOIN 后用
SELECT *定义视图，出现重复列名（如users.id和orders.id），部分驱动只取第一个，下游静默丢数据
显式列名如何切断结构变更传播链
把 SELECT * 换成 SELECT id, name, email，本质是把“运行时契约”升级为“编译时契约”。MySQL 创建存储过程时就会校验这些字段是否存在、类型是否可赋值；缺失字段直接拒绝创建，不让你存下去。
-
ALTER TABLE DROP COLUMN email后，存储过程不会自动失效，但下一次调用前你必须手动修改——这反而成了强制重构的触发点 - 字段重命名？只要新名字没出现在你的显式列表里，存储过程完全不受影响；若要改，你得主动打开 SQL 编辑器，自然意识到业务含义变化
- ORM 映射（如 MyBatis 的
resultMap）依赖稳定列名，显式写法让字段生命周期可追踪，新增 NOT NULL 字段也不会意外抛SQLException
最容易被忽略的点：不是语法错，而是契约消失
真正麻烦的从来不是多敲几个字段名，而是 SELECT * 让人不再确认：这一查到底要什么字段、谁在消费、字段生命周期多长、变更成本几何。它掩盖的不是错误，是责任边界——当表结构动了，没人知道哪段存储过程该跟着动，也没人知道哪个下游系统正在靠列序活着。
