我应该索引具有低“真”基数 MySQL 的布尔字段吗？

Question

我有一个包含 1M 行（并且还在增长）的 MESSAGE 表。每个消息查询都涉及选择行 WHERE isRequest = True 或 WHERE isRequest = False，但绝不会同时选择两者。我的绝大多数查询都在寻找 isRequest = False。该表的写入非常频繁，我需要保持快速写入（因为用户喜欢以低延迟相互发送消息）。另请注意，MESSAGE 表目前除了主键之外没有任何列索引。

95% 的行有 isRequest = False，只有 5% 的行有 isRequest = True。 在这种情况下索引 isRequest 布尔字段是否更高效？

此外，我了解索引列会消耗内存，但是对于所有列数据类型，包括布尔值，这种开销等效吗？

更新：

在与@Rick James 进一步分析后，我们提出了一个新的表格方案（请注意，所有 PK 都是自动递增的，因此时间相对性是可辨别的）：

MESSAGE (id=PK) (sender_id, recipient_id, conversation_id = FKs)
---------------------------------------------------------------
id  sender_id   recipient_id  message            conversation_id
1    1          2            "hows it going"   4
2    2          1            "great! hbu"      4
3    1          8            "hey man"         3
4    9          1            "please respond"  2
5    4          6            "goodnight girl"  1


CONVERSATION (id=PK) (userA_id, userB_id = FKs)
-----------------------------------------------
id  userA_id  userB_id
1   4          6            
2   1          9
3   1          8
4   1          2


USERCONVERSATION (id=PK) (userA/B_id, conver_id, lastMsg_id = FKs)
------------------------------------------------------------------
id   userA_id  userB_id   conver_id  lastMsg_id   isRequest
1    4         6          1          5            False
2    6         4          1          5            False
3    1         9          2          4            True
4    9         1          2          4            True
5    1         8          3          3            False
6    8         1          3          3            False
7    1         2          4          2            False
8    2         1          4          2            False

索引：

MESSAGE: index(id),
         index(conversation_id, id)

CONVERSATION: index(id), 

USERCONVERSATION: index(id),
       index(user_id, isRequest),
       index(user_id, lastMessage_id),
       index(conversation_id)

应用中的查询：

由于如上所述的正确索引，以下查询应该是高性能的。如果可以改进，请与我们联系。

获取变量 userID 的最近 20 个对话（包括最后的消息内容和其他用户的信息）：

SELECT  T4.userB_id, T4.username, T4.profilePic, T4.conver_id,
        T4.message 
    (
        SELECT  T1.userB_id, T2.username, T2.profilePic, T1.conversation_id,
                T1.lastMessage_id
            FROM  
            (
                SELECT  userB_id, conversation_id, lastMessage_id
                    FROM  rage.userconversation
                    WHERE  userA_id = {userID}
                      AND  isRequest=False
            ) AS T1
            LEFT JOIN  rage.user AS T2  ON T1.userB_id = T2.id AS T3
    )
    LEFT JOIN  rage.message AS T4  ON T1.lastMessage_id = T4.id
    ORDER BY  T4.id DESC
    LIMIT  20

单词解释：获取最近的 USERCONVERSATION 行中的 20 行，因为 lastMessage 存储在那里。为了找到给定用户最近的 20 个，请选择 user_id = userID 的所有行并按 lastMessage_id DESC 排序。这是准确的，因为 message_id 是自动递增的。除了最后一条消息，我们还需要获取对话中其他用户的一些用户数据（个人资料图片、用户名）。我们通过左连接来实现这一点。

结果：

RESULT (for userID = 1)
---------------------------------------------------------------
userB_id  username   profilePic  message            conver_id
8         John       8.jpg       "hey man"          3
2         Daisy      2.jpg       "great! hbu"       4

然后当用户点击对话时，由于我们有对话 ID，我们只需：

SELECT * FROM rage.message WHERE conversation_id={conver_id} ORDER BY id DESC LIMIT 20

希望我们索引 (conversation_id, id) 后排序很快。

