最可靠方式是查询information_schema.columns系统表，需指定table_schema、table_name和column_name；返回count(*)>0结果判断存在与否，注意大小写、权限及跨库误判风险。
直接查 information_schema.COLUMNS 最可靠
MySQL 没有内置的 IF EXISTS 语法来判断字段是否存在，最稳妥的方式就是查系统表 information_schema.COLUMNS。它记录了所有库、表、列的元信息，只要能查到对应记录，就说明字段存在。
注意：必须指定正确的 TABLE_SCHEMA（数据库名）和 TABLE_NAME（表名），否则可能跨库误判。
常用写法：
SELECT COUNT(*) > 0 AS exists_flag FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'your_table_name' AND COLUMN_NAME = 'your_column_name';
返回 1 表示存在，0 表示不存在。用 COUNT(*) > 0 比 SELECT 1 LIMIT 1 更明确，避免空结果集带来的逻辑歧义。
在存储过程或动态 SQL 中判断字段是否存在
如果要在存储过程中做条件逻辑（比如“存在则更新，不存在则跳过”），不能直接用 IF EXISTS (SELECT ...)，因为 MySQL 不支持这种语法。得先查、再赋值、再判断。
实操要点：
- 用
SELECT INTO把查询结果存入变量，例如：SELECT COUNT(*) INTO @col_exists FROM information_schema.COLUMNS WHERE ... - 之后用
IF @col_exists > 0 THEN ... END IF;控制流程 - 务必加
WHERE TABLE_SCHEMA = DATABASE()或显式指定库名，避免在多库环境下出错 - 注意权限：用户需有对
information_schema的SELECT权限，某些低权限账号可能被限制访问
DESCRIBE 和 SHOW COLUMNS 能不能替代？
可以快速查看字段列表，但不适合自动化判断——它们是语句，不是可查询的数据源，没法直接用于条件分支。
比如执行 DESCRIBE your_table，结果是结果集，不能被 IF 或变量捕获；想用它判断，还得额外套一层查询或客户端解析，反而更重。
另外要注意：
-
SHOW COLUMNS FROM tbl默认只查当前库，不指定库名时容易在跨库操作中误判 - 两者都不返回字段所属的
TABLE_SCHEMA，无法区分同名表在不同库中的字段 - 在高并发 DDL 场景下，
DESCRIBE可能触发表元数据锁，而查information_schema.COLUMNS是只读且轻量的
常见错误：字段名大小写、引号、特殊字符处理
MySQL 在 Linux 下默认区分表名和字段名的大小写（取决于 lower_case_table_names 配置），但 information_schema.COLUMNS.COLUMN_NAME 存储的是定义时的原始大小写。如果你建表时写了 MyColumn，那查的时候也得写 'MyColumn'，写成 'mycolumn' 就查不到。
其他易踩坑点：
- 字段名含反引号或特殊字符（如空格、短横线）时，
COLUMN_NAME字段里存的是未转义的原始名，不要在 WHERE 条件里加反引号 - 使用参数化方式拼接 SQL（如在应用层）时，确保
COLUMN_NAME值已去除首尾空格，避免因建表语句里多写了空格导致匹配失败 - MySQL 8.0+ 引入了角色权限模型，
information_schema查询可能受TABLES_ADMIN或SELECT_CATALOG_ROLE影响，测试环境 OK 不代表生产也 OK
真正麻烦的不是查不到，而是查到了但字段其实在另一个库的同名表里——所以每次查，TABLE_SCHEMA 这一条件别省。
