Что быстрее индекс по varchar(255) или индекс по int(11)

Тема в разделе "Базы данных", создана пользователем babahalki, 18 окт 2017.

Модераторы: latteo
  1. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    244
    Симпатии:
    87
    Привет, друзья.
    Решаю практическую задачу по оптимизации структуры БД. Делаю часть БД, касающуюся свойств товаров.
    Что будет быстрее работать для
    Код:
    select col from table where col in (............)
    Если col будет varchar(255) или int(11)?
     
  2. CAPAXA

    CAPAXA

    Регистр.:
    7 июн 2007
    Сообщения:
    955
    Симпатии:
    568
    Естественно int, и места индексы будут занимать гораздо меньше. Но вот на счет IN, на сколько мне известно, то мускуль не поддерживает индексы в данной конструкции.
     
    babahalki нравится это.
  3. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    244
    Симпатии:
    87
    спасибо, буду копать в эту сторону.
    Тут посерьезнее проблема вылезла, был вариант со множеством left join сделать, вот тут точно без индексов получилось. Концепция множественности таблиц вообще неработоспособная выходит.
    Получается вариант с наименьшим кол-вом джоинов - делать все в 1 таблицу. 64 индекса мускуль разрешает, должно хватить.
     
  4. Black Hat

    Black Hat

    Регистр.:
    15 май 2015
    Сообщения:
    155
    Симпатии:
    101
    Плохой вариант.
    Похоже вы еще один, кто не знает как работают индексы.
    1. Почитайте про покрывающие и составные индексы
    2. Почитайте, почему много индексов - плохо. Со слов "не надо увлекаться созданием большого количества индексов" https://habrahabr.ru/company/mailru/blog/266811/
    3. Почитайте, что такое профилирование запросов, и как их оптимизировать

    А смотря в каких случаях. Вот положительный пример: у вас есть база пользователей, 1 млн штук. В среднем одна регистрация каждые 10 минут. "Логинятся" на сайте каждые 10 секунд.
    Если время последнего логина писать в ту же таблицу, кеш запросов к этой таблице будет в среднем жить 10 секунд, так как любое обновление таблицы его сбрасывает. А если вынести в отдельную таблицу, и ее джойнить в некоторых местах - некоторые запросы к таблице пользователей будут жить до 10 минут.
    Гуглить по "вертикальное партиционирование"
     
    latteo и babahalki нравится это.
  5. CAPAXA

    CAPAXA

    Регистр.:
    7 июн 2007
    Сообщения:
    955
    Симпатии:
    568
    Я на кеш мускуля ставки бы не делал. Он в большей части вреден, чем полезен.
     
    babahalki нравится это.
  6. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    244
    Симпатии:
    87
    Я на кеш не рассчитываю, потому что повторяющиеся запросы будут достаточно редкими, почти все будут уникальными. Задача в том, чтобы заставить систему выполнять эти запросы максимально быстро.

    Сделаю так:

    s_products
    id int(11)
    name varchar(512)

    s_features
    id int(11)
    name varchar(256)

    s_values_uniq
    id smallint(6)
    value varchar(512)

    s_options
    product_id int(11)
    1 smallint(6)
    2 smallint(6)
    3 smallint(6)
    .
    .

    Типичный запрос на получение товаров с определенными свойствами и сразу самих товаров.
    Код:
    SELECT o.product_id, o.1, o.2, o.3
    FROM s_options o
    WHERE 1
    AND o.1 = '12' AND o.2 = '10' AND o.3 = '1023'
    
    Потом построчно проходим все записи из выборки и раскладываем все поля по отдельным массивам, фильтруя повторы и NULL, и заменяя значения id на значения из таблицы c уникальными значениями из таблицы s_values_uniq.

    В итоге 1 выстрел и 2 зайца, у нас есть id нужных товаров, а также значения свойств соответствующие этим товарам.

    Но идея с хранением в 1 супер таблице мне не нравится, какой-то большой excel получается. Интересно как хранит данные яндекс маркет?
     
  7. Black Hat

    Black Hat

    Регистр.:
    15 май 2015
    Сообщения:
    155
    Симпатии:
    101
    1. Сразу указывайте в колонках NOT NULL - по возможности. Обработка колонок, в которых может быть NULL - дольше.
    2. Вы изобретаете то, что называется EAV. Для самообразования это хорошо. На небольших данных будет отлично работать, какую бы схему не придумали. На больших - ну как сделаете. Я бы заранее подготовил данные, скажем 1 млн товаров, чтобы посмотреть как будет работать. А также несколько вариантов фильтрации. И тогда на этом можно начать "обкатывать".
    ХЗ, не буду говорить что не знаю.
    Алиэкспресс раньше использовал MySQL. Яндекс почта - на PostgreSQL. Яндекс метрика - кликхаус.
    У постгреса гораздо больше фич, чем у мускула. Например - поиск по JSON. Ну в Mysql эту фишку тоже впилили в версию 5.7, что относительно недавно. Можно и без таблиц искать, сразу по JSON. Единственное - сколько у вас товаров?

    Также для поиска по характеристикам можно использовать фасетный поиск на основе Sphinx + его тип - MVA. Его главный разработчик в одном докладе так и сказал - все БД хороши для хранения и транзакций. А для поиска - не очень. Сфинкс покрывает эту задачу.
     
    babahalki нравится это.
  8. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    244
    Симпатии:
    87
    Делаю форк уже имеющейся CMS. Самообразование - побочный эффект. Нужна рабочая система в итоге. Товаров примерно 100 тыс.

    За полтора года набралось некоторое количество мелких твиков, которые сейчас пытаюсь собрать во что-то более цельное.

    https://www.nulled.cc/threads/291347/
     
  9. bleakas

    bleakas Писатель

    Регистр.:
    13 мар 2017
    Сообщения:
    7
    Симпатии:
    1
    100к товаров немного, даже если таблицу плохо сделать без индексов будет работать за норм время. Если товаров больше ляма, вот тогда нудно беспокоится. ( если конечно у вас используется hdd, то нужно хорошо продумать индексы)