为何含位运算条件的UPDATE用索引，同条件SELECT却不用？

核心原因在于两个语句的执行需求差异，直接影响了查询优化器的成本判断：

• 对于SELECT * FROM mytable WHERE process_flag & 4 = 4：
  非聚集索引仅存储process_flag和行定位信息（比如主键或RID），如果用这个索引定位到符合条件的行后，还需要回表（访问聚集索引/堆表）读取所有其他列——这个操作叫书签查找。如果符合条件的记录数量较多（哪怕只占500万条数据的10%），书签查找的IO成本会远高于直接全表扫描，所以优化器会放弃索引，选择全表扫描，导致耗时较长。

• 对于UPDATE mytable SET process_flag = process_flag &~ 4 WHERE process_flag & 4 = 4：
  这个语句仅需修改process_flag列，而该列正好包含在非聚集索引中。优化器可以直接通过非聚集索引定位到目标行，然后完成两个操作：修改聚集索引/堆表里的process_flag值，同步更新非聚集索引中的对应条目。整个过程不需要回表读取其他列，IO成本大幅降低，因此优化器会选择使用索引，执行速度自然更快。

补充细节：位运算条件process_flag & 4 = 4本身属于可被索引利用的条件，只是SELECT场景下回表成本过高，才被优化器舍弃索引；而UPDATE场景下无额外回表需求，索引的价值就体现出来了。

内容的提问来源于stack exchange，提问作者altwood