mysql - 提高 MySQL 索引效率 - 多个索引中的列？

Question

尝试在海量数据上更有效地使用索引。

我有一个开源应用程序，可以将数百万条记录记录到 MySQL 数据库中。我已经在 Web 开发中使用 mysql 数据库多年，我对选择有效的字段类型、索引为何/如何有用的基础知识等有足够的了解 - 但是我们的应用程序日志的庞大数据量加上很难准确预测将查询哪些列让我有点不知所措。

该应用程序记录玩家的事件。我们有一个非常先进的清除系统，但有些服务器很忙，仅仅八周后它们就有 5000 万条记录。

在这种规模下，对于我们现有的索引，查询可能仍需要 30-90 秒。

主表模式(减去现有索引):

CREATE TABLE IF NOT EXISTS `prism_data` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `epoch` int(10) unsigned NOT NULL,
  `action_id` int(10) unsigned NOT NULL,
  `player_id` int(10) unsigned NOT NULL,
  `world_id` int(10) unsigned NOT NULL,
  `x` int(11) NOT NULL,
  `y` int(11) NOT NULL,
  `z` int(11) NOT NULL,
  `block_id` mediumint(5) DEFAULT NULL,
  `block_subid` mediumint(5) DEFAULT NULL,
  `old_block_id` mediumint(5) DEFAULT NULL,
  `old_block_subid` mediumint(5) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

WHERE最常见的条件包括:

world_id/x/y/z坐标(查询都默认为用户周围的半径，所以坐标几乎总是被使用)

epoch (所有查询默认为最近三天，用户需要覆盖更长的时间范围)

action_id和/或 player_id (有一半的时间，用户在寻找谁做了特定的 Action 或特定的玩家引起了什么 Action 。)

剩余的查询可以是任意组合，block_id 值与玩家或 Action 等组合。随机

GROUP BY - 默认情况下，应用程序按某些字段分组，因此用户不会看到 100 个相同玩家/ Action /块的重复事件，他们只能看到带有计数的单个记录。
action_id , player_id , block_id , DATE(FROM_UNIXTIME(epoch)) ORDER BY总是 prism_data.epoch DESC, x ASC, z ASC, y ASC, id DESC . epoch以便用户首先看到最近的事件。其余的都是为了让“回滚”引擎按正确的顺序处理事情。

这是一个没有订单/组的示例查询 :

SELECT *
FROM prism_data 
INNER JOIN prism_players p ON p.player_id = prism_data.player_id
INNER JOIN prism_actions a ON a.action_id = prism_data.action_id
INNER JOIN prism_worlds w ON w.world_id = prism_data.world_id 
LEFT JOIN prism_data_extra ex ON ex.data_id = prism_data.id 
WHERE w.world = 'DeuxTiersMondes'
AND (prism_data.x BETWEEN 668 AND 868)
AND (prism_data.y BETWEEN -33 AND 167)
AND (prism_data.z BETWEEN 358 AND 558);
LIMIT 1000;

使用索引: INDEX地点 ( world_id , x , z , y );查找 1000 行仍然需要 15 秒(或查找所有 64735 行需要 50 秒)。

该查询的解释:

+----+-------------+------------+--------+---------------+----------+---------+--------------------------------+------+--------------------------+
| id | select_type | table      | type   | possible_keys | key      | key_len | ref                            | rows | Extra                    |
+----+-------------+------------+--------+---------------+----------+---------+--------------------------------+------+--------------------------+
|  1 | SIMPLE      | w          | ref    | PRIMARY,world | world    | 767     | const                          |    1 | Using where; Using index |
|  1 | SIMPLE      | prism_data | ref    | location      | location | 4       | minecraft.w.world_id           | 6155 | Using index condition    |
|  1 | SIMPLE      | a          | eq_ref | PRIMARY       | PRIMARY  | 4       | minecraft.prism_data.action_id |    1 | NULL                     |
|  1 | SIMPLE      | p          | eq_ref | PRIMARY       | PRIMARY  | 4       | minecraft.prism_data.player_id |    1 | NULL                     |
|  1 | SIMPLE      | ex         | ref    | data_id       | data_id  | 4       | minecraft.prism_data.id        |    1 | NULL                     |
+----+-------------+------------+--------+---------------+----------+---------+--------------------------------+------+--------------------------+

在我看来，寻找这个特定的值应该快得多。我们甚至没有在这个查询中排序/分组。

我的问题:

我认为为我上面列出的每个常见情况设计一个索引是最有意义的。即组合 world_id/x/y/z 的一个索引, 一个结合了 action_id/player_id一个用于 epoch .对于某些查询，这很有效，但对于其他查询则不然。对于使用 world_id, player_id, and epoch 的查询它只选择了 world_id/x/y/z指数。

我可以/应该在多个索引中包含一列吗？可能是完整位置的一个索引，还有 world_id/player_id/epoch 的一个索引。 ?我真的不知道 mysql 使用什么逻辑来选择最适合的索引，但我假设如果索引使用 mysql 需要的更多列，它会选择那个。如果这有助于我的查询，那么在写入时稍微提高性能是值得的。

我应该创建一个包含我分组/排序的所有字段的索引吗？我的说明经常显示Using filesort我知道这是性能的主要痛点。

即使它们在组合索引中，在大多数字段上使用单个索引有什么好处吗？

抱歉阅读太久。

我正在使用不同的索引设置对 5 个最常见的查询进行大量分析，但感觉我可能缺少一些基础知识。在我继续之前，我宁愿让一些真正的专家教我一些我遗漏的东西。

Answer 1

只是一个简短的说明，因为这种事情一遍又一遍地出现:prism_worlds 上的 JOIN不需要，因为您(很可能)不需要该表中的数据。您基本上是在询问数据库“给我名称等于'某物'的世界的每个名称”。改用标量子查询。

在 prism_worlds.world 上创建唯一索引并运行查询

SELECT *
FROM prism_data 
WHERE prism_data.world_id = (SELECT w.world_id FROM prism_worlds AS w WHERE w.world = 'DeuxTiersMondes')
LIMIT 1000;

优化器将计算出 prism_data.world_id被限制为单个常量值。 MySQL 会提前运行一个查询来找出这个值并在整个查询过程中使用它。见 EXPLAIN为 const - 子查询执行。

关于 prism_data.x , .y和 .z :您可能希望为此创建几何列和空间索引。如果您需要坚持使用单独的值，您可能希望将整个世界几何体分成固定大小的体素(由单个 int 表示)，并使用简单的几何体来确定哪个位置属于哪个体素。

我个人的解决方案不会过多考虑在此表上添加无数查询。索引会使它变慢变大。使用 cron 作业填充报表(物化 View )以提前生成结果并在 cron 作业出现并再次更新它们时使用它们。