Оптимизация MYSQL

[Opik]

Оптимизация MYSQL

Из-за нагруженности базы данных (mySQL), остро встал вопрос оптимизации. что можно сделать?
1) Таблицы innodb на больших объемах и частым обновлением/добавлением
2) граммотно расставленные индексы
3) SELECT SQL_CACHE (?) - помогает ли?
4) делать выборку только тех полей, которые действительно нужны для работы.
5) Имеет ли делать смысл LIMIT 1. Т.е верно ли утверждение " Если будет стоять LIMIT 1, то после первого совпадения, он прекратить сравнение и поиск остальных строк. " при выборке по primary key, или без него.
memcache не предлагать, т.к на данном этапе оптимизируются именно запросы и база в целом, результаты кешироваться будут тоже.
Спасибо.

 

[Фанат]

результаты explain select на наиболее тяжёлых запросах - в студию

-~{}~ 06.08.05 19:32:

плюс benchmark того же запроса

 

[Opik]

Я сделал так, что бы запросы, которые выполняются больше 0.1 писались в лог, что бы можно было отловить их. Наиболее "ресурсоемкими" оказались UPDATE, INSERT, DELETE например:
sec: 1.49662; query: UPDATE `participants` SET `takeDamage` = `takeDamage` + 4 WHERE oid = '39115' and mid = 1332
sec: 1.15912; query: INSERT INTO battles (offer, time, id, attacker, defender, kick, block, type, damage, comment)
values (39021, 1123325643, 12, '', '', '', '', 2, '', '<b>OrEst побежден!</b>')
sec: 1.87144; query: DELETE FROM participants where oid = '39084' and mid = '3408'
селектов же очень мало и выполняются быстрее.
Типы таблиц parcitipant, battles - Innodb
поля mid, oid - индексы у таблицы participant, primary key нету.
Появилась мысль: добавить в эту таблицу поле auto_increament, и сделать primary key и удалять по нему? Стоит ли это делать?

 

[Фанат]

из таблиц, в которые идёт частое удаление/обновление, лучше индексы вообще убрать.
особенно, если выборка редкая

 

[Opik]

В этих таблица как выборки частые, так и удаление/добавление/обновление. И что по поводу ввода primary key?

-~{}~ 06.08.05 18:53:

"селектов же очень мало и выполняются быстрее" я имел в виду. что в логе их мало зафиксировано.

 

[Фанат]

а размер таблиц какой?

 

[Opik]

battles:
Данные 150,192 KB
Индекс 38,976 KB
Всего 189,168 KB
participants:
Данные 4,624 KB
Индекс 6,880 KB
Всего 11,504 KB

 

[Фанат]

я правильно понимаю, что таблица battles занимает 150 мегабайт?
и что - всё время требуются выборки именно по всей таблице?
разделить на "дежурную" и "архивную" никак нельзя?
или писать сводную статистику, к примеру, колчество боёв, сразу готовой цифрой, а не считать постоянно?

 

[Opik]

Да, ты всё правильно понимаешь. 150 мегабайт примерно. Чаще выборки идут по части таблицы. но порой и требуются старые данные. Есть вариант "ненужные" записи хранить в файлах, т.е serialize массива.

 

[Фанат]

Есть вариант "ненужные" записи хранить в файлах, т.е serialize массива.

150 мегабайт сериализованных данных?

 

[Opik]

Фанат
ну не в одном же файле, там много боев, 1 бой = 1 файл.

 

[Фанат]

150 000 файлов?

 

[Opik]

)) нет, 1 бой != 1 мб. там примерно 20000 боев... но хотя это тоже много файлов... можно за 1 день 1 файл. Или лучше всё же использовать как ты писал ранее 2 таблицы, актуальную и архивную?

 

[Фанат]

1 бой != 1 мб.

ты не пробовал ансериализовывать мегабайтный файл?
тебе понравится.

Или лучше всё же использовать как ты писал ранее 2 таблицы, актуальную и архивную?

ты это у меня спрашиваешь?

 

[Opik]

"ты не пробовал ансериализовывать мегабайтный файл"
нет, но видимо долго. нужно будет попробовать.
"ты это у меня спрашиваешь?"
вроде да, ты предложил такое решение вроде бы.

-~{}~ 06.08.05 19:34:

А что касательно остальных вопросов?

 

[Фанат]

а при чём здесь остальные вопросы?
Тебе шашечки или ехать?
тебе скрость нужна или на вопросы ответить?

-~{}~ 06.08.05 20:44:

ну давай посмотрим твои вопросы.

3) SELECT SQL_CACHE (?) - помогает ли?
4) делать выборку только тех полей, которые действительно нужны для работы.

у тебя, по-моему, что-то в мозгу заело.
тебе ещё раз напомнить, как у тебя работают селекты, или сам сподобишься?

и слово "грамотность" пишется с одной буквой "М"
постарайся запомнить и не делать хотя бы этой идиотской ошибки.

 

[Opik]

"тебе скрость нужна или на вопросы ответить?"
скорость важна, но ответы хотелось бы слышать, что бы либо пользоваться, либо забыть и не возращаться.
"и слово "грамотность" пишется с одной буквой "М"" это я запомню, но если бы меня больше интересовала моя грамотность, я бы обратился на другой форум, но спасибо за беспокойство, ценю.

 

[Фанат]

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

ответы хотелось бы слышать

единственный ответ, который должен тебя интересовать, звучит так:
таблица, в которой часто происходят изменения, должна быть НЕБОЛЬШОЙ.
чтобы полное переписывание индексов, которое происходит при каждом изменении таблицы, не отжирало кучу времени.
остальные твои вопросы - детский лепет.

 

[Opik]

ок, благодарю.

 

[slach]

если можно обойтись без тразакций, то попробуй сменить тип на MyISAM

все таки 150 метров это не предел... если на приличном железе

кроме того есть такая вещь как
CREATE TABLE (
) DELAY_KEY_WRITE = 1;

понижается надежность, но скорость весьма не плоха
кроме того можно попробовать поиграться с размером Key Cache
http://dev.mysql.com/doc/mysql/en/MyISAM_key_cache.html