The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Высокопроизводительный MySQL-движок TokuDB переведён в разря..."
Отправлено sauron, 30-Апр-13 08:34 
> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь,
> индекс, и ничего кроме" - очень даже нужны хинты/форсирование.

Если у вас возникает такая надобность, то надо внимательно посмотреть на свою базу данных.

> "Часто", "реже" - это всё относительно, и зависит от приложения / структуры
> БД. У меня есть большая табличка, аналитическая выборка из которой ломает
> шаблон оптимизатору хоть MySQL, хоть MSSQL, хоть Оракла. Просто потому, что
> все три берут самый очевидный вариант плана запроса, который совершенно неоптимален
> с точки зрения доступа к диску. И переструктурировать ее некуда -
> там явных внутренних связей просто нет, + символьные поля переменной длины.
> С форсированием конкретного индекса (раза в два больше строк в скане,
> зато на порядок меньше время выполнения) же вся аналитика бегает очень
> неплохо.

А не надо так делать и все будет хорошо.

> Тут бы неплохо пруфлинк-таки, потому что из того, что я на форумах
> вижу - ситуация прямо обратная.

Пруфлинк на что? Что MySQL хуже держит нагрузки? Вы уйдите с форумов про MySQL и сразу найдете.

> Когда делаешь START TRANSACTION, и начинаешь писать данные пачками - блокируются части
> индекса. Ровно до момента COMMIT. Поэтому параллельные записи, затрагивающие те же
> части индекса - уже не пройдут, и будут ждать выполнения твоей
> транзакции. А до момента COMMIT может пройти много времени.

И? Ну не будет в выборке у меня этих данных и все.

> Поэтому иногда выгоднее отсутствие явных транзакций, и выполнение по 1 команде записи
> на транзакцию. Например при высоком параллелизме обновления одних и тех же
> таблиц. Zabbix в его нынешнем виде - как раз тот случай.

И в этом случае у MySQL все становится плохо. Хотя и при длинных транзакциях ему тоже плохеет :)

> Хотя - да, его бы переписать с прямой записи в таблицы на
> каждый чих на очередь обновления - и он нормально бы с
> транзакционностью ужился, и проблем с производительностью стало бы меньше. Подвижки в
> этом направлении там уже есть, но пока что не везде.

Транзакционная запись необходима. Это ускорит работу zabbix ну так лучше с СУБД работать.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру