Мне будет нужно больше системных ресурсов для выполнения DB2 вместо MySQL?

вы используете isam или innodb?

обычно DB2 требует меньше системных ресурсов, чем текущие версии mysql. однако, если вам нужна производительность и размер баз данных не слишком велик, вы можете действительно захотеть переключиться на postgresql, поскольку он значительно менее «функциональный» (читай: раздутый), чем mysql . иногда вам НУЖЕН mysql, но если нет, лучше использовать pgsql.

Я не думаю, что это будет иметь большое значение, если вы запустите mysql или DB2. Однако вы не будете уверены в производительности, если не попробуете это сами. Я рекомендую вам попробовать его в тестовой среде, аналогичной вашей текущей системе.

DB2 должна достаточно эффективно использовать память на сервере, если вы оставите включенной функцию самонастраивающегося управления памятью (STMM) при условии, что процессы вне DB2 выделяют и освобождают свою память в воспитанная манера поведения. STMM регулирует размер нескольких высокоэффективных буферов и куч памяти, чтобы приспособиться к постоянно меняющейся рабочей нагрузке базы данных. Эта функция была включена по умолчанию для последних двух основных выпусков DB2 и обычно имеет настройки памяти, которые почти идентичны настройкам базы данных, вручную настроенным экспертом по DB2. Одно из предостережений относительно STMM заключается в том, что ему запрещено конструктивно совершать резкие колебания в размерах своей памяти, а это означает, что STMM может потребоваться внести несколько дополнительных корректировок, чтобы приспособиться к резкому скачку или падению использования базы данных. DB2 предлагает множество встроенных функций мониторинга, которые помогут вам отслеживать эффективность и закономерности роста структур внутренней памяти, чтобы вы могли быстро получить представление о том, как «нормально» выглядит для конкретной рабочей нагрузки.

На стороне ЦП , одним из самых больших рисков для хорошей производительности и масштабируемости является сканирование, которое сжигает циклы ЦП, даже если все необходимые страницы данных уже кэшированы в памяти буферного пула. Понимание того, как работают индексы и когда они будут использоваться или игнорироваться для определенных операторов SQL, особенно важно по мере роста таблиц и расширения запросов. Иногда неприемлемое сканирование происходит не из-за плохого индексирования или плохих предикатов соединения, а из-за того, что количество элементов таблицы и статистика распределения, собранная RUNSTATS, устарела, что вводит в заблуждение DB2 ' Оптимизатор запросов на основе затрат недооценивает последствия использования частичного или полного сканирования. Утилита db2expln покажет план доступа для предложенного запроса с учетом текущей статистики. Во время выполнения также можно отслеживать количество прочитанных (отсканированных) строк по сравнению с фактически выбранными, что может дать вам представление о том, сколько происходит отток, чтобы получить наборы результатов для вашей рабочей нагрузки.