优先用VARCHAR(n)（n=实际最大长度+10%余量），超255字符且不常查询的字段选TEXT；布尔用TINYINT UNSIGNED或ENUM；时间按“发生”选TIMESTAMP、“指定”选DATETIME；整数计数用BIGINT，金额用DECIMAL(M,D)。
用 VARCHAR 还是 TEXT？看长度和索引需求
超过 255 字符且不常用于 WHERE 或 ORDER BY 的字段（如文章正文、日志内容），优先选 TEXT；否则统一用 VARCHAR(n)，n 取业务实际最大长度 + 10% 余量。MySQL 8.0+ 中 VARCHAR(65535) 理论上限受行总长限制（65535 字节），但实际受字符集影响：utf8mb4 下一个字符占 4 字节，所以最多约 16383 个字符。
常见错误：把用户昵称设成 TEXT —— 导致无法直接建普通索引（需指定前缀长度），也增加排序/分组开销；反过来，把固定长度的编码（如身份证号、订单号）设成 VARCHAR(255) 浪费存储和比较成本。
-
VARCHAR存储时保留实际长度，适合长度波动大、常参与查询的字段 -
TEXT不计入行内存储（InnoDB 存单独页），不能有默认值（除非 MySQL 5.7+ 且显式指定NOT NULL DEFAULT ''） - 需要全文检索？必须用
TEXT+FULLTEXT索引，VARCHAR不支持
TINYINT(1) 不等于布尔值，BOOLEAN 只是别名
MySQL 没有原生布尔类型，BOOLEAN 和 BOOL 都被自动转为 TINYINT(1)，存的是数字 0/1，不是 true/false 字面量。ORM（如 Django、Laravel）可能自动转换，但直连 MySQL 时写 WHERE status = TRUE 实际等价于 WHERE status = 1，语义易误导。
更严重的问题是 TINYINT(1) 的显示宽度（1）毫无意义——它不影响取值范围（仍是 -128~127 或 0~255），也不限制输入值，INSERT INTO t VALUES (999) 会静默截断为 255（开启严格模式才报错）。
- 表示开关状态，用
TINYINT UNSIGNED（0~255），明确业务含义（如 0=待处理, 1=成功, 2=失败） - 避免用
TINYINT(1)声称“存布尔”，代码里还得额外注释含义 - 如果只用 0/1 且绝不会扩展，
ENUM('false','true')更自文档化，但注意 ENUM 是字符串比较，性能略低
时间字段选 DATETIME 还是 TIMESTAMP？关键看时区和范围
TIMESTAMP 自动转为 UTC 存储、读取时转回当前会话时区，范围小（1970–2038），适合记录“事件发生时间”（如创建时间、更新时间）；DATETIME 按字面值存储，不涉及时区转换，范围大（1000–9999），适合记录“计划时间”（如会议开始时间、合同到期日）。
