Size: a a a

2020 November 13

IZ

Ilia Zviagin in MySQL
Open Source
Скажем у TimeWeb вроде как у тебя 2 VDS не обьеденены в одну сеть. Не знаю есть ли такая опция у Azure
Если ты о скорости передачи данных между хостами А и В, то да, она должна быть хорошей.

Но скорость работы современных сетей сравнима со скоростью работы дисковых подсистем (не  SSD правда).
источник

OS

Open Source in MySQL
@MasterZiv

Кстати дико извиняюсь, не колотите ногами, видимо что то пропустил в мат. части когда учился.

Есть ли простое обьяснение почему LEFT JOIN в кол-ве 1шт. и допустим еще 2 просто JOIN - работают быстрее нежели 3 LEFT JOIN

На LEFT подключение расходуется больше внутренних операций?
источник

🇻

🇻 🇱 🇦 🇩 in MySQL
Ilia Zviagin
Потому что у любой СУБД 2 фактора, определяющие производительность:
Индексы и кэш.

Кэш - это память, занятая под данные.
Поскольку на хосте должна работать только СУБД и ос, 90% надо отдать под СУБД.
не только. важно еще расположение данных на диске
источник

IZ

Ilia Zviagin in MySQL
Влад
А если появится много пользователей, допустим 1000 человек, то что произойдет с БД?

Просто мы боимся что если она при старте уже ест всю память, то если придут люди на сайт, то БД  сразу ляжет, т.к. свободной сейчас осталось 10% озу
Ну я не могу на вашу систему отвечать, что там с ней будет, но в общем вам надо посчитать вашу конфигурацию железа и вашу нагрузку так чтобы суммарно MySQL в любой нагрузке не занимал более 80-90% ОЗУ.

На сайте MySQL можно найти статьи по конфигурации.

Могу также сказать, что с появлением пользователя на него тратится относительно мало памяти, основной объем ОЗУ идёт на кэш данных (innodb buffer cache) и рабочую память СУБД.
Так что очень сильно оно не вырастет
источник

IZ

Ilia Zviagin in MySQL
Open Source
@MasterZiv

Кстати дико извиняюсь, не колотите ногами, видимо что то пропустил в мат. части когда учился.

Есть ли простое обьяснение почему LEFT JOIN в кол-ве 1шт. и допустим еще 2 просто JOIN - работают быстрее нежели 3 LEFT JOIN

На LEFT подключение расходуется больше внутренних операций?
Это просто враньё.
Ничего не работает быстрее
источник

OS

Open Source in MySQL
Ilia Zviagin
Это просто враньё.
Ничего не работает быстрее
Видимо особенность моих таблиц) Не однократно просто подобное наблюдаю)
источник

IZ

Ilia Zviagin in MySQL
Open Source
@MasterZiv

Кстати дико извиняюсь, не колотите ногами, видимо что то пропустил в мат. части когда учился.

Есть ли простое обьяснение почему LEFT JOIN в кол-ве 1шт. и допустим еще 2 просто JOIN - работают быстрее нежели 3 LEFT JOIN

На LEFT подключение расходуется больше внутренних операций?
На left расходуется ровно столько же операций что и на аналогичный inner join
источник

В

Влад in MySQL
Ilia Zviagin
Ну я не могу на вашу систему отвечать, что там с ней будет, но в общем вам надо посчитать вашу конфигурацию железа и вашу нагрузку так чтобы суммарно MySQL в любой нагрузке не занимал более 80-90% ОЗУ.

На сайте MySQL можно найти статьи по конфигурации.

Могу также сказать, что с появлением пользователя на него тратится относительно мало памяти, основной объем ОЗУ идёт на кэш данных (innodb buffer cache) и рабочую память СУБД.
Так что очень сильно оно не вырастет
А можете еще сказать, если мы возьмем другую БД, к примеру postgres, она так же использует 80-90% памяти?
Или это фишка mysql?
источник

OS

Open Source in MySQL
Хорошего вечера, пойду отвлекусь от работы :)
источник

OS

Open Source in MySQL
Ilia Zviagin
На left расходуется ровно столько же операций что и на аналогичный inner join
Спасибо
источник

IZ

Ilia Zviagin in MySQL
Open Source
Видимо особенность моих таблиц) Не однократно просто подобное наблюдаю)
Это эффект ощупывания слепым слона .
Слон круглый и теплый
источник

IZ

Ilia Zviagin in MySQL
Влад
А можете еще сказать, если мы возьмем другую БД, к примеру postgres, она так же использует 80-90% памяти?
Или это фишка mysql?
СУБД использует (обычно) ровно столько памяти, сколько ей ВЫДЕЛЯТ.
80-90% - это сколько НУЖНО ВЫДЕЛИТЬ,а не сколько она сама берёт.
источник

IZ

Ilia Zviagin in MySQL
Влад
А можете еще сказать, если мы возьмем другую БД, к примеру postgres, она так же использует 80-90% памяти?
Или это фишка mysql?
Любую СУБД надо настраивать, сколько ей выделять памяти,  никто там сам никогда ничего не ест.

Есть конечно режима работы когда ты говоришь "жри сама сколько хочешь", но обычно в таких режимах СУБД себя контролирует.
источник

В

Влад in MySQL
Ilia Zviagin
Любую СУБД надо настраивать, сколько ей выделять памяти,  никто там сам никогда ничего не ест.

Есть конечно режима работы когда ты говоришь "жри сама сколько хочешь", но обычно в таких режимах СУБД себя контролирует.
Спасибо за разъяснения, последний вопрос. А как понять сколько выделить памяти БД? Какие тут есть критерии?

Если можно, дайте ссылочку на не сложную инструкцию по настройке для сервера с 1 ГБ озу
источник

IZ

Ilia Zviagin in MySQL
Влад
Спасибо за разъяснения, последний вопрос. А как понять сколько выделить памяти БД? Какие тут есть критерии?

Если можно, дайте ссылочку на не сложную инструкцию по настройке для сервера с 1 ГБ озу
Ну я вот так сразу не дам, надо искать хорошую
источник

IZ

Ilia Zviagin in MySQL
Влад
Спасибо за разъяснения, последний вопрос. А как понять сколько выделить памяти БД? Какие тут есть критерии?

Если можно, дайте ссылочку на не сложную инструкцию по настройке для сервера с 1 ГБ озу
1 гиг мало же.
Бд разве что маленькая...
источник

В

Влад in MySQL
Ilia Zviagin
1 гиг мало же.
Бд разве что маленькая...
Одна БД которой пользуется админ весит 170 мб (там несколько таблиц на пару сотен тысяч записей), а вторая пока пустая, будет наполняться когда появятся пользователи.

Работает достаточно шустро, нареканий пока нет. Вот только хочется чтобы с появлением пользователей не было проблем.

Может посоветуете по опыту сколько ОЗУ на какой объм БД будет достаточно?
источник

OS

Open Source in MySQL
источник

OS

Open Source in MySQL
или MySQL-Tunner запустите и дайте 24 часа поработать, он должен прикинуть
источник

V

Vova in MySQL
Там же longtext размеров до 4Gb
100 Mb на запись вот и 500 гигов
источник