SQL字段类型设计应遵循“够用且最小”原则，优先选最窄整数、合理用CHAR/VARCHAR、禁用字符串存时间金额、慎用NULL与TEXT。
SQL字段类型设计的核心是“够用且最小”，不是越大越好，也不是越通用越安全。选对类型能减少磁盘占用、降低内存开销、加快索引扫描、避免隐式转换，甚至影响查询计划是否走索引。
按实际业务范围选最窄的整数类型
比如用户状态只有 0（禁用）、1（启用）、2（待审核），用 TINYINT UNSIGNED（0~255，占1字节）就足够，没必要用 INT（4字节）。订单号如果全是纯数字且不超过 21 亿，优先考虑 INT UNSIGNED；若确定永远 ≤65535，直接上 SMALLINT UNSIGNED（2字节）。MySQL 中带 UNSIGNED 的整数类型能多存一倍正数，且避免负值误入。
- 布尔类字段：用 TINYINT(1)（不是 BOOL/BOOLEAN，它们只是别名），值只存 0/1
- 枚举固定值（如性别、订单类型）：可考虑 ENUM('male','female')，比 VARCHAR 更省空间且自带约束，但修改需 ALTER TABLE，慎用于可能频繁扩展的场景
- 避免滥用 BIGINT：仅当主键预计超 21 亿、或需要跨分库全局唯一 ID 时才用
字符串类型宁短勿长，优先 CHAR 或 VARCHAR 而非 TEXT
手机号、身份证号、编码类字段长度固定，用 CHAR 更高效（如 CHAR(11) 存手机号）；名称、描述等变长内容用 VARCHAR(N)，N 设为业务允许的最大长度，不要盲目设成 255 或 1000。超过 255 字符且不参与 WHERE/ORDER BY/GROUP BY 的字段（如文章正文），才考虑 TEXT；否则 VARCHAR 更快——因为 TEXT 是离行存储，每次读取要额外 IO。
- 邮箱字段：VARCHAR(254) 足够（RFC 标准上限），别用 VARCHAR(500)
- 中文姓名：VARCHAR(20) 通常够用（含复姓+双名+空格），不用 VARCHAR(100)
- 避免用 TEXT 做索引字段：MySQL 5.7+ 支持前缀索引，但全文检索才真正需要 TEXT + FULLTEXT 索引
时间与数值类型拒绝“字符串存储”陷阱
用 DATETIME 或 TIMESTAMP 存时间，别用 VARCHAR('2024-03-15 14:23:00')。前者支持日期函数、范围查询、索引高效；后者无法直接比较大小，WHERE date > '2024-01-01' 可能全表扫，还容易因格式不一致出错。同理，金额必须用 DECIMAL(M,D)（如 DECIMAL(12,2)），不能用 FLOAT/DOUBLE（精度丢失）或 VARCHAR（无法计算、排序错乱）。
- TIMESTAMP 占 4 字节，DATETIME 占 8 字节，但 TIMESTAMP 有范围限制（1970–2038）且自动时区转换，高并发日志类场景可选 DATETIME
- 价格字段 DECIMAL(10,2) 表示最多 8 位整数 + 2 位小数，够覆盖千万级金额，别写成 DECIMAL(20,6)
- JSON 数据量小且结构稳定时，可用 JSON 类型（MySQL 5.7+），它支持校验和部分索引；否则拆成关系字段更可控
合理使用 NULL 和默认值，减少空值判断开销
字段明确不会为空，就加 NOT NULL。NULL 在 B+ 树索引中单独存放，增加索引体积；COUNT(col) 会跳过 NULL，而 COUNT(*) 不会，易引发逻辑错误；更多 NULL 值也会让优化器难以准确估算行数，影响执行计划。对于“未知”“不适用”等语义，可用特殊值替代（如时间字段用 '0000-00-00 00:00:00' 或预留一个业务标识码），前提是应用层统一处理。
- 主键、外键、索引列尽量 NOT NULL
- 字符串默认值用 ''（空字符串）比 NULL 更直观，也避免 ORM 映射歧义
- 数值字段默认值设为 0，而非 NULL，除非“无值”本身有独立业务含义
