数据表就是数据库里的“电子表格”
它不是抽象概念，而是真实存在的逻辑容器：每张表对应一个
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”。
