MySQL медленно работает на локальном хосте - в основном продолжительность сети - PullRequest
1 голос
/ 17 марта 2011

Я выполняю очень простой запрос по проиндексированному столбцу в таблице строк объемом 20 млн.

select * from prvol where date = '20100203';

Это занимает около 22 секунд.Я новичок в SQL, но думаю, что индексированный столбец должен быть быстрее, чем этот.Там нет проблемы с памятью.Кроме того, вывод говорит, что время в основном в сети.Я выполняю запрос на той же машине, на которой работает сервер.

/* 0 rows affected, 6,882 rows found. Duration for 1 query: 0.828 sec. (+ 21.438 sec. network) */

Что означает это сетевое время?Вы ожидаете, что этот запрос будет выполняться быстрее?

РЕДАКТИРОВАТЬ: в соответствии с запросом, вот некоторые результаты.

EXPLAIN SELECT * FROM prvol WHERE date = '20100203';
"id","select_type","table","type","possible_keys","key","key_len","ref","rows","Extra"
"1","SIMPLE","prvol","ref","Index 1","Index 1","4","const","6881","Using where"

SHOW CREATE TABLE prvol;
"Table","Create Table"
"prvol","CREATE TABLE `prvol` (
  `exch` varchar(10) DEFAULT NULL,
  `ticker` varchar(10) DEFAULT NULL,
  `date` date DEFAULT NULL,
  `open` float unsigned DEFAULT NULL,
  `high` float unsigned DEFAULT NULL,
  `low` float unsigned DEFAULT NULL,
  `close` float unsigned DEFAULT NULL,
  `vs` float unsigned DEFAULT NULL,
  `aclose` float DEFAULT NULL,
  KEY `Index 1` (`date`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1"

Ответы [ 4 ]

2 голосов
/ 22 марта 2011

В конце концов я понял, почему мой запрос был медленным. См. здесь для ответа. Это закончилось тем, что не имело ничего общего с сетевым временем. Это была проблема с размером кэша.

2 голосов
/ 17 марта 2011

Да, безусловно, он должен работать быстрее.

Возможно, вы допустили одну из следующих распространенных ошибок:

  • Вы проиндексировали столбец, но это не было datecolumn.
  • Вы создали многоколонный индекс, но столбец date не является первым столбцом в индексе и поэтому не может использоваться для этого запроса.
  • Вы явно помните, что добавили индекс, но каким-токажется, что индекс «исчез» (возможно, потому что вы выполнили запрос, и он выдал ошибку, но вы не заметили сообщение об ошибке).

Чтобы выяснить, что это, запустите SHOW CREATE TABLE prvol и опубликовать вывод.


Еще одна вещь, которую вы можете сделать, чтобы улучшить ситуацию, - это избежать использования SELECT *.Всегда выбирайте только те столбцы, которые вам нужны.Даже если вы считаете, что вам нужны все столбцы, вам, вероятно, все равно следует перечислить их в явном виде в целях безопасности на случай, если схема изменится в будущем.

1 голос
/ 17 марта 2011

Я на самом деле думаю, что запрос выполняется отлично.

Возвращать 6,882 строки N-столбцов (выберите *) за 0,828 секунды - разумное время на разумном оборудовании.

Сетьвремя 21.438 с - это время, необходимое для передачи по сети x МБ, где x = bytes per row * 7k, что может составлять десятки МБ.Но 21-е в сети немного медленнее - , но это не вопрос вопроса .

0 голосов
/ 22 февраля 2019

Я использую эту библиотеку. Это было быстрее, чем у Google.

<script src="https://api.mqcdn.com/sdk/place-search-js/v1.0.0/place-search.js"></script>
<link type="text/css" rel="stylesheet" href="https://api.mqcdn.com/sdk/place-search-js/v1.0.0/place-search.css"/>

<script type="text/javascript">

var ps;
window.onload = function () {
    ps = placeSearch({
        key: 'lYrP4vF3Uk5zgTiGGuEzQGwGIVDGuy24',
        container: document.querySelector('#place-search-input'),
        useDeviceLocation: false,
        collection: [
            'poi',
            'airport',
            'address',
            'adminArea',
        ]
    });
}

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...