在 200 万行 MySQL MyISAM 表上约 150 毫秒答案

【问题标题】：~150ms on a 2 million rows MySQL MyISAM table在 200 万行 MySQL MyISAM 表上约 150 毫秒
【发布时间】：2015-04-25 20:58:51
【问题描述】：

我正在通过一个包含约 200 万行 + 约 60 万行（两个 MyISAM 表）的宠物项目来了解 MySQL 的性能。在两个 INT(10) 索引列上使用 BETWEEN 的范围查询，限制为 1 个返回结果大约需要 160 毫秒（包括一个 INNER JOIN）。我认为我的配置没有优化，正在寻找一些关于如何诊断或“通用配置”的建议。

我创建了一个gist，其中包含两个表、查询和 my.cnf 的内容。

在插入从MaxMinds open database 的 CSV 文件导入的所有数据后，我创建了 b-tree 索引。我尝试了两个单独的，现在是一个组合索引，性能没有差异。

我在主频为 2.6GHz (i5) 和 8GB 1600MHz RAM 的 Macbook Pro 上本地运行它。 MySQL 是使用 mysql 下载页面中的可下载二进制文件安装的（无法提供第三个链接，因为我的代表太低了）。这是一个默认安装，没有对 my.cnf 配置文件进行重大添加，包含在 gist 中（位于我系统上的 /usr/local/mysql-5.6.xxx/ 目录下）。

我担心的是我达到了 ~160 毫秒，这表明我错过了一些东西。我考虑过压缩表格，但我觉得我缺少其他配置。 myisampack 也不在我的 PATH 中（我认为），所以在进一步探索之前我正在考虑其他优化。

感谢任何建议！

$ mysql --version
/usr/local/mysql-5.6.23-osx10.8-x86_64/bin/mysql  Ver 14.14 Distrib 5.6.23, for osx10.8 (x86_64) using  EditLine wrapper

表格

CREATE TABLE `blocks` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `begin_range` int(10) unsigned NOT NULL,
  `end_range` int(10) unsigned NOT NULL,
  `_location_id` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `begin_range` (`begin_range`,`end_range`)
) ENGINE=MyISAM AUTO_INCREMENT=2008839 DEFAULT CHARSET=ascii;

CREATE TABLE `locations` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `country` varchar(2) NOT NULL DEFAULT '',
  `region` varchar(255) DEFAULT NULL,
  `city` varchar(255) DEFAULT NULL,
  `postalcode` varchar(255) DEFAULT NULL,
  `latitude` float NOT NULL,
  `longitude` float NOT NULL,
  `metro_code` int(11) DEFAULT NULL,
  `area_code` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=641607 DEFAULT CHARSET=utf8;

查询

SELECT locations.latitude, locations.longitude
FROM blocks
INNER JOIN locations ON blocks._location_id = locations.id
WHERE INET_ATON('139.130.4.5') BETWEEN begin_range AND end_range
LIMIT 0, 1;

编辑；在 SELECT 上使用 EXPLAIN 更新了要点，为方便起见，也在此处发布。

EXPLAIN SELECT locations.latitude, locations.longitude FROM blocks INNER JOIN locations ON blocks._location_id = locations.id WHERE INET_ATON('94.137.106.123') BETWEEN begin_range AND end_range LIMIT 0, 1;

+----+-------------+-----------+--------+---------------+-------------+---------+---------------------------+---------+------------------------------------+
| id | select_type | table     | type   | possible_keys | key         | key_len | ref                       | rows    | Extra                              |
+----+-------------+-----------+--------+---------------+-------------+---------+---------------------------+---------+------------------------------------+
|  1 | SIMPLE      | blocks    | range  | begin_range   | begin_range | 4       | NULL                      | 1095345 | Using index condition; Using where |
|  1 | SIMPLE      | locations | eq_ref | PRIMARY       | PRIMARY     | 4       | geoip.blocks._location_id |       1 | NULL                               |
+----+-------------+-----------+--------+---------------+-------------+---------+---------------------------+---------+------------------------------------+
2 rows in set (0.00 sec)

编辑 2;为方便起见，将数据包含在问题中。

【问题讨论】：

您可能想要运行 EXPLAIN 并发布结果。
@ZsoltSzilagy 谢谢，更新了问题。
索引为(begin_range, end_range)是没有意义的。它将被当作只是(begin_range) 使用。所以，最好有索引(begin_range)，因为它更小——从磁盘读取的字节更少（尽管好处相对较小）。您可以尝试在(end_range) 上添加第二个索引，但我怀疑 MySQL 会在此查询中使用这两个索引。尝试检查explain。
也不是完全没用。如果所需的所有信息都在索引本身中，则不必读取表来检索其余数据。我实际上会在[begin_range, end_range, _location_id] 或[_location_id, begin_range, end_range] 上尝试组合索引。订单很重要。这样可以从索引本身执行连接。
@VladimirBaranov 我尝试了这两种方法，但对性能没有实际影响（就我而言）。午餐后我会尝试 ontrack 的建议 - 但是，添加 INNER JOIN 会增加大约 5 毫秒的整体响应时间。

标签： mysql performance myisam mysql-5.6

【解决方案1】：

问题和正常方法（您的代码举例说明）导致达到 1095345 行。我有一种方法可以在 one 磁盘命中时执行该查询，即使缓存很冷。

摘自http://mysql.rjweb.org/doc.php/ipranges：

情况

您的数据包含大量不重叠的“范围”。这些可以是 IP 地址、日期时间（单个站点的显示时间）、邮政编码等。

你有成对的开始和结束值；一个“项目”属于每个这样的“范围”。因此，本能地，您创建了一个包含范围开始和结束的表格，以及有关项目的信息。您的查询涉及 WHERE 子句，用于比较开始值和结束值之间的情况。

问题

一旦您获得大量项目，性能就会下降。您使用索引，但没有发现任何效果很好。索引无法实现最佳功能，因为数据库不了解范围是不重叠的。

解决方案

我将提出一个解决方案，该解决方案强制项目不能具有重叠范围这一事实。该解决方案构建了一个表来利用这一点，然后使用存储例程来解决它所带来的笨拙。

【讨论】：