选对数据类型是避免后续问题的关键：用TINYINT存状态、DATETIME存时间、DECIMAL存金额、TEXT存不定长文本；Not Null和Auto Increment需按业务逻辑谨慎设置；设计后须通过插入测试、检查DDL、合理建索引验证合理性。
Navicat 里新建表时怎么选对数据类型
选错数据类型是后续出问题的根源——比如用 varchar(255) 存手机号，后期查不出结果；用 int 存带小数的价格，直接丢精度。navicat 界面看着直观，但字段类型背后有实际约束，不能只看“能输进去”。
-
TINYINT足够存状态（0/1）、性别（1/2）这类单字节值，别默认上INT； - 时间字段优先用
DATETIME（支持范围广、精度到秒），TIMESTAMP虽自动更新但受时区和 2038 年限制； - 金额类必须用
DECIMAL(M,D)，比如DECIMAL(10,2)表示最多 8 位整数 + 2 位小数，FLOAT或DOUBLE会累积浮点误差； - 文本内容不确定长度时，
TEXT比VARCHAR(65535)更稳妥，后者在行长度超限时可能被截断或报错。
Navicat 字段设置里哪些选项真有用
界面右侧一堆勾选项，不是全都要打。关键看业务逻辑是否依赖这些行为，而不是“看着安全就全选”。
-
Not Null：只有该字段绝不能为空才勾，比如主键、用户名；留空合法的字段（如备注）别硬加，否则插入失败； -
Auto Increment仅用于主键且类型为整型（TINYINT到BIGINT），其他字段加了也没用； -
Default填值时注意语法：字符串要加单引号（'pending'），数字不加（0），函数如NOW()不加引号； -
Unsigned只对数值型有意义，勾了就禁用负数，比如用户积分、库存数量适合用； -
Comment别空着，写清楚用途（如“用户最后一次登录时间戳”），比代码注释更持久。
Navicat 设计表后怎么验证字段是否合理
点“保存”不等于设计完成。很多问题要等真正插数据或连应用才暴露，得提前模拟边界场景。
- 用 Navicat 自带的
Query工具手动INSERT几条典型数据：超长字符串、负数、空值、带小数的金额，看是否报错或被截断； - 检查生成的建表 SQL（右键表 → “Quick DDL”），确认
ENGINE=InnoDB、CHARSET=utf8mb4是否存在，避免中文乱码或事务不生效； - 如果字段要建索引，别在设计界面随便勾“Index”，先想清楚查询条件——
WHERE user_id = ?才需要在user_id上建索引，ORDER BY create_time才考虑给时间字段加索引； - 留意 Navicat 默认把主键设为
PRIMARY KEY+AUTO_INCREMENT，但复合主键或 UUID 主键需手动删掉自增再调整。
Navicat 导出表结构时容易漏掉什么
导出 SQL 文件常用来做版本控制或迁移，但默认设置会丢关键细节。
- 导出前务必勾选
Export Options → Include Create Options，否则COMMENT、ENGINE、ROW_FORMAT全丢失； -
Export Options → Include Data按需选择，测试表可导，生产配置表慎导，避免误导入脏数据； - 导出的 SQL 里若含
CREATE TABLE ... SELECT，说明 Navicat 把数据当结构一起导了，这种语句不可复用，得手动改成纯 DDL； - 不同 Navicat 版本导出格式略有差异，特别是 MySQL 8.0+ 的隐藏字段（
INVISIBLE）或 JSON 类型，在旧版 Navicat 中可能无法识别或转成TEXT。
字段设计不是填完就完的事，它直接影响后续查询性能、数据一致性、甚至 ORM 映射是否出错。最常被跳过的一步是：没拿真实业务数据样本来试字段边界。比如用户昵称允许 emoji？订单号最长几位？这些不测，上线后改字段代价远大于一开始多花五分钟。
