在这种情况下我应该使用分区吗

Question

我有下表：

    CREATE TABLE `connections` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
 `user_id_from` int(11) NOT NULL,
 `user_id_to` int(11) NOT NULL,
 `counter` int(11) NOT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `to_from` (`user_id_to`,`user_id_from`),
 KEY `user_id_from` (`user_id_from`)
) ENGINE=InnoDB AUTO_INCREMENT=1559108041 DEFAULT CHARSET=utf8

它是 103GB（43GB 数据和 59GB 索引）和大约 ~1,143,663,061 行。我认为主要的性能障碍是索引大小的结果，因此解决方案可能意味着将其减少为小索引（分区）。我正在考虑添加一个 DATE 字段并按 MONTH 进行分区。我可以忍受每次只查询最近的 X 个月（X 大约是 6 个月）。我看到的缺点是这会导致桌子变得比现在大。

在我进行基准测试之前，您会建议这样做吗？您还有其他建议吗？

更新： 我在这张表上使用的查询：
SELECT * FROM connections WHERE user_id_to=x LIMIT 3000
SELECT * FROM connections WHERE user_id_from=x ORDER BY counter DESC LIMIT 100
SELECT user_id_from, counter FROM connections WHERE user_id_to IN (x1, x2, ..., x1000) LIMIT 500
SELECT * FROM connections WHERE user_id_to=x AND user_id_from IN (x1, x2, ..., x1000) LIMIT 1000

我以 user_id_to 作为主要条件并以 user_id_from 作为主要条件进行查询的原因是连接是定向的，我正在寻找相互连接（to->from && from->to）。 WHERE user_id_to 的行数可能非常高，WHERE user_id_from 大多不是那么多，这就是为什么当我 ORDER BY counter 时我没有为此添加索引。

Answer 1

您可以通过修改唯一键（取决于您的查询如何使用它们）来删除一个索引user_id_from：而不是to_from，将其设为from_to为(user_id_from,user_id_to)，例如开始-结束。那么您就不需要user_id_from 上的第二个索引，因为即使不需要第二部分 (user_id_to)，也会使用组合索引/键 user_id_from 的第一部分。

所以你只需要：

PRIMARY KEY (`id`)
UNIQUE KEY `from_to` (`user_id_from`,`user_id_to`)

这是节省索引使用空间的一项更改。 （使用表的一小部分对其进行测试，然后查看EXPLAIN 结果）。 PS：当您继续进行此更改时，请删除 user_id_* 索引，然后创建 from_to 索引，以防您的磁盘限制在 30 GB 以内。

特别针对您的问题...
如果不需要旧数据，则以下任一方法可能更有意义：

1. 删除旧行，例如user_id_to 超过 1 年；或者，
2. （使用选项 1）- 创建一个类似 old_users 的表，如果需要该信息，只需添加他们的 ID 和 user_id_to 字段。
3. 将connections 的旧行插入到新表中，例如connections_archive，然后从connections 中删除。假设您永远不会在应用程序的查询中查询_archive，或者仅从管理界面（即很少）在这种情况下，使用connections 和connections_archive 对“联合”查询的性能影响是可以忍受的。李>