Сложность времени сортировки базы данных

Question

В настоящее время я разрабатываю мобильное приложение и использую Codeigniter MySQL. Теперь я столкнулся с ситуацией, когда у меня есть таблица книг (эта таблица будет 100k + с записями). В этой таблице у меня есть столбец NotSelling. Пример db:

Book A 45 
Book B 0 
Book C 159 
Book D 78 
. 
. 
. 
Book Z 450 

Где выше цифры - это то, что появляется в столбце NotSelling в db. Мне нужно извлечь 20 лучших книг из этой большой таблицы. Теперь мое решение для этого - сортировать таблицу, а затем просто использовать TOP, чтобы извлечь 20 лучших записей.

Что я хотел бы знать о производительности сортировки таблицы. Поскольку я уверен, что постоянно сортировать таблицу, чтобы получить лучшие 20 результатов, это займет довольно долгое время. Мне были даны решения проблемы:

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

Но все ли сказано, что кто-нибудь знает о лучшем решении этой проблемы или имеет способ/способ оптимизации производительности функциональности, которую я ищу? Заметьте, что я новичок, поэтому кто-нибудь сможет указать мне в правильном направлении, где я могу прочитать о производительности базы данных. Я бы очень признателен.

Answer 1

Думаю, вы слишком много думаете здесь. Определенно случай преждевременной оптимизации. Несмотря на то, что все вышеупомянутые решения совершенно верны. Вы должны знать, что записи 100K + являются похмелье для Mysql. Мы обычно использовали order на столах с 30 миллионами + строк, с отличным перфомансом.

Но у вас ДОЛЖЕН иметь индекс для сортируемого столбца и дважды проверить схему таблицы. Рег. Кэширование тоже не волнуется, mysql делает это для вас для повторяющихся запросов, когда таблица не изменилась. Но индекс по столбцу является обязательным, основным и наиболее важным требованием.

Answer 2

Не беспокойтесь о производительности сортировки. Это может быть исправлено в базе данных позже, добавив индекс, если это действительно окажется проблемой.

На этапе проектирования оптимизация является отвлечением. Вместо этого сосредоточьтесь на функциональности и прямоте, что реализация представляет проблему. Пока они нацелены, все остальное можно устранить сравнительно легко.

Answer 3

В зависимости от того, какие метаданные хранятся внутри структуры данных индекса, поддерживающего столбец, обход может быть выполнен в O (n) раз, когда n - это количество возвращенных элементов.

Это означает, что теоретически, есть ли у вас 1 миллион или 200 триллионов записей, вытаскивание первых 20 будет таким же быстрым, пока у вас есть индекс. На практике будет разница в производительности, так как небольшой индекс будет соответствовать памяти, а большой - дискам.

Итак, вы слишком беспокоитесь. Как Srikar Appal, правильно проиндексированная столовая таблица 100k ничего не представляет для MySQL