如下面的代码，我将chat_id和student_id设置为主键，以便为另一个student_id添加相同的聊天。当它投入生产时，记录会很多。我是否应该仅为student_id添加一个索引，以便当每个用户返回屏幕查看最近的消息时，搜索速度会更快？
CREATE TABLE `tim_chat_recipients` (
`chat_id` INT(11) NOT NULL,
`student_id` INT(11) NOT NULL,
`message_status` TINYINT(1) NOT NULL DEFAULT '0' COMMENT '1:New, 2:Read, 3:Deleted',
PRIMARY KEY (`chat_id`, `student_id`))COLLATE='latin1_swedish_ci' ENGINE=InnoDB;
答案 0 :(得分：0)
如果代码要搜索student_id 而不 chat_id那么的索引至少 student_id < em> required 或查询将导致非扩展表/群集扫描 ..这是因为隐式群集/索引(chat_id, student_id) 无法在没有提供chat_id的情况下用于索引/缩减。
这个辅助索引 - INDEX(student_id, [optionally other columns]) - 可能包含其他列，作为索引的一部分或包含，尽管“适当选择”取决于查询。在这种情况下，包含message_status列以便能够使用“未看到的消息”作为具有最小读取IO的过滤器可能是有意义的，因为它可以避免探测回到表/集群。 （指数是关于平衡维护/磁盘成本和查询的好处。）
简而言之：对于SARGABLE query中的查询规划器选择的索引，必须知道索引的左侧部分，并在WHERE中提及或者，有时是JOIN .. ON条款。