2015-02-02 5 views
-1

Мне нужно создать таблицу, которая назначает идентификатор пользователя и идентификатор продукта некоторым данным (модели 2 от одного до многих отношений). Я сделаю много запросов, какSQL where performance performance

select * from table where userid = x; 

Первое, что я заинтересован в том, как велика должна таблица получить до того, как запрос начинает наблюдаться (скажем, это занимает больше, чем 1 секунда).

Также, как это можно оптимизировать?

Я знаю, что это может зависеть от реализации. Я буду использовать mysql для этого конкретного проекта, но меня тоже интересуют более общие ответы.

ответ

0

Все зависит от мощности вашей машины. Делают что запрос более эффективным, создать индекс с «идентификатор пользователя»

0

насколько велика должна таблица получить до того, как запрос начинает наблюдаться (скажем, это занимает больше, чем 1 секунда)

Там слишком много факторов для детерминированного измерения времени выполнения. Скорость процессора, память, скорость ввода-вывода и т. Д. - это лишь некоторые из внешних факторов.

как это можно оптимизировать?

Это более стойкий. Если есть индекс на userid, тогда запрос будет иметь индекс , который ищет, который примерно так же быстро, как вы можете получить , находя запись. Если userid является кластерным индексом , то он будет быстрее, потому что ему не нужно будет использовать позицию из индекса, чтобы найти запись на страницах данных - данные физически организованы как часть индекса.

0

скажу, это занимает больше, чем 1 секунда

С индексом на userid, Mysql удастся найти правильную строку в (в худшем случае) Oh (log n). В секундах это зависит от производительности вашей машины.

Невозможно дать вам точный номер, не учитывая, как долго один операция занимает.

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

, например:

# records | # operations to find entry in worst case 
    2   1 
    4   2 
    8   3 
    16   4 
    ... 
    4096  12 
    ... 
    ~1 B  30 
    ~2 B  31 

Так, с огромным количеством записей - время практически остается постоянным. Для 1 миллиарда записей вам нужно будет выполнить ~ 30 операций.

И вот так оно продолжается: 2 миллиарда записей, 31 операция.

так, скажем, ваш запрос выполняется в 0.001 секунды для 4096 записей (12 OPS) это заняло бы Arround (0.001/12 * 30) 0.0025 секунд за 1 миллиард записей.

Heavy Sidenode: это просто с учетом выполнения сложности двоичного поиска, но она показывает, как сложность будет масштаб .

Вкратце: Ваша база данных будет не впечатлена запросом по индексированному значению. Однако, если вы выполняете большое количество этих запросов одновременно, увеличивается время c.

+0

Благодарим вас за ответ. Ваш ответ основан на сложности бинарного поиска. Однако для двоичного поиска требуется сортировка данных (в этом случае, после user_id). Что делать, если я ищу product_id? Использует ли sql некоторые сложные структуры данных, которые позволяют выполнять двоичный поиск в любом столбце? – Paul92

+0

@ Paul92 Это то, что индексы mysql предназначены для: всякий раз, когда вы создаете индекс в определенном столбце, mysql будет поддерживать отсортированный список столбца * that *, чтобы выполнить бинарный поиск на нем. Вот почему индексы быстро ищут, но замедляют вставки вниз (тогда индекс также должен быть обновлен). – dognose

+0

См. Также: http://dev.mysql.com/doc/refman/5.0/ru/mysql-indexes.html – dognose