Влияет ли размер соседней таблицы в базе данных MySQL на скорость выполнения запросов к отдельной небольшой таблице?

Question

[Хостинг Ярославль]

Влияет ли размер соседней таблицы в базе данных MySQL на скорость выполнения запросов к отдельной небольшой таблице?

Есть ли смысл разбить проект на 3 БД:

• Рабочая база
  
• Логи
  
• Статические большие данные (справочники)
  

Даст ли это прирост производительности или каждая таблица в отдельности не зависит от ее соседей в БД?

Answer 1

[Fixid]

Влияние не прямое. Таблицы не зависимы друг от друга. Они даже физически хранятся обычно в разных файлах, как и индексы. (в зависимости от типа хранилища)
Тут скорее будут влиять параллельные запросы к другим таблицам за счет потребления общих ресурсов.
Поскольку на весь инстанс выделено определенное место в озу для кэша запросов и индексов.

Comments

[ponaehal]

Действительно? в MySQL на каждую таблицу отдельный файл данных?

[Fixid]

ponaehal, в зависимости от типа хранилища

[Fixid]

ponaehal, например InnoDB по дефолту хранит данные в одном файле-хранилище ibdata (которых может быть несколько), но можно принудительно указать хранить одну таблицу в одном файле.
В MyISAM на каждую таблицу приходится три файла: FRM, MYI и MYD

Никто не запрещает использовать в пределах одной Бд разные типы хранилищ для разных таблиц

[Владимир]

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

[ponaehal]

Владимир, Fixid Спасибо! не знал, что так можно. А у вас есть понимание в каких случаях это целесообразно? Все равно, при запросе эти таблицы нужно прочитать с физического диска.... Параллелить наверное получится только если они расположены на разных дисках?
Сорри за глупые вопросы, с MySQL не работал - просто тема зацепила))

[Fixid]

ponaehal, Все немного не так.
С диска база читается только когда этих данных нет в памяти.
В память эти данные могут попасть двумя способами:
1. Сама ОС закэширует сами физические файлы с диска в свободную память, но тут же удалит если эта память кому то понадобится
2. Вы говорите самой БД, что ей под кэш выделено например 1гб под данные и 100мб по индексы, и дальше база уже сама думает как оптимальнее использовать доступное место в ОЗУ. При это БД отбирает это место у ОС и теоретически может вытеснить файловый кэш.

Когда приходит запрос к БД (крайне упрощенно и в реальности порядок может быть немного другой):
1. Идет обращение к индексу (если он есть.):
1.0. Ищем такой запрос в кэше запросов (можно кэшировать простые запросы вместе с данными ответа и никуда не ходить)
1.1. Ищем в кэше, если нету идем на диск и читаем с него (но ОС может отдать этот файл из ОЗУ если он был ею закэширован, БД будет думать что читает с диска)
1.2. Понимаем где взять эти данные и идем на диск. Читаем нужный кусок файла и отдаем его.

ОС любит кэшировать мелкие файлы к которым часто обращаются.

[ponaehal]

Fixid, Да я это понимаю. В целом порядок работы с диском/памятью такой же как например в Oracle. Я имел ввиду случай когда данные не в памяти, а на диске. В чем профит разбиения таблиц по файлам?

[Fixid]

ponaehal, разбиение/не разбиение на отдельные файлы это требование storage engine и обычно ничего более. Единственная гипотетическая фича, что можно хранить отдельные файлы на отдельных дисках. Но это bad practice, для этого придумали RAID

[Владимир]

ponaehal, для сферичского сервера mysql в вакууме: файл ibdata один большой и у него почти нет шансов быть закешированным ОС, файлы таблиц намного меньше поэтому вероятность того что файл таблицы будет закешированн ОС и этот файл доживет в кеше до следующего запроса к нему намного больше, если хотябы одно чтение было из кеша а не с диска - уже хорошо.

Answer 2

[Олег]

- У Вас свой физический сервер ?
- VPS ? А какая виртуализация ? Насколько жадный хостер ? Приблизительный оверселед ?
- Шаред ?

В общем все сводиться к тому . Будут ли нужные данные фактически в физической оперативной памяти на момент запроса.

Смысл шаманить со структурой базы данных есть только в случае дедика. Но там проще доставить ОЗУ.