- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Тип чего, простите? о_О
Но ведь это менять архитектуру нужно и скрипты переписывать (либо костылями обвешиваться) - опять же не "админское" решение...
mysqldump раз в час по крону - вполне админское
Metal_Messiah, а структуру таблицы? О индексации полей не думали?
# Query_time: 30.509671 Lock_time: 0.000027 Rows_sent: 0 Rows_examined: 686309
SELECT * FROM plmon WHERE ip='6340****2' AND name='****' AND proto='48' AND auth='********' AND authprov='4' ORDER BY id LIMIT 1;
С индексами сложности какие-то?
Что покажет?
mysqldump раз в час по крону - вполне админское
Костыль это а не решение.. вон 600к записей перебирается при каждом заходе..
Индекс id который основной. Структура
`id` int(11) unsigned NOT NULL auto_increment,
`csbid` int(4) unsigned NOT NULL,
`ip` int(4) unsigned default NULL,
`lang` varchar(2) NOT NULL,
`auth` varchar(21) NOT NULL,
`name` varchar(50) NOT NULL,
`proto` int(1) unsigned NOT NULL,
`authprov` int(1) unsigned NOT NULL,
`slotid` int(1) unsigned default NULL,
`serverid` int(4) unsigned NOT NULL,
`serverip` int(4) unsigned default NULL,
`time` int(4) unsigned default NULL,
`country` varchar(2) NOT NULL,
`city` varchar(50) NOT NULL
PRIMARY KEY (`id`)
) ENGINE=MyISAM
Country и city думал индексами на другую таблицу сделать но потом понял что join дольше работает чем хранить лишние байты
но потом понял что join дольше работает чем хранить лишние байты
Как записи гонять - нормально.. а байты экономим.
Для начала
И в запросах можно для наглядности порядок поменять...
В результате что выдаст:
А вообще - имеет смысл про оптмизацию MySQL почитать.
Костыль это а не решение.. вон 600к записей перебирается при каждом заходе..
Я уже писал - взять и переписать скрипты
Я уже писал - взять и переписать скрипты
Andreyka, похоже на разговор слепого с глухим.
Неужели, правда не видно разницы "переписать скрипты" vs "оптимизировать узкое место". Неужели, действительно трудозатраты на "переписать скрипты" /+ поменять архитектуру, мемкэш прикрутить или крон.. которого раз в час может оказаться мало/ сравнимы с "добавить индексов + настроить конфиги"[по идее то, что само собой разумеется нужно сделать первым делом, тем более с точки зрения Админа и не сделано в силу неопытности или желания набить "самостоятельных шишек" ]?
На обращение в сервис "жму газ - не едет" ответ от механика - движок заменим на помощнее - лучше тянуть будет.
ivan-lev, вы здесь недавно? это у Андрея такой стиль.
На обращение в сервис "жму газ - не едет" ответ от механика - движок заменим на помощнее - лучше тянуть будет.
Если вы на легковушке собрались многотонные грузы возить - лучше заменить движок :)
ТСу просто надо открыть для себя индексы (структуру индексов можно уже подкорректировать с учетом и остальных запросов)
CREATE INDEX ip ON plmon (ip, name, proto),
CREATE INDEX auth ON plmon (auth, authprov),
CREATE INDEX country ON plmon (country)