存储过程禁用select*，因其执行时动态解析表结构，新增/删除/重命名字段或修改列序会导致静默错位、运行时错误或隐性不一致；改用显式列名可实现编译时校验，切断结构变更传播链。
存储过程里 SELECT * 会因 ALTER TABLE 失效或静默错位
MySQL 存储过程在创建时会固化字段元数据（列名、类型、顺序），但 SELECT * 不参与固化——它只在每次执行时动态解析当前表结构。这意味着：
- 新增字段：
SELECT *仍能执行成功，但返回结果集多出一列；若应用层用rs.getString(3)这类按位置取值，直接拿到错误字段 - 删除/重命名字段：报错
Unknown column 'xxx' in field list，但错误可能出现在嵌套调用深处，堆栈指向不明 -
ALTER TABLE MODIFY COLUMN xxx VARCHAR(255) FIRST：字段物理顺序改变，SELECT *返回列序随之变化，强依赖顺序的客户端逻辑立即错乱
视图 + 存储过程组合会让问题更隐蔽
当存储过程查询一个用 SELECT * 定义的视图时，两层动态解析叠加：
- 底层表加字段 → 视图定义不更新 → 存储过程查该视图，结果集列数 ≠ 底层表列数，但不报错
- 视图删字段 → 存储过程调用失败，错误日志显示“调用 proc_name 时字段不存在”，实际根因在视图定义里
- 字段类型变更（如
VARCHAR(50) → TEXT）→ 某些 JDBC 驱动可能截断或转换失败，且无明确提示
显式列名能切断结构变更传播链
把 SELECT * 换成 SELECT id, name, email，本质是把“运行时契约”升级为“编译时契约”：
- 创建存储过程时，MySQL 就校验所列字段是否存在、类型是否可赋值；缺失字段直接报错，不让你存下去
- 后续
ALTER TABLE DROP COLUMN email后，存储过程不会自动失效，但下一次调用前你必须手动修改——这反而成了强制重构的触发点 - 字段重命名？只要新名字没出现在你的显式列表里，存储过程完全不受影响；若要改，你得主动打开 SQL 编辑，自然意识到业务含义变化
ORM 或应用层按列名映射时，* 会放大错配风险
很多 ORM（如 MyBatis、SQLAlchemy）默认按列名绑定属性，但前提是列名稳定且唯一：
- 两个表 JOIN 后用
SELECT *，出现重复列名（如users.id和orders.id），部分驱动只取第一个，静默丢数据 - 表里新增
deleted_at TIMESTAMP，ORM 自动映射到对象属性，可能覆盖已有字段或引发NullPointerException - MyBatis 的
resultMap若未显式声明字段，新增NOT NULL字段没默认值时直接抛SQLException
真正难处理的不是语法本身，而是 SELECT * 让人不再确认：这一查到底要什么字段、谁在消费、字段生命周期是否可控、变更成本有没有被评估过。
