ОК для создания таблиц данных MySQL в производственной среде

Question

Мне нужно создать MySQL tempory table в производственной среде.Таблица может содержать столбец, содержащий не более полумиллиона записей.Как правило, это будет около нескольких тысяч записей.

У меня есть несколько вопросов здесь

1. Можно ли создавать таблицы временных таблиц в среде рабочих серверов БД
2. Чтоэто может повлиять на производительность в том же сеансе клиента MySQL
3. Смогу ли я уменьшить влияние на производительность, если я буду хранить данные на диске, а не в памяти
4. Любые решения Elegent вместоэто

Answer 1

Как уже говорили другие, вы не предоставляете много контекста, поэтому "это зависит".

В общих чертах, создание таблиц и хранение в них данных - это то, для чего предназначена реляционная база данных. Будь то одна строка или миллионы, реляционные базы данных любят данных и действительно хороши в оптимизации хранения и доступа - очень маловероятно, что в этом вы сможете добиться большего успеха, чем MySQL.

Однако ... все серверы - в определенной степени - ограничены в ресурсах. Производственные серверы обычно имеют странные, непредсказуемые схемы использования; работы по согласованию на конец месяца, внезапные всплески активности от одного отдела или типа пользователя, отчеты запускаются по пятницам, реальный мир, похоже, не работает с предсказуемым графиком.

Опять же, в самых общих чертах, серверы баз данных, как правило, имеют кривые производительности "хоккейной клюшки" - до тех пор, пока вы не столкнетесь с какими-то узкими местами в ресурсах, время отклика значительно увеличится в зависимости от использования. Затем, когда вы сталкиваетесь с узким местом (обычно с ЦП, ОЗУ или доступом к диску), вы видите перегиб вверх, время отклика которого резко увеличивается.

Если ваш рабочий сервер близок к достижению этой точки узкого места во время одного из непредсказуемых пиков реального мира, то все, что вы добавляете на этот сервер (включая временную таблицу), может вызвать точку перегиба. Итак, спросите кого-то, кто понимает производственную среду, насколько сильно загружен рабочий сервер в часы пик.

Следующая проблема заключается в том, что создание и хранение данных, как правило, не является проблемой производительности, но может иметь место запрос данных (а медленные запросы связывают много ресурсов, которые могут повлиять на другие процессы и пользователей). Я предполагаю, что вы не просто храните данные, вы что-то делаете с ними; если это происходит медленно или требует значительных ресурсов, это может оказать ощутимое влияние. Настройте и оптимизируйте запросы (в отдельной среде!), Убедитесь, что ваш EXPLAIN показывает, что вы используете индексы для всего, а запросы возвращаются в миллисекундах, и вы вероятно окей.

Есть ли более элегантное решение? Да, вы можете переместить данные на отдельный сервер отчетов, где вы можете выполнять любую обработку, поддерживаемую вашей временной таблицей.

Answer 2

Извините, не может быть другого ответа, кроме "это зависит", поэтому ответ может быть только общим.

1. Приложения создают временные таблицы, когда они им нужны. Это нормальная практика и одна из причин существования временных таблиц. MySQL также создает их для некоторых операций.

2. Зависит от текущей рабочей нагрузки сервера и его возможностей (CPU / RAM / HDD).

3. Вряд ли. Вероятно, лучше всего позволить MySQL управлять ими; он автоматически преобразует таблицы временной памяти в таблицы дисков, когда становится недостаточно памяти (https://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-tablespace.html)

4. Зависит от специфики вашей проблемы. Как часто будут создаваться таблицы и как долго они будут сохраняться. Сама временная таблица может считаться элегантным решением, поскольку она позволяет хранить временные данные на одной стороне и избегать дополнительного копирования данных в / из приложения обработки.