Ответы пользователя по тегу MySQL
  • Поиск большого количества записей в mysql

    archibaldtelepov
    @archibaldtelepov
    1. какой процент слов для поиска в массиве от общего количества записей?
    2. Если меньше 1% (я не помню, до какого значения использование индекса актуально), то может сделать двухходовую комбинацию вида:

    1) создать таблицу временную с одной колонкой
    2) залить в неё массив
    3) выбрать все, что надо, написав JOIN созданной временной таблицы с основной, по которой ищем, содеинив их по значению поля word?
    Ответ написан
    Комментировать
  • Логика выполнения 2х селектов в MySQL

    archibaldtelepov
    @archibaldtelepov
    Кроме того, no_cache это интересно, но в первом запросе могут быть ещё данные только на диске.
    а во втором запросе может оказаться так, что данные уже в кэше дисковой подсистемы, например

    Попробуйте выполнить запросы на свежем сервере в обратном порядке?
    Ответ написан
    Комментировать
  • Архитектура БД для фильтров аналог Яндекс Маркета?

    archibaldtelepov
    @archibaldtelepov
    Да, конечно.

    начну с конца. value — чтобы выбирать по числовому идентификатору и чтобы для свойства «цвет крышки» хранился номер 100, а не где-то слово «белый», а где-то «белий» ну и т.п.

    далее, в интерфейсе подбора по параметрам человек выбирает «а покажите мне все продукты, у которых объём жесткого диска 2 гб, а ширина экрана 100 метров».

    выбираем продукты

    select distinct p.name,p.code,p.price from
    product p inner join product_property_value ppv using (product_id)
    where
    ppv.property_id = HDD_SIZE_PROPERTY_ID and value_id = VID_100GB
    and ppv.property_id = SCREEN_SIZE_PROPERTY_ID and value_id = VID_100M


    при наличии индекса ppv(property_id, value_id) должно работать быстро

    тут, конечно, возникает разумный вопрос — а что делать с запросами типа «ширина монитора больше 17 дюймов».

    на что возникает резонный ответ — если у нас есть такие запросы, у нас есть несколько вариантов:

    1) не париться, и добавлять в приведённый выше запрос таблицу value, для которой построен индекс по полю value

    select distinct p.name,p.code,p.price from
    product p inner join product_property_value ppv using (product_id)
    inner join value v on v.value_id = ppv.value_id
    where
    ppv.property_id = SCREEN_SIZE_PROPERTY_ID and v.value > VID_17IN


    2) делить таблицу value на, скажем, три

    value_int для целых значений
    value_string для текстовых
    value_decimal для нецелых значений

    в таблицу property мы добавляем признак типа значений свойства и на этапе построения приведённого выше запроса соединяем с требуемой таблицей

    из всего этого видим мы, что основная проблема — это выборки по диапазонам, так?
    а выборки по одному или нескольким значениям нормально решаются с помощью value_id

    3) следующий способ оптимизации по скорости:
    для всех значений, для которых возможна выборка по диапазону
    мы добавляем в property поля
    max_value_id и min_value_id
    указывающие на идентификатор ряда в value, в котором хранится максимальное и минимальное значение свойства соответственно.

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

    при использовании такого подхода можно выбирать с помощью конструкции value_id between даже при поиске по диапазону значений и не лазать в таблицу value при выборках, что добро
    Ответ написан
  • Архитектура БД для фильтров аналог Яндекс Маркета?

    archibaldtelepov
    @archibaldtelepov
    А чем не устраивает стандартное реляционное решение вида

    product (product_id [PK], name,… );
    property (property_id [PK], name, ...);
    value (value_id [PK], value);
    product_property_value (product_id, property_id, value_id, primary key (property_id, value_id, product_id, ));

    или есть какие-то данные, которые показывают, что на ваших объёмах оно будет тормозить?

    на одном интернет-проекте на 250 000 активного ассортимента и 60 000 уникальных посетителей в сутки не тормозит особо.
    Ответ написан