Mysql 为什么这个复合键没有索引？

我创建了这个表：

CREATE TABLE incident_originator (
    id_incident INT (11) UNSIGNED NOT NULL,
    id_user INT (11) NOT NULL,
    PRIMARY KEY (
        id_incident,
        id_user
    ),
    CONSTRAINT fk_incident_incident_originator FOREIGN KEY (id_incident) REFERENCES incident_table (id_incident) ON DELETE RESTRICT ON UPDATE CASCADE,
    CONSTRAINT fk_user_incident_originator FOREIGN KEY (id_user) REFERENCES users (id_user) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE = INNODB DEFAULT CHARSET = latin1;

但是，fk_用户_事件_发起人已编制索引，而fk_事件_事件_发起人未编制索引。为什么呢？InnoBD不是应该自动索引所有外键吗？id_事件中缺少索引会使连接速度变慢，不是吗？我读的越多，我理解的就越少

另外，当我向表中添加值时，它们是按第二列排序的，作为一个人阅读会变得很奇怪

编辑：当我从事件发起人处显示索引时；它返回以下内容：

Non_unique  Key_name    Seq_in_index    Column_name
0   PRIMARY 1   id_incident
0   PRIMARY 2   id_user
1   fk_user_incident_originator 1   id_user

fk_事件的发起人不是

当然是

PRIMARY KEY (id_incident,id_user),

在引用表中，必须有一个索引，其中外键列按相同顺序列为第一列。如果引用表不存在，则会自动在引用表上创建这样的索引

id_事件是主键最左边的第一列。。。主键是一个非常好的索引，用于在强制约束时查找值。添加第二个索引是多余的

连接也是如此，尽管连接不是外键总是被索引的实际原因-任何包含锚定到索引左侧的所有连接列的索引对于连接都是非常有效的

它们是按第二栏排序的，作为一个人阅读会变得很奇怪

告诉您知道的任何人，数据库不会为了人类的利益而对其输出进行排序，除非人类使用order BY。没有ORDER BY的结果集根据定义是无序的。行通常按主键顺序返回的事实是巧合，而不是出于设计或需要。当优化器在读取表时更改策略时，当表变大时，此行为可能会改变。。。但由于id_user上的索引实际上是一个覆盖索引，它包含表中的所有列，因为所有索引还包含主键的副本。。。或者，更准确地说，它包含满足此特定查询所需的所有列—这有时是两种不同的东西，这是不在实际代码中使用SELECT*的最佳原因之一，因此优化器恰好选择它作为其源。它从它选择的任何索引中以索引顺序读取行，并且该顺序成为结果的完全一致顺序。

我在问题中添加了显示索引的结果，因为正如您所说，我看不到fk_incident_incident_始发者被索引。它不应该出现在show索引结果中吗？关于这个>它从它选择的任何索引中以索引顺序读取行，并且该顺序成为结果的完全一致顺序。主键和Seq_索引值的索引顺序表明它应该首先按id_事件对列进行排序，不是吗？无论如何，我不会对查询结果使用SELECT*或not排序，排序更像是一种好奇。SHOW INDEX之所以令人困惑，是因为，在这里，fk_user_incident_originator并不是你所认为的意思。这是索引名，仅与约束符号重合。如果您先向user_id添加了一个索引，然后添加了这个外键，那么它也不会显示在show index中。