таблица около 10 млн записей, в неё постоянно происходят вставки и обновления, а так же постоянный select к ней с фильтрацией по разным набором полей (вот тут и проблемы), индексы делал простой, составной, mysql просто отказывается брать необходимый индекс и берет не эффективный, использовать use index такое себе решение наверное (по крайней мере при одних запросах быстро, при других уже нужен другой индекс и угадать селективность сложно и покрыть все комбинации). Может кто сталкивался, аналогия - таблица todo постоянная фильтраций по диапазаону (партишены по дате тоже пробовал), представим что надо назначать задачу кому-то и в этих задачах искать по статусам и другим параметрам
Если дажэ тебе трудно угадать — то куда уж мысклю-то!
Давай опрееделение таблицы (таблиц), и запрос, потом может ещё что-то спрошу...
Пока сказать могу, что для КАЖДОГО запроса надо индекс подбирать отдельно. Т.е. любое сочетание поисковых аргументов — отдельно.
Дело в том что - если я создаю индекс на свой поисковый запрос, то он отказывается иногда его использовать и берет другой менее эффективный, вот ddl таблицы create table if not exists _tasks ( id int unsigned auto_increment, export_id int unsigned not null, client_id int unsigned not null, department_id int unsigned default '0' not null, operator_id int unsigned default '0' not null, status smallint unsigned not null, created_at timestamp not null, updated_at timestamp not null, primary key (id, created_at) ) partition by range(unix_timestamp(`created_at`)) ( partition `2020m11` values less than (1604178000), partition `2020m12` values less than (1606770000), partition `2021m1` values less than (1609448400), partition `2021m2` values less than (1612126800), partition `2021m3` values less than (1614546000), partition max values less than (MAXVALUE) ); create index _tasks_operator_id_department_id_status2_created_at_index on _tasks (operator_id asc, department_id asc, status asc, created_at desc); create index _tasks_created_at_index on _tasks (created_at desc); из таблицы видно что есть отделы и операторы, статусы задач и поле created_at по которому фильтруется диапазон, тут еще не хватает company_id, т.к. у каждой компании есть свои задачи (это поле добавится скоро). если искать строго по составному ключу все ок, как только начинается выбирать другой порядок (например не выбирать оператора и департамент), индекс не используется что логично, начинаю добавлять по оператору и дате создания create index _tasks_operator_id_created_at_index on _tasks (operator_id asc, created_at desc); запускаем, но он почему-то не хочет использовать этот индекс и тормозит (использует _tasks_created_at_index), пишу use index _tasks_operator_id_created_at_index полетел.. потом кейс: поиск еще по статусу и тут уже тормозит, создаю еще один составной индекс create index _tasks_operator_id_status_created_at_index on _tasks (operator_id asc, status asc, created_at desc); здесь без use index определил нормально индекс и отработал, ну и какое количество индексов должно быть, нужно ли в коде в зависимости от фильтров ему явно говорить use index ? запрос на всякий (период специально выбрал большой - но на самом деле там всего 6 месяцев тестовых данных, с ростом сотрудников и компаний объем записей за месяц а может и за неделю будет равен тому что за 6 месяцев) select tk.id, tk.export_id, tk.phone_id, tk.department_id, tk.operator_id, tk.status from `_tasks` as tk where 1 = 1 and tk.`operator_id` = 17 and tk.`status` = 1 and (tk.`created_at` >= '2018-02-01 00:00:00' and tk.`created_at` <= '2021-05-01 23:59:59') order by tk.`created_at` desc limit 100 offset 0
да я тоже думал про кликхаус, но решил задать вопрос, может в рамках mysql это все разруливается
А записей сколько за шесть месяцев?
Ты чё, ебанулся? Какой тут индекс ещё?
Нахера тебе столько в наборе?
"я ставлю индекс, а он неэффективный, его мускль не берет".... Конечно
в любом случае задач все равно 10 млн или предлагаете резать её на несколько таблиц по отделу по статусу и т.д. ?
Не предлагаю, я тебе и партии убрать предлагаю.
В общем, мой дар речи пропал до утра...
Обсуждают сегодня