Краткое описание: Есть ли способ улучшить производительность сканирования таблиц в таблицах InnoDB?
Пожалуйста, не предлагайте добавлять индексы к избегать сканирования таблиц.(см. ниже)
innodb_buffer_pool_size находится на 75% памяти сервера (48 ГБ / 64 ГБ). Я использую последнюю версию Percona (5.7.19), если это что-то меняет
Дольше:У нас есть 600 Гб данных последних временных рядов (мы объединяем и удаляем старые данные), распределенных по 50-60 таблицам.Так что большинство из них - «активные» данные, которые регулярно запрашиваются.Эти таблицы несколько большие (более 400 числовых столбцов), и многие запросы выполняются по ряду этих столбцов (тревожно), поэтому нецелесообразно добавлять индексы (как мы должны были бы добавить несколько десятков).Самые большие таблицы разбиваются на разделы в день.
Я полностью осознаю, что это проблема разработки приложения / таблицы, а не проблема "настройки сервера".В настоящее время мы работаем над тем, чтобы значительно изменить способ составления и запроса этих таблиц, но мы должны поддерживать существующую систему до тех пор, пока это не произойдет, поэтому я ищу способ немного улучшить вещи, чтобы выиграть нам немного времени.
Недавно мы разделили эту систему и перенесли ее часть на новый сервер.Ранее он использовал MyISAM, и мы попытались перейти на TokuDB, что казалось уместным, но столкнулось с некоторыми странными проблемами.Мы перешли на InnoDB, но производительность действительно плохая.У меня складывается впечатление, что MyISAM лучше справляется со сканированием таблиц, поэтому, за исключением любого лучшего варианта, мы вернемся к нему, пока не будет установлена новая система.
Обновление
Все таблицыимеют почти одинаковую структуру: -timestamp -primary key (поле varchar (20)) -по 15 полям различных типов, представляющих другие вторичные атрибуты, по которым можно фильтровать (вместе с сначала соответствующим образом проиндексированными критериями) -и затем о несколькихсто мер (с плавающей точкой), между 200-400.
Я уже обрезал длину строки настолько, насколько мог, не меняя саму структуру.Первичным ключом был varchar (100), все меры были двойными, у многих вторичных атрибутов были изменены типы данных.
Обновление оборудования на самом деле не вариант.
Создание небольших таблиц с нужным мне набором столбцов поможет некоторым процессам работать быстрее.Но за счет создания этой таблицы с помощью сканирования таблицы и дублирования данных.Может быть, если бы я создал его как таблицу памяти.По моей оценке, это займет пару ГБ от буферного пула.Кроме того, существуют процессы агрегации, которые регулярно читают столько же данных из основных таблиц, и им нужны все столбцы.
К сожалению, в тех запросах, к которым я планирую обратиться, много дублирования.следующая версия.Тревожные процессы и процессы агрегации в основном обрабатывают данные за весь день каждый раз, когда вставляются некоторые строки (каждые полчаса), вместо того, чтобы просто работать с новыми / измененными данными.
Как я уже сказал, большие таблицы разбиваются, поэтомуэто обычно сканирование ежедневного раздела, а не всей таблицы, что является небольшим утешением.
Реализация системы для хранения этого в памяти вне БД может работать, но это повлечет за собой множество измененийустаревшая система и разработка.Можно и потратить это время на лучший дизайн.
Тот факт, что таблица InnoDB намного больше для тех же данных, что и MyISAM (в 2-3 раза больше в моем случае), действительно снижает производительность.