“字段”和“列”在MySQL中完全等价，仅语境偏好不同；ALTER TABLE用COLUMN是SQL标准语法；字段类型选错会导致数据异常，如TINYINT未加UNSIGNED、VARCHAR滥用、FLOAT存金额；生成列分VIRTUAL与STORED，后者才可索引。
在 MySQL 中，“字段”和“列”**没有实质区别，可以完全互换使用**——它们指的都是表结构中垂直方向上的一个数据单元，比如 id、username、created_at 这些名字所代表的那“一竖”。所谓“字段”更偏向逻辑/应用层描述（比如 ORM 里常说“映射字段”），而“列”更偏向 SQL 语法和存储层表述（如 SELECT name FROM user 中的 name 就是一列），但二者在 MySQL 的 DDL/DML 语境下完全等价。
为什么 ALTER TABLE 里写的是 COLUMN 而不是 FIELD？
因为 SQL 标准语法规定：修改结构的操作（ADD COLUMN、DROP COLUMN、MODIFY COLUMN）统一用 COLUMN 关键字。MySQL 不支持 ADD FIELD 这种写法——这不是设计差异，而是语法约定。你写 ALTER TABLE t ADD b INT 看似省略了 COLUMN，其实是 MySQL 允许的简写，底层仍按列处理。
-
ADD COLUMN是显式、标准、推荐写法；ADD是隐式简写，但易引发歧义（比如加索引时也用ADD） - 文档、错误提示、权限系统（如
SELECT权限粒度）全以COLUMN为单位，不存在FIELD权限或关键字 -
工具链（如 mysqldump、Navicat、SQLyog）导出的建表语句一律用
COLUMN
字段类型选错的三个典型翻车现场
类型不是随便填的，选错直接影响数据完整性、查询性能甚至迁移成本。常见踩坑点：
-
TINYINT存状态却没加UNSIGNED：本想存 0/1/2，结果插入 3 报错——TINYINT默认有符号，范围是 -128~127；要存非负小整数，必须写TINYINT UNSIGNED（范围 0~255） -
VARCHAR(255)到处滥用：字符集是 utf8mb4 时，VARCHAR(255)最大占 1020 字节（255×4），可能触发内部临时表降级为磁盘表；真实业务中，用户名通常VARCHAR(32)足够，邮箱VARCHAR(254)即可（RFC 5321 限制） -
FLOAT存金额：比如price FLOAT(10,2)插入99.99，查出来可能是99.98999786376953——浮点数精度丢失不可控；必须用DECIMAL(10,2)，它按字符串方式精确存储
计算字段（Generated Column）和普通字段的本质区别
计算字段（也叫生成列）看起来像字段，但它**不占用物理存储空间（除非标记为 STORED）**，值是实时计算出来的。例如：
ALTER TABLE user ADD COLUMN full_name VARCHAR(100) GENERATED ALWAYS AS (CONCAT(first_name, ' ', last_name)) STORED;
注意关键点：
- 没加
STORED就是VIRTUAL（默认），每次SELECT都重新执行CONCAT，无法建索引；加了STORED才真正落盘、可索引、可被外键引用 - 计算字段不能直接
INSERT或UPDATE，否则报错ERROR 3105 (HY000): The value specified for generated column is not allowed. - 函数必须是确定性的（
NOW()、RAND()等非确定函数禁止使用），否则建表失败
真正容易被忽略的是：当你用 SHOW CREATE TABLE 查看表结构时，生成列会明确标出 GENERATED ALWAYS AS (...) STORED，但它在 DESCRIBE table 输出里和普通列长得一模一样——仅靠 DESCRIBE 无法分辨，必须看建表语句或查询 information_schema.COLUMNS 表里的 GENERATION_EXPRESSION 字段。
