选合适数据库字段类型可省空间、提性能、防出错：整数用TINYINT/SMALLINT/MEDIUMINT；布尔用TINYINT(1)；字符串按需选VARCHAR(N)而非TEXT；时间用DATETIME；慎用JSON，优先结构化设计。
数据库字段类型选得合适，能省空间、提性能、防出错。PHP 本身不决定字段类型，但应用层的设计和操作会直接影响你对 MySQL（或其他数据库）字段类型的选用是否合理。
用最小够用的整数类型
比如用户 ID、状态码、分类编号这类字段，别一上来就用 INT(11)。MySQL 中 TINYINT（1 字节，范围 -128~127 或 0~255）足够存“性别”“启用状态（0/1）”；SMALLINT（2 字节）适合订单类型、年级等；MEDIUMINT（3 字节）可覆盖大多数业务编号场景。用小类型不仅节省磁盘和内存，索引也更紧凑，JOIN 和排序更快。
- 布尔型状态优先用 TINYINT(1)（不是 BOOL，后者只是别名），避免用 VARCHAR('yes'/'no') 或 TEXT
- 自增主键若确定总量不超过 6.5 万，可用 SMALLINT UNSIGNED；超千万再考虑 INT 或 BIGINT
- PHP 中读取后保持类型一致：用 mysqli_fetch_assoc() 或 PDO 的 PDO::ATTR_EMULATE_PREPARES = false，避免数字被转成字符串
字符串字段按实际长度选，慎用 TEXT
姓名、手机号、邮箱、标题等都有明确长度上限。用 VARCHAR(N) 比 TEXT 更高效——前者存在行内，可建索引、支持前缀索引、查询快；后者单独存储，无法直接参与排序或 GROUP BY，且 InnoDB 对 TEXT 的二级索引会额外增加回表开销。
- 手机号统一 11 位（国内），用 VARCHAR(11) 或 CHAR(11)（定长更优）
- 邮箱建议 VARCHAR(254)（遵循 RFC 标准最大长度）
- 短描述（如标签、SKU 编码）控制在 32~64，别盲目设 VARCHAR(255)
- 只有真正可能超 65535 字节的内容（如文章正文、日志详情）才用 MEDIUMTEXT
时间字段优先用 DATETIME 或 TIMESTAMP
PHP 常用 date('Y-m-d H:i:s') 写时间，对应数据库应选 DATETIME（推荐）或 TIMESTAMP。前者范围大（1001–9999 年）、时区无关、语义清晰；后者占 4 字节更省空间，但范围窄（1970–2038）、受时区影响，且 MySQL 5.6+ 后两者默认行为已趋同，一般无强理由选 TIMESTAMP。
立即学习“PHP免费学习笔记（深入）”；
- 创建时间、更新时间字段用 DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
- 避免用 INT 存时间戳（如
time()返回值）：PHP 处理方便，但丧失数据库原生时间函数能力（如DATE_ADD、YEAR()），也难读、难索引 - PDO 插入时可直接绑定 PHP DateTime 对象，驱动自动转换（需开启 ATTR_EMULATE_PREPARES = false）
避免 JSON 字段滥用，结构化优先
MySQL 5.7+ 支持 JSON 类型并可建虚拟列索引，但仅适合真正动态、不可预知结构的场景（如用户自定义表单字段）。多数情况下，把“配置项”“多选项”“地址字段”硬塞进 JSON，会导致查询难写、索引失效、校验缺失、迁移痛苦。
- 收货地址拆成 province、city、detail 等独立 VARCHAR 字段，便于搜索和统计
- 多选标签可用关联表（
user_tags），比 JSON 数组更符合范式、易维护 - 确需 JSON，至少加 CHECK 约束保证格式（如
JSON_VALID(content)），并在 PHP 层做严格序列化/反序列化校验
