Mysql грузит систему в 0

_HEDELKA_

Client
Регистрация
20.02.2022
Сообщения
648
Благодарностей
170
Баллы
43
Всем привет дамы и господа!

Сегодня столкнулся с проблемой OpenServer а конкретнее Mysql грузит систему в 0, работают 10 шаблонов и все они часто обращаются к базе

Как известно я разрабатываю ботов на зеннопостере и при нажатии кнопки в боте связанные с запросом к бд ответ приходит в 5-10 секунд (на 1 человека) обычный ответ приходит моментально

По характеристикам вдс 4x2.2ГГц, 8Гб RAM, 100Гб HDD, 1IP

Как можно фиксануть данный баг?

Или есть альтернативные базы данных (желательно где будет легко перейти с Mysql так как всё написано на этой базе)
 

_HEDELKA_

Client
Регистрация
20.02.2022
Сообщения
648
Благодарностей
170
Баллы
43
или даже может купить за 150 рублей сервер под сайт (там база данных есть с 10гб памятью) чтобы освободить процессы базы mysql на вдс
 

catol

Client
Регистрация
05.07.2012
Сообщения
278
Благодарностей
98
Баллы
28
Была похожая проблема но 1 сайт ложил весь сервак процессами MYSQL.
1. Включить кеширование или если WP поставить плагин.
2. Сделать html версию сайта и забыть про нагрузку.
3. Не использовать mysql (может скрипт поддерживает другие виды баз данных)
4. Настрой кеширование cloudflare

Я решил эту проблему 3м вариантом, натянул свой шаблон на другую CMS которая не использует mysql
 

WebBot

Client
Регистрация
04.04.2015
Сообщения
1 763
Благодарностей
1 391
Баллы
113

backoff

Client
Регистрация
20.04.2015
Сообщения
6 042
Благодарностей
6 475
Баллы
113
я так понимаю никакого сайта нет, просто бот работает с бд?
если так, то тут только делать оптимизацию самих запросов к БД

пришли тяжелый запрос, посмотрим.
 

_HEDELKA_

Client
Регистрация
20.02.2022
Сообщения
648
Благодарностей
170
Баллы
43
я так понимаю никакого сайта нет, просто бот работает с бд?
если так, то тут только делать оптимизацию самих запросов к БД

пришли тяжелый запрос, посмотрим.
Да ты прав, сервер дб располагается на вдс через OpenServer, абсолютно все запросы тяжелые вот один из:
103438

103439

103440
 

backoff

Client
Регистрация
20.04.2015
Сообщения
6 042
Благодарностей
6 475
Баллы
113
ну вот как раз запрос с "LIKE" - жопный, я понимаю что он удобный, но с ним скорости не будет, тем более когда БД большая
этот запрос, чтоб найти нужную запись по критерию, будет обходить всю БД (каждую строчку), и чем она больше, тем дольше будет искать

проиндексируй БД, обычно это стандартный первый столбец идет как "id"
тут надо либо еще одну БД делать либо файл, я юзаю просто текстовик, туда записываю все id из БД потом при нужном запросе сопоставляю данные и беру уже сам id строки и обращаюсь уже к ней
 

WebBot

Client
Регистрация
04.04.2015
Сообщения
1 763
Благодарностей
1 391
Баллы
113
А здесь прям точно нужен LIKE ??? или все же достаточно обычного = ????

И если все таки точно нужен (в чем есть большие сомнения), то индек то по столбцу имеется?
 

_HEDELKA_

Client
Регистрация
20.02.2022
Сообщения
648
Благодарностей
170
Баллы
43
ну вот как раз запрос с "LIKE" - жопный, я понимаю что он удобный, но с ним скорости не будет, тем более когда БД большая
этот запрос, чтоб найти нужную запись по критерию, будет обходить всю БД (каждую строчку), и чем она больше, тем дольше будет искать

проиндексируй БД, обычно это стандартный первый столбец идет как "id"
тут надо либо еще одну БД делать либо файл, я юзаю просто текстовик, туда записываю все id из БД потом при нужном запросе сопоставляю данные и беру уже сам id строки и обращаюсь уже к ней
Да окей одну фиксануть можно.
Но есть другие запросы которые нужно обязательно искать по тексту так как мы изначально не знаем ID хоть они и ставятся везде, если только все делать через такую фишку: кнопка: действие|ID таким образом работа всегда будет через но записи опять же пополняются 24/7 и мы не знаем у какого пользователя какой ид (так как там могут быть и 3 и 10 записей, и все их нужно спарсить)
Хз что делать.
 

WebBot

