- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть вроде бы простые запросы вида
выполняются почти 1 сек. индекс на поле rgt и первичны на ID стоит. Можно ли его ускорить?
MyISAM? InnoDB?
innodb_flush_log_at_trx_commit = 0 уже стоит, может удалить индексы с таблицы? При апдейте же еще и индексы обновляется, а ме они сейчас только мешают наверное?
---------- Добавлено 22.02.2018 в 14:31 ----------
MyISAM? InnoDB?
InnoDB у меня
какого тип у rgt?
сколько у вас оперативной памяти и что в innodb_buffer_pool_size?
innodb_flush_method = O_DIRECT
innodb_buffer_pool_size = 4096M
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 0
innodb_thread_concurrency = 4
innodb_file_per_table = 1
innodb_io_capacity = 400
innodb_open_files = 2048
innodb_buffer_pool_instances = 2
max-connect-errors = 10000
ТИП - int(11)
оперативки на ВПС 16 гигов. на ВПС 13 баз для работы одного скрипта, суммарно их объем менее 1 гб
при 16 гб памяти innodb_buffer_pool_size можно делать и больше - 8,10 например
в таблице много записей?
p.s. вообще индексы замедляют обновление и вставку
Индексы хороши только для select, остальные операции они замедляют. Попробуйте удалить индекс на rgt и сравните. Если у вас массовые запросы, то лучше проводить их "пачками", т.е.
START TRANSACTION;
UPDATE ...
UPDATE ...
UPDATE ...
UPDATE ...
COMMIT;
Если этот update не изменяет выводимые пользователю данные, то его можно выполнить в фоновом режиме (в коде php):
session_write_close();
fastcgi_finish_request(); // тут пользователь получает свою страницу
UPDATE ... // а сервер продолжает делать апдейты, но пользователю уже не нужно ждать
UPDATE ...
UPDATE ...
UPDATE ...
Можно попробовать убрать индексы, если выделяется достаточно innodb_buffer_pool_size
Можно удалить все индесы с обновляемых таблиц - даже первичные на id?
Dram, только с тех полей, которые изменяются апдейтом
Есть вроде бы простые запросы вида
выполняются почти 1 сек. индекс на поле rgt и первичны на ID стоит. Можно ли его ускорить?
Переход на ssd сильно поможет:) Такое большое время на апдейт обычно обуславливается тем, что база носится по всему диску то туда то сюда и пишет в разные места. Рандомный доступ - всегда долго.
Вариант - если апдейт поля частый, а таблица большая - вынести id, rgt в отдельную таблицу. По сути будет нечто вроде кэша. Замедления при выборке особого не будет, а скорость при апдейте увеличится в разы.