应使用复合索引 idx_receiver_read_time (receiver_id, is_read, created_at)，其中 is_read 用 TINYINT(1) 存 0/1，配合 TIMESTAMP 类型的 created_at；未读统计用 COUNT(*) WHERE receiver_id = ? AND is_read = 0；分页改用游标（created_at + id）避免深分页性能问题。
如何用 is_read 字段高效查未读消息
直接加 is_read 字段（TINYINT(1) 或 BOOLEAN），比用状态码字段（如 status TINYINT）更直观、更利于索引下推。MySQL 对 WHERE is_read = 0 这类等值条件能快速走索引，前提是该字段上有合适的复合索引。
-
is_read值建议统一：0 = 未读，1 = 已读 —— 避免用 1/2 或字符串，否则COUNT(*)统计和ORDER BY排序都容易出错 - 不要只给
is_read单独建索引；它区分度低（只有两个值），单独索引几乎无效 - 必须配合接收者 ID 和时间字段组成复合索引，例如：
INDEX idx_receiver_read_time (receiver_id, is_read, created_at) - 查询未读消息时，
ORDER BY created_at DESC才能命中索引的最右前缀；如果写成ORDER BY id DESC，即使有主键索引也大概率触发 filesort
为什么 TIMESTAMP 比 DATETIME 更适合消息时间字段
TIMESTAMP 占 4 字节，DATETIME 占 8 字节，在亿级消息表里，光是存储就能省下几百 MB 到几 GB 空间；更重要的是，TIMESTAMP 自动支持时区转换（只要应用层不乱设 time_zone），而 DATETIME 是“所见即所得”，跨服务器部署时容易因时区不一致导致排序错乱或分页跳变。
-
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP足够记录生成时间，无需手动赋值 -
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP可自动记录状态变更时间，比如标记已读时不用额外更新语句 - 注意：MySQL 5.6.5+ 才支持
ON UPDATE CURRENT_TIMESTAMP用于非第一个TIMESTAMP字段；老版本只能靠应用层或触发器维护 - 别把
TIMESTAMP当成“绝对时间保险柜”——它的取值范围是1970-2038，2038 年后会溢出；若系统需长期存档，得评估是否要切到DATETIME或分表归档
统计未读数时，COUNT(*) 和 SUM(1 - is_read) 有啥区别
绝大多数场景下，SELECT COUNT(*) FROM messages WHERE receiver_id = ? AND is_read = 0 是最优解。它走索引快、语义清晰、MySQL 优化器识别成熟。而用 SUM(1 - is_read) 或 COUNT(IF(is_read = 0, 1, NULL)) 属于画蛇添足，不仅多一层计算，还可能让优化器放弃使用覆盖索引。
- 确保
receiver_id和is_read在同一个复合索引里，且顺序为(receiver_id, is_read, ……)，这样COUNT(*)可以只扫描索引 B+ 树的叶子节点，不回表 - 如果并发极高（比如每秒上千次未读数请求），别在每次请求时都查库；可考虑用 Redis 的
INCRBY/DECRBY缓存每个用户的未读数，DB 仅作为最终一致性兜底 - 避免在统计 SQL 里加
GROUP BY或HAVING—— 单用户未读数不需要分组，加了反而强制临时表 + filesort
分页查未读消息时，LIMIT offset, size 的性能陷阱
当用户未读消息达到几千条，LIMIT 5000, 15 这种深分页会拖垮查询：MySQL 必须先扫出前 5015 行，再丢弃前 5000 行。哪怕有索引，I/O 和 CPU 开销也随 offset 线性增长。
- 改用游标分页（cursor-based pagination）：记录上一页最后一条的
created_at和id，下一页查WHERE receiver_id = ? AND is_read = 0 AND created_at - 别在未读消息列表里混入已读消息再靠
UNION ALL排序 —— 如资料里提到的“未读放前面、已读放后面”方案，实际会触发两次索引扫描 + 合并临时表，延迟翻倍 - 如果业务允许，未读消息上限设为 99+，超过就归为“更多未读”，避免无限拉取；既减轻 DB 压力，也符合人机交互习惯
真正难的不是建字段或写 SQL，而是想清楚：未读状态变更是高频操作，但统计和分页是低频高代价操作；所有优化都要围绕这个不对称性展开。漏掉复合索引顺序、忽略游标替代深分页、或者在高并发下硬扛实时 COUNT，都是上线后才暴露的坑。
