用 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），适合记录“计划时间”（如会议开始时间、合同到期日）。
典型陷阱：在跨时区服务中用
DATETIME存“用户提交时间”，结果各地区查出来都是本地时间，无法对齐；反过来，用
TIMESTAMP存“系统预定维护时间”，结果因服务器时区变更导致时间漂移。 通用建议：所有“发生时间”用
TIMESTAMP，所有“人为指定时间点”用
DATETIMEMySQL 5.6.5+ 支持
DATETIME默认值和自动更新（如
created_at DATETIME DEFAULT CURRENT_TIMESTAMP），不必强求
TIMESTAMP注意
TIMESTAMP在严格模式下插入 NULL 会转为当前时间，而
DATETIME会真存 NULL
数值类型别乱用 DECIMAL
，整数场景优先 BIGINT
钱、精度敏感值（如金融余额、利率）必须用
DECIMAL(M,D)，M 是总位数，D 是小数位数，例如
DECIMAL(15,2)表示最多 13 位整数 + 2 位小数；但普通计数（如浏览量、点赞数）、ID、状态码等，一律用整型：
INT UNSIGNED（0~42亿）或
BIGINT UNSIGNED（0~1.8×10¹⁹）。
滥用
DECIMAL的代价：存储空间更大（按字符串方式编码）、计算比整型慢、某些 ORM 会映射为浮点数引发精度丢失。曾见把用户 ID 设为
DECIMAL(20,0)，结果 PHP 的
json_encode()把它转成科学计数法字符串，前端解析失败。 ID 类字段：优先
BIGINT UNSIGNED AUTO_INCREMENT，避免未来扩容麻烦 需要带符号的计数（如积分增减），用
BIGINT（有符号），别用
DECIMAL
DECIMAL的 M/D 设置要留余量，比如商品价格最高 9999.99，至少定义
DECIMAL(10,2)，别卡死
DECIMAL(6,2)实际字段设计最耗神的地方不在类型本身，而在**边界判断是否和业务演进同步**——今天用
VARCHAR(32)存手机号，明天要支持国际号码就得改；今天
TINYINT表示状态，后天加个新状态就溢出。留余量不是拍脑袋，是看历史增长曲线和产品路线图。