Client
Регистрация
04.04.2015
Сообщения
1 763
Благодарностей
1 391
Баллы
113
и если ува там LIKE => user_id у вас строковый тип, а не числовой .... user_id точно может быть не числом???? а если он всегда число, тогда не понятно зачем он сделан в виде varchar/text, а не int unsigned например
 

_HEDELKA_

Client
Регистрация
20.02.2022
Сообщения
648
Благодарностей
170
Баллы
43
А здесь прям точно нужен LIKE ??? или все же достаточно обычного = ????

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


и если ува там LIKE => user_id у вас строковый тип, а не числовой .... user_id точно может быть не числом???? а если он всегда число, тогда не понятно зачем он сделан в виде varchar/text, а не int unsigned например
У меня все база пишется text (не важно текст или цифры) не понимал как работают эти значения :-)
 

WebBot

Client
Регистрация
04.04.2015
Сообщения
1 763
Благодарностей
1 391
Баллы
113
целые чила (всякие id) долны хранится в столбцах с целочисленным типом ( int unsigned например )
поиск записи по id должен производиться через обычное равно ( WHERE user_id=12345 )
столбцы участвующие в поиске должны иметь индекс ( тогда для поиска 1 записи не нужно сканировать целую таблицу )
 

_HEDELKA_

Client
Регистрация
20.02.2022
Сообщения
648
Благодарностей
170
Баллы
43
целые чила (всякие id) долны хранится в столбцах с целочисленным типом ( int unsigned например )
поиск записи по id должен производиться через обычное равно ( WHERE user_id=12345 )
столбцы участвующие в поиске должны иметь индекс ( тогда для поиска 1 записи не нужно сканировать целую таблицу )
Окей я попробую
 

Moonwalker

Client
Регистрация
16.03.2016
Сообщения
1 617
Благодарностей
1 214
Баллы
113
У меня все база пишется text :-)
Вот тут и проблема. Еще до LIKE.
ps. Вообще, поищи в сети курс по БД от GeekBrains. По крайней мере, базовые вещи в голове по структуре базы, типам данных, логике взаимодействия встанут на место... Ибо у тебя на уровне проектирования структуры уже самое тонкое место получается.
 
Последнее редактирование:

_HEDELKA_

Client
Регистрация
20.02.2022
Сообщения
648
Благодарностей
170
Баллы
43
Вот тут и проблема. Еще до LIKE.
Ну вот вы можете предположить какого объема текст будет (не включая юзер из)
Такие как файл ид (буквы и цифры)
Имя Фамилия отчество
Баланс (как цело число так и через запятую) по логике удобно записать просто как текст а потом уже обрабатывать но если это настолько сильно грузит систему то можно перейти на альтернативное решение как мне написал выше пользователь WebBot

целые чила (всякие id) долны хранится в столбцах с целочисленным типом ( int unsigned например )
поиск записи по id должен производиться через обычное равно ( WHERE user_id=12345 )
столбцы участвующие в поиске должны иметь индекс ( тогда для поиска 1 записи не нужно сканировать целую таблицу )
Вы не могли бы набрать в телеграмме так как есть дополнительные вопросы

И доп вопрос к пользователям Zenno можно сделать так:
Найти и заменить все записи ну грубо говоря есть в различных кубиках текст "блин" нужно заменить везде на "вкусный блин" типа как в txt файле
 

Moonwalker

Client
Регистрация
16.03.2016
Сообщения
1 617
Благодарностей
1 214
Баллы
113
Ну вот вы можете предположить какого объема текст будет (не включая юзер из)
Такие как файл ид (буквы и цифры)
Имя Фамилия отчество
Баланс (как цело число так и через запятую) по логике удобно записать просто как текст а потом уже обрабатывать но если это настолько сильно грузит систему то можно перейти на альтернативное решение как мне написал выше пользователь
Причем здесь объем текста? Его сразу нужно в БД класть правильно, раскладывая данные по нужным столбцам. Id - в свою колонку, ФИО - в свою, баланс - в свою. Причем, у каждого столбца - изначально свой формат. И под этот формат данные перед добавлением форматируем. Т.е., получаем данные, обрабатываем, раскладываем. Потом с этой базой и работать будет нормально, получая оттуда НУЖНЫЕ данные, а не тягая каждый раз кучу ненужного.
И WebBot предложил не альтернативное решение, это тот же MySQL, просто правильно организованная структура БД.
Повторюсь, посмотрите курс по базам данных, поймете свою ошибку на БАЗОВОМ уровне еще в момент проектирования структуры базы данных. Но если нет желания, то, конечно, можно и дальше пытаться через LIKE все тягать (тогда не совсем ясно, какой смысл в БД, если это тоже самое, что с файлами работать).
 

Кто просматривает тему: (Всего: 1, Пользователи: 0, Гости: 1)