直接INSERT存消息在高并发下会导致主键冲突、时间戳精度不足排序错乱、缺失会话关联字段，且无索引时查询性能骤降；必须建表时设计session_id、sender_id/receiver_id、created_at(DATETIME(6))三核心字段，并建对应联合索引。
为什么不能直接用 INSERT INTO chat_log 无脑存消息
直接每条消息都 INSERT 看似简单，但高并发下会迅速暴露问题：主键冲突（比如客户端重发）、时间戳精度不足导致排序错乱、缺失会话上下文关联字段。更麻烦的是，chat_log 表如果没加合适的索引，查某两个用户之间的全部对话会变慢得肉眼可见——不是几毫秒，是几百毫秒起步。
关键不是“能不能存”，而是“存完能不能稳准快地取回来”。所以必须从建表那一刻就考虑三个核心字段：session_id（标识一次完整对话）、sender_id/receiver_id（谁发给谁）、created_at（带微秒精度的 DATETIME(6)）。
实操建议：
- 用
UUID或服务端生成的bigint做session_id，别依赖前端传；前端传的容易伪造或重复 -
created_at必须用DATETIME(6)，MySQL 5.6.4+ 支持，避免同秒内多条消息顺序颠倒 - 联合索引至少要覆盖：
(session_id, created_at)和(sender_id, receiver_id, created_at)
怎么处理撤回、编辑、已读状态这类“消息元操作”
很多人把撤回当成“删掉记录”，这是错的。真实场景中，你得保留原始消息快照，只标记状态变更——否则审计、调试、数据对账全崩。MySQL 里最稳妥的做法是加一个 status 字段（TINYINT），值为 0（正常）、1（已撤回）、2（已编辑）、3（已读）。
注意：已读状态通常不和消息存在同一张表，因为读写频率差异太大。单独建 chat_read_status 表，字段至少含 session_id、user_id、last_read_seq（最后读到第几条），用 ON DUPLICATE KEY UPDATE 更新更安全。
常见错误现象：
- 用
DELETE FROM chat_log WHERE id = ?处理撤回 → 日志丢失，无法追溯 - 把已读时间存在
chat_log表里 → 每次用户点开聊天就全表更新，锁表风险高 - 用
TEXT存消息内容却不加CHARSET=utf8mb4→ 表情符号存成???
分页查历史记录时，LIMIT offset, size 为什么越往后越卡
当用户往上翻到第 100 页（offset=5000），MySQL 得先扫描前 5000 行再返回后 50 条，I/O 和 CPU 成倍涨。这不是代码问题，是 SQL 设计缺陷。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
正确做法是“游标分页”（cursor-based pagination）：用上一页最后一条的 created_at 和 id 作为条件，例如：
SELECT * FROM chat_log WHERE session_id = ? AND (created_at, id) < (?, ?) ORDER BY created_at DESC, id DESC LIMIT 50;
前提是 (created_at, id) 有联合索引，且 id 是主键（自增或唯一）。这样每次都是范围查询，性能稳定在毫秒级。
额外提醒：
- 别用
SELECT *查历史，只选必要字段（如content、sender_id、created_at） - 客户端传来的
session_id必须做白名单校验或权限检查，否则可能越权读别人聊天 - 如果单条消息超 1MB（比如传了大图 base64），别硬塞进 MySQL，存对象存储 URL + 元数据
MySQL 主从延迟导致“刚发的消息查不到”怎么破
读写分离架构下，用户发完消息立刻去从库查，大概率查不到——因为主从同步有几十到几百毫秒延迟。这不是 bug，是 MySQL 复制机制决定的。
解决方案不是关掉从库，而是分场景路由：
- 用户自己刚发送的消息，强制走主库查（加
/*FORCE_MASTER*/注释或用中间件标记） - 查别人发来的消息、历史归档类请求，才走从库
- 对一致性要求极高的操作（如撤回、已读确认），所有读写都走主库
如果你用的是 ProxySQL 或 ShardingSphere，这些路由策略能配死；如果直连，就得在 DAO 层手动控制连接源。别指望应用层加 SLEEP(100) 等同步——既不准又伤性能。
最容易被忽略的一点：哪怕用了游标分页，如果上一页最后一条消息是在主从延迟窗口内写入的，从库查出来的“最后 created_at”可能是旧值，导致漏数据。所以游标字段必须包含主键 id，它不受时间精度和同步延迟影响。
