is_deleted单独建索引无效且拖慢写入，必须与高频查询字段组成复合索引且is_deleted置于右侧；验证需通过explain确认命中、覆盖索引及隐藏索引灰度上线。
软删除字段 is_deleted 单独建索引几乎没用，反而拖慢写入；必须和高频查询字段组合成复合索引，且顺序不能错。
为什么 is_deleted 单独建索引是典型错误
因为 is_deleted 通常是低选择性字段（比如 99% 的数据 is_deleted = 0），MySQL 优化器大概率会直接忽略该索引，走全表扫描。更糟的是，每次 UPDATE 软删除时都要维护这个索引，白白增加 I/O 和锁开销。
- 执行
SHOW INDEX FROM user后发现Cardinality接近 1 或远小于总行数，基本可判定无效 - EXPLAIN 查看查询计划，若
type是ALL或Extra出现Using where但没走索引，说明is_deleted索引未被采纳 - 已有
(username, is_deleted)复合索引的情况下，再建is_deleted单列索引属于冗余，应删掉
is_deleted 必须放在复合索引右侧
几乎所有业务查询都带 WHERE is_deleted = 0，但它几乎总是等值过滤，不是范围条件。所以它适合放在复合索引靠右位置，把高选择性字段（如 user_id、username、created_at）放左边，才能真正缩小扫描范围。
- 正确示例：
CREATE INDEX idx_username_deleted ON user(username, is_deleted)→ 支持WHERE username = ? AND is_deleted = 0 - 错误示例：
CREATE INDEX idx_deleted_username ON user(is_deleted, username)→WHERE is_deleted = 0过滤后仍需扫描大量username值，效率低 - 若查询还含
ORDER BY created_at，且想避免Using filesort，索引可扩展为(username, is_deleted, created_at)，但需确认created_at是否真的参与过滤
如何验证复合索引是否生效
不能只看有没有建索引，得看真实查询是否命中。重点检查三个地方：
- 用
EXPLAIN SELECT * FROM user WHERE username = 'alice' AND is_deleted = 0，确认key列显示索引名，rows显著小于全表行数 - 若查询只查几个字段（如
SELECT id, username），可把它们全包含进索引做成覆盖索引：CREATE INDEX idx_username_deleted_id ON user(username, is_deleted, id)，此时Extra应出现Using index - 后台管理页要查“所有数据（含已删除）”，这类查询不加
is_deleted = 0条件，就完全不会走带is_deleted的索引——这是设计使然，不用强行优化
别跳过隐藏索引做安全验证
上线前不确定新复合索引效果？别直接删旧索引。先用 ALTER TABLE user ALTER INDEX idx_old INVISIBLE 把旧索引隐藏，观察 24 小时慢查询日志和 QPS 波动。如果没异常，再 DROP INDEX；万一出问题，ALTER INDEX ... VISIBLE 一秒恢复。这对大表尤其关键——重建索引可能卡住写入数小时。
真正容易被忽略的点是：软删除场景下，索引有效性高度依赖查询模式是否统一。只要有一个业务接口漏写了 AND is_deleted = 0，就可能让本该走索引的查询退化成全表扫描，而这个问题在线上压测中极难暴露。
