查未读慢需建联合索引(receiver_id, is_read, created_at)，因receiver_id为高频过滤字段须最左，is_read=0为确定性等值条件居中截断数据，created_at在末位支持有序排序免filesort。
查未读慢，多半是缺(receiver_id, is_read, created_at)联合索引
“SELECT * FROM notification WHERE receiver_id = ? AND is_read = 0 ORDER BY created_at DESC LIMIT 20” 这类查询如果执行超过 100ms，基本可以断定没建对索引。单列 receiver_id 或 is_read 索引都救不了——MySQL 在 is_read = 0 这种低基数等值条件下，无法有效利用后续排序字段。
必须建联合索引：(receiver_id, is_read, created_at)。这个顺序不能调换，原因有三：
-
receiver_id是高频过滤入口，必须放最左； -
is_read是确定性等值条件（固定为 0），放在第二位能快速截断数据范围； -
created_at放最后，让 ORDER BY 直接走索引有序性，避免额外 filesort。
建完后用 EXPLAIN 验证：要看到 type=ref、key 显示该索引、Extra 里没有 Using filesort 或 Using temporary。
is_read 单独建索引有没有用？看场景
单独给 is_read 建索引（如 INDEX idx_is_read (is_read)）只在极少数场景有用：
- 后台任务批量清理过期未读消息：
DELETE FROM notification WHERE is_read = 0 AND created_at ； - 全站未读总数统计（不带 user_id）：
SELECT COUNT(*) FROM notification WHERE is_read = 0（但这种需求本身应被业务层缓存，不该直查）。
日常用户维度的未读查询中，is_read 单列索引几乎不会被优化器选中——因为 receiver_id 的区分度远高于 is_read，联合索引已完全覆盖。
反例：如果建了 (is_read, receiver_id)，那 WHERE receiver_id = ? AND is_read = 0 就会失效（违反最左前缀原则），查询直接退化为全表扫描。
为什么不要用 ENUM 或字符串存 is_read 状态
把状态写成 ENUM('unread','read') 或 VARCHAR(10) 看似语义清晰，实际会拖慢未读查询：
- 字符串比较比整型慢，尤其在
is_read = 'unread'这种条件上，MySQL 无法高效利用索引前缀； - 如果字段是
ENUM，底层虽转为整数存储，但一旦修改枚举值顺序或增删项，可能引发隐式类型转换，导致索引失效； -
TINYINT(1)存 0/1，配合联合索引，能让WHERE is_read = 0成为高效的等值查找，且与receiver_id组合时选择性陡增。
别为了“可读性”牺牲查询路径稳定性——业务代码里用常量映射即可，数据库只管高效存取。
created_at 用 TIMESTAMP 还是 DATETIME？必须选前者
用 DATETIME 存 created_at 会导致两个隐形问题：
- 时区不一致：应用服务器和数据库时区不同步时，
created_at值会错位，影响“按时间倒序”的准确性； - 无法自动更新
updated_at：只有TIMESTAMP支持ON UPDATE CURRENT_TIMESTAMP，而标记已读操作（UPDATE ... SET is_read = 1）需要精准记录那一刻的时间，这对排查“用户到底什么时候点开的”至关重要。
TIMESTAMP 占 4 字节、自动时区转换、支持自动更新——它不是兼容旧习惯的备选，而是支撑未读逻辑闭环的基础设施。别省这点空间，也别绕开它。
复杂点在于：联合索引里 created_at 是升序存储，但查询要 ORDER BY created_at DESC。MySQL 8.0+ 支持降序索引，但多数线上环境仍是 5.7 或 8.0 默认配置，此时仍依赖 B+Tree 叶子节点双向链表反向遍历，性能依然可靠——前提是索引存在且顺序正确。漏掉这个索引，再好的业务逻辑也卡在数据库第一关。
