我有以下查询，使用 MariaDB 10 / InnoDB：
SELECT id, sender_id, receiver_id, thread_id, date_created, content
FROM user_message
WHERE thread_id = 12345
AND placeholder = FALSE
ORDER BY date_created DESC
LIMIT 20
此查询根据给定的条件获取消息并按创建日期排序。
我有一个覆盖索引(thread_id, date_created)。
运行 EXPLAIN 时，使用了正确的索引并且我得到了输出“Using where”，尽管查询使用的是不在索引中的语句中间的列。我可以为“placeholder = x”使用任何值，结果是一样的。
如果我将排序更改为使用另一列，则 EXPLAIN 会正确指示“使用位置。使用文件排序”。
我有一个令人头疼的时刻。有人可以解释一下吗？我希望看到的是需要额外的文件排序，因为由于额外的列而无法完全使用覆盖索引。
Postgres 文档声明了以下有关仅索引扫描和覆盖索引的内容：
如果您经常运行类似的查询
SELECT y FROM tab WHERE x = 'key';加速此类查询的传统方法是仅在 x 上创建索引。然而，索引定义为
CREATE INDEX tab_x_y ON tab(x) INCLUDE (y);可以将这些查询作为仅索引扫描来处理，因为可以从索引中获取 y 而无需访问堆。
因为列 y 不是索引搜索键的一部分，所以它不必是索引可以处理的数据类型；它仅存储在索引中，并且不被索引机制解释。另外，如果索引是唯一索引，即
CREATE UNIQUE INDEX tab_x_y ON tab(x) INCLUDE (y);唯一性条件仅适用于 x 列，不适用于 x 和 y 的组合。（INCLUDE 子句也可以用 UNIQUE 和 PRIMARY KEY 约束编写，为设置这样的索引提供替代语法。）
问题1：如果 的数据类型y可以添加到索引中，并且没有唯一性要求，那么使用CREATE INDEX tab_x_y ON tab(x) INCLUDE (y)overCREATE INDEX tab_x_y ON tab(x, y)进行查询有什么优势SELECT y FROM tab WHERE x = 'key';？
在向索引添加非键有效负载列（尤其是宽列）时保持保守是明智的做法。如果索引元组超过索引类型允许的最大大小，数据插入将失败。在任何情况下，非键列都会复制索引表中的数据并使索引的大小膨胀，从而可能会减慢搜索速度。 …
我有一个包含一列的非聚集索引。现在我想改变索引并添加额外的两列作为覆盖列。是否可以？如果是，那么请您提供 T-SQL 脚本。