Какой запрос наиболее быстрый? Какой ключ применить?

Рейтинг: 0Ответов: 2Опубликовано: 20.10.2014

В таблице есть поле city_id, нужно перед вставкой записи выполнить проверку, есть ли поле с определенным city_id.

Записей в таблице 2000000.

Очень медленно ищет.

SELECT COUNT(*) FROM `sl_cities` WHERE `city_id` = ".$value['id'].";

Какой запрос использовать для поиска?

И какой ключ применить для city_id?

Примари кей в таблице нет, также значения city_id без повторений.

Таблица MyISAM

1   city_id int(11)

2   country_id  int(11)

3   region_id   int(11)

4   area    varchar(1024)

5   region  varchar(1024)

6   title   varchar(1024)

7   important   tinyint(4)

В дальнейшем выборка будет идти не только по city_id, но и по country_id и region_id.

php mysql
Источник: Stack Overflow на русском

Ответы

▲ 1

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

SELECT 1 FROM `sl_cities` WHERE `city_id` = ".$value['id'].";

Вернет единицу при первом же совпадении.

Ключ здесь вообще ни при чем, вы путаете ключи и индексы. Ключи позволяют однозначно идентифицировать запись, индексы - осуществлять быстрый поиск по полю. То, что вместе с ключом создается индекс, не значит, что они суть единое целое.

Примари кей в таблице нет, так же значения city_id без повторений.

Вот вам и primary key.

▲ 1

Интересно, что же у вас за машина такая, что по 2-м миллионам медленно ищет.

А по теме, вообще в таких случаях задача очень просто решается, если у вас архитектура сайта правильно построена (а как мы знаем, это очень важно в таких случаях), я о том, что к вашей этой таблице должна быть только одна сущность в модели, где вы можете оптимизировать (ниже), а если ваша таблица много где используется, то тут печалька.

Как же оптимизировать:

  1. Первое: файлы с данными (в данном случае работа с файлами будет быстрее, минусы: если поиск будет не только по ключу, ибо название файла = ключ).

  2. SQL дерево: для поиска SQL дерева, наверное, для вас лучший вариант, т.к. деревья создавались для быстрого поиска.

  3. Изменить SQL таблицу: иными словами, хэш таблица + таблицы вариантов хэша. Сложность: придумать такой алгоритм, который точно указывал бы на хэш таблицу с вашей сущностью. (Но вполне на костыликах делается.)

  4. Помудрить (если есть возможность) с работой SQL сервера, там можно его оптимизировать в некоторых моментах.

Обновление

Очень медленно ищет. Какой запрос использовать для поиска?

Вот ваши основные тезисы вопроса.

И вообще, я не вижу проблем построить архитектуру по принципу дерева и вставлять туда сколько хотите, есть дерево где поиск всегда будет константный (типа log, ln)