MySQL表结构本质是字段定义集合，其元数据实时存储于INFORMATION_SCHEMA.COLUMNS中，含字段名、DATA_TYPE、IS_NULLABLE、COLUMN_DEFAULT、EXTRA等关键属性。
MySQL里一张表到底包含哪些字段信息
表的结构本质就是字段定义的集合，DESCRIBE table_name 或 SHOW COLUMNS FROM table_name 能直接看到字段名、类型、是否允许 NULL、键类型、默认值和额外属性。这些信息全存在 INFORMATION_SCHEMA.COLUMNS 系统表里，不是元数据缓存，每次查都是实时读取。
-
DATA_TYPE是实际类型（如varchar、int），不带长度或修饰符；想看完整声明得查COLUMN_TYPE -
IS_NULLABLE值是YES或NO，不是布尔值，别用= 1判断 -
COLUMN_DEFAULT对于没有显式 DEFAULT 的字段返回NULL，但NOT NULL字段没设 DEFAULT 时，插入不给值会报错，这点容易误以为“默认就是 NULL” -
EXTRA里出现auto_increment表示自增，on update CURRENT_TIMESTAMP这类行为不会出现在这里，得看COLUMN_DEFAULT或建表语句
如何安全地查看字段和索引的对应关系
字段本身不“属于”某个索引，索引是独立对象，只是引用一个或多个字段。要确认某字段是否被某个索引使用，必须联查 INFORMATION_SCHEMA.STATISTICS 和 COLUMNS。
-
STATISTICS表中COLUMN_NAME是字段名，INDEX_NAME是索引名，SEQ_IN_INDEX表示该字段在联合索引里的顺序 - 主键索引名固定为
PRIMARY，唯一索引名由用户指定或自动生成（如uk_email），普通索引名也一样 - 注意
NON_UNIQUE字段：0 表示唯一索引（含主键），1 表示非唯一索引 - 执行
SHOW CREATE TABLE t最直观，但输出是 DDL 字符串，解析起来麻烦；自动化场景优先走系统表联查
修改字段时为什么有时会锁表，有时不会
从 MySQL 5.6 开始支持部分 ALTER TABLE 操作的 Online DDL，但是否真正“不锁表”，取决于操作类型、存储引擎和 MySQL 版本。InnoDB 是主力，重点看它。
- 仅修改
COMMENT或DEFAULT值（ALTER COLUMN ... SET DEFAULT）通常不锁表 - 改字段类型（如
VARCHAR(255)→VARCHAR(500)）在多数情况下可 Online，但若涉及字符集转换或精度扩大（如INT→BIGINT）可能触发表拷贝 - 加
NOT NULL约束且字段有 NULL 值时，必然全表扫描+更新，会锁表；加NOT NULL且当前全为非 NULL 值，才可能避免拷贝 -
ALGORITHM=INPLACE不等于“完全不锁”，它只表示不重建表，但仍可能在某些阶段拿 MDL 写锁，阻塞 DML
字段名大小写敏感问题在哪生效
字段名在 SQL 语句中**始终不区分大小写**，无论操作系统或配置如何。真正影响大小写的，是标识符引用方式和系统变量 lower_case_table_names ——但它只管表名、数据库名，不管字段名。
- 写
SELECT id, Name FROM user和SELECT ID, name FROM USER效果完全一样 - 只有用反引号包裹时，MySQL 才按字面量处理：
`Name`和`name`在同一个表里是两个不同字段（虽然语法允许，但强烈不建议） - 常见困惑来源：应用层 ORM 可能对字段做首字母大写映射（如 Java Bean），但这和 MySQL 无关；出问题往往是程序拼 SQL 时大小写不一致导致字段未识别，而非数据库报错
- 跨平台迁移时，如果旧库用了混合大小写的字段名又加了反引号，新环境没注意初始化配置，可能导致查询失败——这种坑不在字段定义本身，而在引用习惯
字段结构看着简单，但每个字段背后连着类型规则、索引逻辑、变更成本和引用一致性。动表之前，先看 SHOW CREATE TABLE 和 SELECT * FROM INFORMATION_SCHEMA.COLUMNS，比凭经验猜更可靠。
