数据表是数据库中具有强类型约束的真实逻辑容器，字段类型须按业务用途精准选择：手机号等用VARCHAR/CHAR防截断，金额必用DECIMAL，状态用TINYINT(1) UNSIGNED，时间按需求选DATETIME或TIMESTAMP，昵称优先VARCHAR，非空字段应显式定义NOT NULL与默认值。
数据表就是数据库里的“电子表格”
它不是抽象概念，而是真实存在的逻辑容器：每张表对应一个 CREATE TABLE 语句，有名字、有行（记录）、有列（字段），就像 Excel 里一个 sheet。但关键区别在于——表的结构是强约束的，每一列必须提前声明类型，插入时类型不符会直接报错（比如往 TINYINT 列插字符串 'abc'），而不是默默转成 0 或 NULL。
字段类型选错，轻则浪费空间，重则丢精度甚至出错
MySQL 不是“能存就行”，字段类型直接影响存储效率、查询性能和业务正确性。常见踩坑点：
-
INT(11)的11不是长度限制，只是显示宽度（且 MySQL 8.0.17+ 已弃用），INT无论写成INT(1)还是INT(20)都占 4 字节、范围都是 -2147483648～2147483647 - 存手机号、身份证号、门牌号？别用
INT或BIGINT——它们会自动截断前导 0（如012345变成12345），也做不了模糊查询（比如“查所有以 138 开头的号码”）。该用VARCHAR(11)或CHAR(18) - 金额字段用
FLOAT或DOUBLE？危险！FLOAT(10,2)存9999999.99可能变成10000000.00。必须用DECIMAL(15,2)，它按十进制精确存储，不丢失分位 - 状态、开关、是否启用这类只有 0/1 的字段，优先用
TINYINT(1) UNSIGNED，不是BOOLEAN（MySQL 里BOOLEAN是TINYINT(1)的别名，但语义不清晰）
结构设计要从“值怎么用”倒推，而不是从“看起来像什么”出发
比如一个叫 created_at 的字段：
- 如果只是记录插入时间，且不需要时区转换，用
DATETIME（范围大、无时区干扰） - 如果要自动更新、依赖服务器时区、或需配合
ON UPDATE CURRENT_TIMESTAMP，才考虑TIMESTAMP（但注意：它只能存 1970–2038 年间的时间） - 如果字段实际只存年份（如出生年），别用
YEAR类型——它太冷门、ORM 支持差、且无法做日期运算；老老实实用SMALLINT UNSIGNED或CHAR(4)
再比如用户昵称：VARCHAR(32) 比 CHAR(32) 更合适，因为昵称长度差异大，CHAR 会补空格浪费空间，且在严格模式下可能被截断。
建表时加 NOT NULL 和默认值不是“可选项”，而是明确业务意图
很多团队习惯给所有字段加 DEFAULT NULL，结果导致大量 NULL 值混杂，后续 WHERE status = 1 查不到 status IS NULL 的记录，还得额外写 OR status IS NULL。更稳妥的做法：
- 业务上“一定有值”的字段（如
user_id,amount），强制NOT NULL - 允许为空但有合理默认的（如新用户初始积分），设
DEFAULT 0 - 真正意义不明、后期才填充的（如用户头像 URL），才保留
NULL，并确保应用层能区分“未设置”和“设为空字符串”
字段类型不是填空题，是设计契约。一个 TINYINT UNSIGNED 字段，等于向所有人声明：“这个值永远在 0–255 之间，超了就是 bug”。
