存储过程禁用SELECT*，因其在执行时动态解析表结构，导致新增/删除/重命名字段或修改列序时引发静默错位、运行时错误或隐性不一致；改用显式列名可实现编译时校验，切断结构变更传播链。
存储过程里写 SELECT *，等于把表结构变更的爆炸引信直接焊死在代码里。
存储过程中 SELECT * 会因 ALTER TABLE 失效或静默错位
MySQL 存储过程在创建时会固化字段元数据（列名、类型、顺序），但 SELECT * 不参与固化——它只在每次执行时动态解析当前表结构。这意味着：
- 新增字段：存储过程仍能执行成功，但返回结果集多出一列，调用方若按位置取值（如
rs.getString(3)）会拿到错误字段 - 删除/重命名字段：存储过程报错
Unknown column 'xxx' in field list，但错误位置可能在嵌套调用深处，排查困难 -
ALTER TABLE ... MODIFY COLUMN xxx VARCHAR(255) FIRST：字段物理顺序改变，SELECT *返回列序随之变化，强依赖顺序的客户端直接错乱 - 视图 + 存储过程组合更危险：视图用
SELECT *创建后，底层表加字段不会自动同步到视图定义，而存储过程再查该视图，就出现“视图列数 ≠ 实际表列数”的隐性不一致
显式列名如何切断表结构变更的传播链
把 SELECT * 换成明确字段列表，本质是把“运行时契约”升级为“编译时契约”：
- 创建存储过程时，MySQL 就校验所列字段是否存在、类型是否可赋值，缺失字段直接报错，不让你存下去
- 后续
ALTER TABLE删除某个被引用字段时，存储过程不会自动失效，但下一次调用前你必须先手动修改它——这反而成了强制重构的触发点 - 字段重命名？只要新名字没出现在你的显式列表里，存储过程完全不受影响；若要改，你得主动打开 SQL 去编辑，自然意识到业务含义变化
- ORM 或应用层通过
CALL proc_name()获取结果集时，列名明确，映射安全；即使表里加了deleted_at TIMESTAMP，也不会意外覆盖已有对象属性
哪些场景下连“显式列名”都还不够
光写列名不能解决所有问题，尤其当字段语义或约束发生非结构化变更时：
- 字段类型从
VARCHAR(50)扩容到VARCHAR(255)：通常无害，但若应用层做了长度硬编码（如 Java 的substring(0,50)），依然会出错 -
ENUM('active','inactive')新增值'pending'：数据库不报错，但旧版应用可能因未识别枚举值而抛异常或默认 fallback - 字段加了
GENERATED ALWAYS AS表达式：显式列出该字段没问题，但要注意表达式依赖的源字段是否也被其他逻辑引用 - 分区表中字段用于
PARTITION BY LIST COLUMNS(...)：哪怕只查一个分区字段，也要确认该字段在存储过程中被显式引用且类型匹配，否则分区裁剪可能失效
最易被忽略的一点：存储过程里的 SELECT * 往往藏在嵌套子查询或临时表构造中，比如 CREATE TEMPORARY TABLE tmp AS SELECT * FROM users —— 这种写法会让临时表结构随原表漂移，后续所有基于 tmp 的操作都变成不可控状态。
