mysql建表必须指定字段类型和NULL约束，推荐engine=innodb、charset=utf8mb4，并添加表与字段comment；时间字段优先用datetime而非timestamp。
CREATE table 语句必须指定字段类型和非空约束
MySQL 不允许创建没有任何列的表，也不接受未声明数据类型的字段。最基础的建表命令至少要包含字段名、类型，以及明确的 NOT NULL 或 NULL 约束。
常见错误是直接写 CREATE TABLE t1 (id, name); —— 这会报错 Error 1171 (42000): All parts of a PRIMARY KEY must be NOT NULL 或更早的语法错误，因为 MySQL 要求每个字段都带类型。
-
int、VARCHAR(255)、TEXT、DATETIME是高频类型，注意VARCHAR必须带长度，TEXT不支持默认值（除非是 MySQL 8.0.13+ 且用default ''） - 主键推荐显式声明：
id INT PRIMARY KEY AUTO_INCREMENT，不依赖隐式规则 - 字符集建议统一设为
utf8mb4，避免 emoji 或生僻字存不进去：CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
ENGINE=InnoDB 是默认且推荐的存储引擎
MySQL 5.5+ 默认引擎已是 InnoDB，它支持事务、行锁、外键，而 MyISAM 只有表锁、不支持事务，现在基本只用于归档或只读场景。
建表时不显式指定 ENGINE，可能在某些旧配置或从库上回退到 MyISAM，导致后续加外键失败或并发更新异常。
- 务必写明：
ENGINE=InnoDB - 如果需要全文索引且用的是 MySQL 5.6+，
InnoDB已支持，无需切引擎 -
MEMORY引擎仅适合临时中间表，重启即丢数据，别误用在持久表上
添加注释让表和字段可维护性提升明显
很多团队上线后才发现不知道某个 status 字段是 0/1 还是枚举字符串，或者 ext_data 到底存 json 还是序列化数组——这些信息本该在建表时就固化。
- 表注释用
COMMENT '用户基本信息表' - 字段注释加在字段定义末尾：
nick_name VARCHAR(64) COMMENT '用户昵称，脱敏展示用' - 注释内容会被
SHOW CREATE TABLE和文档生成工具识别，但不会出现在DESCRIBE输出里
时间字段优先用 DATETIME 而非 TIMESTAMP
TIMESTAMP 表面看省空间（4 字节 vs DATETIME 的 5–8 字节），但它有隐藏陷阱：自动时区转换、2038 年溢出、不能设默认值为函数（如 NOW()）在部分老版本中受限。
- 统一用
DATETIME DEFAULT CURRENT_TIMESTAMP或DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 如果业务严格要求 UTC 存储且需自动转换，再考虑
TIMESTAMP，但得确认所有连接层没做本地时区覆盖 -
DATE和TIME类型只在纯日期或纯时间场景下使用，别为了“省字节”强行拆分DATETIME
实际建表时最容易被跳过的，是字符集、引擎、注释这三项——它们不报错，但半年后查问题或交接时，代价远高于敲几个单词的时间。