在200萬行上的〜150ms MySQL MyISAM表

我正在學習一個由~2百萬行+〜600k行（兩個MyISAM表）組成的寵物項目的MySQL性能。在兩個INT（10）索引列上使用BETWEEN進行範圍查詢，LIMIT爲1返回的結果大約需要160ms（包括INNER JOIN）。我想我的配置沒有優化，並且正在尋找一些關於如何進行診斷的建議，或者可能是「常見配置」。在200萬行上的〜150ms MySQL MyISAM表

我創建了一個gist包含兩個表，查詢和my.cnf的內容。

在插入從MaxMinds open database的CSV文件導入的所有數據後，創建了b-tree索引。我試了兩次，現在是一個綜合指數，在性能上沒有差異。

我在2.6GHz（i5）和8GB 1600MHz內存的MacBook Pro上本地運行此程序。 MySQL的安裝使用可下載的二進制文件從mysql的下載頁面（無法提供第三個鏈接，因爲我的代表很低）。這是一個默認安裝，對my.cnf配置文件沒有主要的補充，包含在要點中（位於我的系統的/usr/local/mysql-5.6.xxx/目錄下）。

我擔心的是我達到了〜160ms，這表明我錯過了一些東西。我曾考慮壓縮桌子，但我有一種感覺，我錯過了其他配置。另外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;爲了方便，將數據包含在問題中。

來源

2015-02-24 iwantoski

您可能想要運行EXPLAIN併發布結果。 – 2015-02-24 09:44:19

@ZsoltSzilagy謝謝，更新了這個問題。 – iwantoski 2015-02-24 09:52:49

將索引作爲'（begin_range，end_range）'是沒有意義的。它會像使用'（begin_range）'一樣使用。所以，最好是索引'（begin_range）'，因爲它比較小 - 從磁盤讀取的字節數少（雖然好處相對較小）。你可以嘗試在'（end_range）'上添加第二個索引，但是我懷疑MySQL會在這個查詢中使用這兩個索引。嘗試並檢查'解釋'。 – 2015-02-24 10:19:13

這個問題和正常的方法（你的代碼的例證）導致命中1095345行。我有一個辦法，可以做一個磁盤命中查詢，即使緩存很冷。

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

現狀

你的數據包括一大組不重疊「的範圍」。這些可能是IP地址，日期時間（單站顯示時間），郵編等。

你有一對開始和結束值;一個'項目'屬於每個這樣的'範圍'。所以，本能地，你創建一個帶有範圍的開始和結束的表格，以及有關該項目的信息。您的查詢涉及一個WHERE子句，用於比較開始值和結束值之間的差異。

問題

一旦獲得大量項目，性能就會下降。你玩索引，但找不到任何效果。索引不能導致最佳功能，因爲數據庫不瞭解範圍是不重疊的。

解

我將提供強制執行的事實，項不能有重疊的範圍的溶液。該解決方案構建了一個表來利用該表，然後使用Stored Routine來解決它所施加的笨拙。

來源

2015-02-25 05:00:52

在200萬行上的〜150ms MySQL MyISAM表

回答

相關問題