应使用 TIMESTAMP 类型并建立 (user_id, is_read, created_at) 复合索引支撑高并发未读消息查询，避免单列索引失效、全表扫描及时区不一致问题。
用 TIMESTAMP + 复合索引支撑高并发消息查询
用户拉取“最新未读消息”是高频操作，created_at 和 is_read 必须联合走索引，否则分页一卡就是几秒。别只给 created_at 加单列索引——MySQL 优化器在 WHERE is_read = 0 ORDER BY created_at DESC 场景下大概率不走索引。
- 建表时直接加复合索引：
ALTER TABLE notification ADD INDEX idx_user_read_time (user_id, is_read, created_at) -
user_id必须放最左，因为所有查询都带接收者 ID；is_read放第二位，能快速过滤未读；created_at放最后，满足排序需求 - 避免在
content字段上建索引——TEXT/VARCHAR(2048) 全字段索引会拖慢写入，真要搜内容用全文索引或外部搜索引擎
不要用触发器实时发 MQ，改用 Canal + binlog 做变更捕获
在 AFTER INSERT 触发器里调 RabbitMQ 或 Kafka 生产者，看似简单，实则埋雷：事务提交前就发消息，数据库回滚了而 MQ 消息已发出，数据必然不一致；且触发器逻辑阻塞主库写入，QPS 上千就抖动。
- 必须开启 MySQL
binlog-format=ROW和log-bin，并设置唯一server_id - 用
Canal订阅 binlog，它把每条 INSERT 解析成结构化事件，再由你自己的消费者投递到 MQ —— 这样消息发出时机在事务提交后，天然保序、可重试 - 注意 Canal 的
destination配置要和表名严格匹配，否则漏事件；测试阶段务必开canal.instance.filter.regex白名单，避免误吞系统表
消息状态更新别 update 全字段，用 WHERE 条件锁最小粒度
用户点“全部已读”，后端执行 UPDATE notification SET is_read = 1 WHERE user_id = ? AND is_read = 0 是常规操作，但容易忽略两个坑：没加 created_at 条件，导致扫全表；没限制影响行数，一次误操作清空百万用户未读态。
