- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Автор. Дадите рута, попробую разобраться.
icq 100692643
Нет. А что в этом логе такого важного для парсинга?
Для Вас может ничего и нет (как правило, он вообще пустой на продакшен) - а ТС надо. Что у него там - хз, может лог запросов для отладки пишет.
Ну вот когда он расскажет, тогда и посоветую более детально
программа mysqlsla, например, отчетики строит и с помощью general log и slow log.
Спасибо, посмотрел mysqlsla, к сожалению примеров мало, а на основе документации не получается получить нужную информацию...
Ну вот когда он расскажет, тогда и посоветую более детально
Собственно задача, которую я хочу решить написана в первом посте:
- сколько в среднем за одно подключение запросов;
- сколько за одно подключение запросов к той или иной таблице;
В mysql.log идет идентификатор соединения, типа запроса, запрос. То есть я хотел бы узнать, что в среднем за одно соединение происходит 15 запросов (10 SELECT, 3 INSERT, 2 UPDATE) и что 5 запросов к таблице TABLE_A, 10 к TABLE_B.
Смысл всего этого для себя вижу в оптимизации запросов, то есть если окажется, что на одно соединение происходит больше одного обращения к одной таблице с выборкой одних и тех же данных, то воспользуюсь допустим memcache на стороне скриптов. Ну как то так.
в отчетах mysqlsla несколько другой подход - усреднение запросов и поиск самых нагружающих типов (не зависимо от аргументов) запросов .
то что вы пытаетесь найти - какая-то фигня. так никто не делает. одинаковые запросы в рамках одной сессии скоре всего будут закешированы кешом запросов mysql.
впрочем, могу написать специальный парсер именно такой как вам нужен. дорого
То есть я хотел бы узнать, что в среднем за одно соединение происходит 15 запросов (10 SELECT, 3 INSERT, 2 UPDATE) и что 5 запросов к таблице TABLE_A, 10 к TABLE_B.
А если это трёхэтажные SELECT-ы с JOIN-ами и alias-ами, и INSERT-ы, комбинированные с SELECT-ами?
Замучаетесь писать парсер, который грамотно посчитает, сколько фактически запросов в одном запросе и к каким они таблицам :)
Гораздо проще, если движок ваш, вести учёт прямо в нём, ибо увеличивать переменные на 1 гораздо проще, чем парсить лог.
Я кой-чего не понял, если включен general log и требуется оптимизация.... то может его выключить, а?
В Дебияне про этот лог сказано просто и бесхитростно:
#log = /var/log/mysql/mysql.log
И заменить на slow log, зачем все-то анализировать?
Спасибо, посмотрел mysqlsla, к сожалению примеров мало, а на основе документации не получается получить нужную информацию...
Собственно задача, которую я хочу решить написана в первом посте:
- сколько в среднем за одно подключение запросов;
- сколько за одно подключение запросов к той или иной таблице;
Там можно указывать таблицу для анализа. Делай отчет по каждой табличке, по отдельности.
;9299010']А если это трёхэтажные SELECT-ы с JOIN-ами и alias-ами, и INSERT-ы, комбинированные с SELECT-ами?
Замучаетесь писать парсер, который грамотно посчитает, сколько фактически запросов в одном запросе и к каким они таблицам :)
Гораздо проще, если движок ваш, вести учёт прямо в нём, ибо увеличивать переменные на 1 гораздо проще, чем парсить лог.
Спасибо, ваши аргументы меня убедили отказаться от этой затеи...