Answer 1

对于这个查询，也许还有其他查询，最好在表中有另一列。它会是一个唯一的数字，比如“conversation_id”，它是从一对唯一的发件人和收件人中派生出来的。

一种粗略的方式（但不一定是最佳方式）是从这个有序对的不同值中以某种方式推导出它：

(LEAST(sender_id, recipient_id), GREATEST(recipient_id, sender_id))

那么INDEX(conversation_id, id) 可能是正在讨论的查询的关键。到那时，我们可以重新加入对布尔值的讨论。我怀疑这最终会是最佳索引：

INDEX(conversation_id, isRequest, id)

（或者可能交换了前两列）。

Answer 2

使用复合索引。让我们看看整个WHERE 子句，以便为您提供准确的详细信息。

例子

WHERE IsRequest = True
  AND UserId = 12345

将受益于

INDEX(IsRequest, UserId)

（无论你把列名放在哪个顺序，它是真还是假都没有关系。）

你的例子

• OR 破坏了索引的使用
• 两个查询之间的UNION 可能会避免OR。
• 没有索引对您编写的查询有用。
• 将有两个嵌套表扫描。

也许

（不知道下面是不是也一样）

( SELECT  m1.id, m1.sender_id, m1.recipient_id, m1.message ...
    FROM  myapp_message AS m1
    LEFT JOIN  app_message AS m2
         ON  m1.sender_id = m2.sender_id
        AND  m1.id < m2.id
    WHERE  m2.id IS NULL
      AND  m1.sender_id = {userID}
      AND  m1.isRequest = False
    order by  id desc
    LIMIT  20
) UNION ALL (
SELECT  m1.id, m1.sender_id, m1.recipient_id, m1.message ...
    FROM  myapp_message AS m1
    LEFT JOIN  app_message AS m2
         ON  m1.recipient_id = m2.recipient_id
        AND  m1.id < m2.id
    WHERE  m2.id IS NULL
      AND  m1.recipient_id= {userID}
      AND  m1.isRequest = False
    order by  id desc
    LIMIT  20 
)   ORDER BY id DESC LIMIT 20

如果您要分页，请参阅：http://mysql.rjweb.org/doc.php/pagination#pagination_and_union

更接近

SELECT  m...
    FROM
      ( SELECT xid, MAX(mid) AS mid
        FROM
        (
          ( SELECT  recipient_id AS xid,
                    MAX(mid) AS mid      -- The last message TO each recipient
                FROM  WHERE sender_id = 1234  -- FROM the user in question
                GROUP BY  recipient_id
                ORDER BY 2 DESC   -- ("2nd column")
                LIMIT  20                        
          )
          UNION ALL
          ( SELECT  sender_id AS xid,
                    MAX(mid) AS mid      -- The last message FROM each sender
                FROM  WHERE recipient_id = 1234  -- TO the user
                GROUP BY  sender_id
                ORDER BY 2 DESC
                LIMIT  20
          )
        ) AS y
        GROUP BY xid       -- yes, repeated
        ORDER BY mid DESC  -- yes, repeated
        LIMIT 20           -- yes, repeated
      ) AS x
    JOIN messages AS m  ON m.mid = x.mid

使用这两个索引：

INDEX(sender_id, recipient_id, mid)
INDEX(recipient_id, sender_id, mid)

每个子查询都有一个INDEX。每个都是最优的，加上“覆盖”。

（我没有看到isRequest 的相关性，所以我把它省略了。我怀疑如果需要该列，可以将其添加到索引中而不会降低效率——如果放置在适当的位置。 )

Answer 3

您有多种选择。根据您的描述，以下两个之一似乎是合适的：

• 一个聚集索引，其中第一个键是IsRequest。
• 包含IsRequest 的分区方案。

另一种可能性是两个单独的表。

但是，因为我怀疑您的查询是否返回了 95%（甚至 5%）的行，所以毫无疑问还有其他过滤器。为这些过滤器创建索引可能比为布尔标志创建索引更重要。