Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Тема закрыта
Добрый день, появилась проблема с БД.
Мой SELECT возвращает данные в виде
id | text | tag_name
132 | Текст132 | Тэг1
132 | Текст132 | Тэг76
132 | Текст132 | Тэг43
Выглядел SELECT так:
Отредактированно slipkahh (01.05.2012 21:13:30)
Неактивен
Решением будет контролировать целостность всех номеров:
- создать новую колонку с уникальным номером допустим назовём её row_id,
- перекрутить к таблице триггер на удаление и добавление.
При добавлении, новой записи даем row_id = мах(row_id)+1
При удалении, тут посложнее : row_id удаляемой записи нужно присвоить последней записи, то есть получается самый большой row_id удалятся.
Ну а потом всё просто, с помощью php генерируем 10 чисел от 1 до мах(row_id) и делаем быстрый запрос
Отредактированно evgeny (01.05.2012 23:59:11)
Неактивен
Евгений, спасибо большое за ответ!
Смотрите какой вариант еще появился: возврат прямо-таки 10 чисел не обязателен, можно и +-3.
Делаю так: генерирую 10 чисел, далее вашим запросом с IN ( , , ... , ) выдергиваю записи, если в IN ( ... ) будет находится сгенерированый несуществующий ID, то mysql вернет не empty string, а просто пропустит этот id и вернет вместо 10 строк - девять.
Поэтому на прерывания в id можно закрыть глаза. Я прав?
Спасибо за внимание!
Неактивен
Всё попробовал, пока вроде неплохо работает.
Спасибо за FAQ, интересно!
Еще напомните пож, запрос SELECT .. WHERE id IN ( .. , .. , .. ) ORDER BY id не приведет случайно к фулскану? Что отработает первым WHERE или ORDER BY?
Неактивен
зависит от наличия индексов
сначала where
Неактивен
slipkahh написал:
Всё попробовал, пока вроде неплохо работает.
Спасибо за FAQ, интересно!
Еще напомните пож, запрос SELECT .. WHERE id IN ( .. , .. , .. ) ORDER BY id не приведет случайно к фулскану? Что отработает первым WHERE или ORDER BY?
Так что вы конкретно попробовали ?
slipkahh написал:
Смотрите какой вариант еще появился: возврат прямо-таки 10 чисел не обязателен, можно и +-3.
... а просто пропустит этот id и вернет вместо 10 строк - девять.
Так сколько конкретно вам случайных чисел надо получить 9 или 10 ? :-)
FAQ №9
Действительно более простое решение.
Опять же если вам надо вынуть не одно случайное число а 10, то вам придётся, доработать тот вариант.
Неактивен
evgeny, я запятую забыл. Это было "всё, попробовал" и относилось к посту #3.
Сейчас работает так: http://clip2net.com/s/1SSbI (блок с пхп инсайд)
Чем больше $max, тем больше вероятность, что вернет именно 12 записей. 12 записей нужны, чтобы не грузить сервер каждым запросом текста.
С удовольствием выслушаю комментарии по моему коду
@all Вы отлично консультируете! Спасибо еще раз.
Вопрос еще небольшой появился: как силами mysql выдернуть из базы тэги, содержащие подстроку, присланную post-ом.
Т.е. пример: в search-field вводится например "про", отправляется в .php скрипт, далее мне нужно сконфигурировать запрос, который выдернет все тэги, содержащие "про". Выдача в виде "проекты","прогнозы","гипротранс".
Наверное и сам бы разобрался какие функции использовать, но ваш совет бесценен в этом плане!
Неактивен
slipkahh написал:
evgeny, я запятую забыл. Это было "всё, попробовал" и относилось к посту #3.
Сейчас работает так: http://clip2net.com/s/1SSbI (блок с пхп инсайд)
Чем больше $max, тем больше вероятность, что вернет именно 12 записей. 12 записей нужны, чтобы не грузить сервер каждым запросом текста.
С удовольствием выслушаю комментарии по моему коду
Я и vasya предложили вам 2 точно работающих варианта.
Вы сделали мини кустарное подобие :-) При большом количестве удалённых строк оно будет фальшивить.
Если не хотите доделать до конца по FAQ №9,
чтоб сократить вероятность неудачных вариантов, добавите не 12 а допустим 20 id, и ограничите вывод в запросе с LIMIT 10;
slipkahh написал:
Вопрос еще небольшой появился: как силами mysql выдернуть из базы тэги, содержащие подстроку, присланную post-ом.
Т.е. пример: в search-field вводится например "про", отправляется в .php скрипт, далее мне нужно сконфигурировать запрос, который выдернет все тэги, содержащие "про". Выдача в виде "проекты","прогнозы","гипротранс".
Наверное и сам бы разобрался какие функции использовать, но ваш совет бесценен в этом плане! smile
Неактивен
ORDER BY RAND() не подходит по причине толстой таблицы.
А насколько быстро работает, если выбирать только id?
SELECT id
FROM ...
ORDER BY RAND()
Неактивен
LazY, по чесноку не знаю, начитался что ORDER BY RAND() загоняет всё во временную таблицу, разве нет?
В любом случае думается мне добровольно я уже не вернусь к этом вопросу, в скором времени допарсю базу до запланированных размеров. Если что-то интересное будет - поделюсь обязательно.
За ссылки спасибо, сделал слету так: SELECT tag_name FROM TAG_TABLE WHERE tag_name like '%Тэг%'
PS никто не сталкивался? http://clip2net.com/s/1SXZ7 Через navicat SELECT выводит как надо, а функция пхп упорно возвращает 0 строк и пустую выборку.
Отредактированно slipkahh (05.05.2012 22:20:20)
Неактивен
slipkahh написал:
PS никто не сталкивался? http://clip2net.com/s/1SXZ7 Через navicat SELECT выводит как надо, а функция пхп упорно возвращает 0 строк и пустую выборку.
Разные кодировки в php и в mysql, попробуйте слово на английском для проверки.
Неактивен
Да, конечно, не заметил, что файл в ansi. Благодарю!
Неактивен
начитался что ORDER BY RAND() загоняет всё во временную таблицу
Так и есть.
SELECT id FROM t.. ORDER BY RAND() LIMIT 10 - самое простое решение. Насколько оно применимо, определяется размерами таблицы в конкретной ситуации.
Например, на не особо мощном домашнем компьютере такой запрос для таблицы в сто тысяч строк выполняется менее одной десятой секунды. Для таблицы в полтора миллиона записей - уже полторы секунды.
Если, например, у вас 100k записей и 0.1 с вам подходит - можно использовать это простое решение.
Неактивен
LazY, вариант с IN ( .. , .. , .. ) отрабатывает сейчас за 0.04с , так что думаю вне конкуренции.
Кстати никогда не сталкивался с паданием сервера от нагрузки. Если запрос допустим обрабатывается 0.1с и в секунду приходит более 10 запросов, что происходит с остальными запросами? Просто выкидываются из очереди?
Неактивен
На перегруженном сервере запросы встают в очередь, соединение, через которое послан запрос, остается открытым, пока он не завершится, либо отваливается по тайм-ауту.
Количество одновременных соединений ограничено, и когда число единовременно открытых соединений сравнивается с ограничением, "свободных мест" для новых соединений не остается, и следующему клиенту сервер БД просто отвечает отказом и никакие запросы даже не начинают выполняться.
Неактивен
Еще вопрос появился. Решил привести табличку в порядок, наткнулся на непонятное что-то.
Запрос:
Отредактированно slipkahh (12.05.2012 00:23:34)
Неактивен
Тема закрыта
Страниц: 1