Форум пользователей MySQL

Мне необходимо сделать алгоритм выборки/сравнения 3000 наименований в секунду из 50000 наименований бд по имени. Линейный поиск тут не уместен, для этого лучше всего подходит бинарный поиск, то есть мы каждый раз не найдя нужные данные будем сокращать поиск в 2 раза, но для этого необходим отсортированный массив в алфавитном порядке, а id нужны для того, что бы можно было обращаться к нужным ячейкам таблицы при поиске.

Предположим у нас есть в таблице 9 значений:

id  name
0     a
1     b
2     c
3     d
4     e
5     f
6     g
7     h
8     i



Нам необходимо найти g, мы берем и делим нашу область поиска на 2 и получаем e, далее сравниваем если e < g, то нам нужно поделить вторую половину на 2 (делим вторую половину на 2 и вот мы уже нашли g), если к примеру в другом случае e > g, то делим первую половину на 2 и так далее пока не найдем нужное значение. (еще бывают исключения, зависит от четности значений)

Отредактированно KenAlcapone (15.04.2017 21:22:33)

Вот я и не могу понять как сделать индекс в таблице для текстовых значений

Индексы есть не только для целых чисел, но и для любых (почти) типов данных.
Но ими нужно разумно пользоваться. Неразумное использование индексов может привести к потере производительности и росту размеров БД. Но, скорее всего, это не в Вашем случае. 50К это для любой СУБД незначительная нагрузка.

Вместо 'h' подставляете, что Вам нужно.

Отредактированно klow (15.04.2017 22:00:11)

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

ой чет я тут жестко тупанул, можно же ведь использовать select * from test таким образом останавливаться на нужном id , спасибо за помощь

появилась еще одна довольно серьезная проблема, добавление в бд 100 значений занимает 5 сек ($sql="INSERT INTO test1 (id, name) VALUES('','$string')", далее стал экспериментировать, сделал цикл на добавление 10000 записей, зашел в phpmyadmin и увидел, что записи постепенно добавляются, подумал, что из за индексирование mysql не справляется и на сервер огромная нагрузка, но оказалось все иначе, на процессор и оп не было нагрузки даже в 1%, чекал через top на debian.

Если выбрать тип таблицы myISAM или memory, тогда добавление 100 записей занимает 0.008 сек. как и нужно, но в этом случае перестает работать индексирование по полю name.

Отредактированно KenAlcapone (16.04.2017 12:35:34)

Создавал через интерфейс phpmyadmin -



похоже дело даже не в индексе по полю name, создал новую таблицу example как на скрине и стал заполнять по 100 записей, в итоге это заняло те же 5 сек.

Если добавлять те же 100 записей одним запросом запрос проходит за 0.34 сек




Если изменить тип таблицы на myISAM, тогда те же 100 записей при добавлении по одной заносятся всего за 0.01 сек вместо 5, но при добавлении индекса через - ALTER TABLE example ADD INDEX IDX_example_name (name); он не работает с myISAM и Memory, он успешно добавляется но свои действия не выполняет по сортировке, если сменить тип на innoDB, тогда начинает работать

Отредактированно KenAlcapone (17.04.2017 14:29:28)

Нашел в чем была причина, логи записывались напрямую в пзу, исправил на innodb_flush_log_at_trx_commit = 2, теперь 100 insert'ов занимают по времени 0,22сек вместо 5сек , только вот все же не понятно почему не работают индексы в MYISAM и MEMORY таблицах.

К примеру вот так с myisam индексы уже не работают -

Хотел сказать, что не работает сортировка по индексу вот отличия

если вы не указываете order by, то можете получить результат в непредсказуемом порядке
и в примере с тем же innodb, завтра при ином положении звезд результат может быть другой.

KenAlcapone написал:

Точно они в обоих случаях находятся в алфавитном порядке по полю name, их просто по разному выводит

если под они вы подразумеваете порядок хранения строк на диске, то то не так
бд это просто куча и такое понятие как первая или последняя строка в ней отсутствует
и если вы не указываете order by, то результат непредсказуемый
что касается отличия в поведение InnoDB и в MyISAM, то они по разному хранят данные внутри себя