不能只在message表加is_read字段，因消息与用户是多对多关系，需独立message_read关联表，含复合主键、双外键（on delete cascade）、read_at字段及必要索引，否则无法支持分用户读状态、高并发更新及阅读轨迹分析。
消息已读状态不是加个 is_read 字段就能完事的——它天然涉及多对多关系、高频更新、查询性能敏感，且容易在 navicat 建模时被简化成单表字段，埋下扩展隐患。
为什么不能只在 message 表里加 is_read 字段
常见错误是把 message 表加上 is_read TINYINT(1)，再加个 read_at DATETIME NULL。这看似简单，但立刻会撞上三个硬伤：
- 无法支持“一条消息被多个用户分别读/未读”——即用户与消息是多对多关系，单字段只能表达全局状态；
- 每次用户点开消息都要
UPDATE message SET is_read = 1 WHERE id = ?，高并发下容易成为热点行锁瓶颈； - 无法记录谁在什么时候读了哪条消息，后续做未读数统计、已读回执、阅读轨迹分析全部落空。
真正合理的起点，是一个独立的 message_read 关联表。
Navicat 中建 physical model 的关键字段和约束
在 Navicat Data Modeler 新建物理模型（选 MySQL 或 PostgreSQL）后，添加以下实体和关系：
-
message表：主键id BIGINT UNSIGNED PK，必有created_at DATETIME； -
user表：主键id BIGINT UNSIGNED PK； -
message_read表：复合主键(user_id, message_id)，外键分别指向user.id和message.id； - 加字段
read_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP，避免 NULL 判断； - 建议加唯一索引
UNIQUE KEY uk_user_msg (user_id, message_id)（Navicat 自动生成复合主键索引，但显式声明更清晰）； - 如果需支持“标记为未读”，可加
status ENUM('read', 'unread') DEFAULT 'read'，但多数场景直接删记录更轻量。
用 Navicat 的外键连线工具拖拽建立关系，它会自动识别并生成 FOREIGN KEY 约束 —— 注意检查生成的 DDL 是否含 ON DELETE CASCADE（推荐启用，避免孤立记录）。
逆向工程已有表时容易漏掉的细节
如果你是从现有数据库逆向生成模型，Navicat 默认可能不加载外键元数据（尤其旧版或权限受限连接）。此时会出现：
-
message_read表显示为孤立表，无连线； - 字段名对得上，但
user_id/message_id没标为 FK； - 导出的 DDL 缺少
CONSTRAINT定义，同步到生产库时会丢失参照完整性。
解决方法：右键该表 → “编辑表” → 切换到“外键”标签页 → 手动添加两条外键规则，并确认“删除时”设为 CASCADE。Navicat 17+ 在“模型工作区”的比对视图中能高亮这类缺失约束，比老版本直观得多。
生成 SQL 和同步前必须验证的两点
Navicat 的“生成 SQL”功能默认输出完整建表语句，但两个地方极易出错：
-
message_read的引擎类型：MySQL 下务必确认是ENGINE=InnoDB（否则外键无效），Navicat 有时会漏写； - 时间字段默认值：PostgreSQL 要写
DEFAULT NOW()，MySQL 用CURRENT_TIMESTAMP，混用会导致同步失败； - 别忽略
message_read表的初始索引策略——Navicat 默认只建主键索引，但按user_id查未读列表（SELECT * FROM message_read WHERE user_id = ? AND read_at > ?）需要额外索引，得手动在“索引”标签页加。
真正麻烦的从来不是画出 ER 图，而是把那个看似简单的“已读”状态，从业务语义准确映射到物理结构、约束、索引和同步流程里——少一步，上线后就可能卡在慢查询或数据不一致上。
