Меню
Что нового?

Возможна ли оптимизация запросов?

Vadimka

Новичок
Возможна ли оптимизация запросов?

Имеется основная таблица логов view_news2 (MyISAM) на 240К записей
и имеется временная таблица view_news2_tmp (MyISAM) на 1К записей (с одним индексом по дате),
в которую пишутся изначально логи, которые несколько раз в час перекидываются в основную таблицу...

INSERT INTO view_news2 SELECT * FROM view_news2_tmp WHERE dd < '2008-02-03 23:27:17' - 4.00748991966
DELETE FROM view_news2_tmp WHERE dd < '2008-02-03 23:27:17' - 1.52402806282

мне кажется время выполнения запросов большое( можно ли что-то оптимизировать?
 
Mr_Max

Mr_Max

Первый класс. Зимние каникулы ^_^
Команда форума
Vadimka
Зачем тебе во временной таблице выборка по условию?
Временная таблица на то и временная - вставил почистил.
Без всяких условий (это мое мнение).

-~{}~ 03.02.08 23:43:

+
мей-би следует использовать TRUNCATE?...
 

Vadimka

Новичок
Автор оригинала: Mr_Max
Vadimka
Зачем тебе во временной таблице выборка по условию?
Временная таблица на то и временная - вставил почистил.
Без всяких условий (это мое мнение).
Нажмите для раскрытия...
Речь идет о информерах,
показалась новость - сделали запись в tmp таблицу с уникальным значением, от момента показа новости до клика по это новости может пройти 1,2 минуты...
вот из-за этого и удаляю по условию, более 2 последних минут...

-~{}~ 04.02.08 00:55:

Автор оригинала: berkut
индексы есть на дате?
Нажмите для раскрытия...
mysql> SHOW INDEX FROM view_news2_tmp;
+---------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+---------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| view_news2_tmp | 1 | dd | 1 | dd | A | 275 | NULL | NULL | | BTREE | |
+---------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
 
itprog

itprog

Cruftsman
Vadimka
медленно потому что индексы обновляются

пс: зачем перекидывать? пиши сразу в view_news2
 

Vadimka

Новичок
Автор оригинала: itprog
Vadimka
медленно потому что индексы обновляются

пс: зачем перекидывать? пиши сразу в view_news2
Нажмите для раскрытия...
в view_news2 есть индексы для подсчетов статистики, думаю что будет подтормаживать при insert строк (сейчас 40-50 строк в сек)
?
 
itprog

itprog

Cruftsman
Vadimka
ну посчитай что тебе оптимальнее, сразу или один раз, но 4 секунды
сделай еще EXPLAIN SELECT * FROM view_news2_tmp WHERE dd < '2008-02-03 23:27:17'

еще есть опция DELAY_KEY_WRITE, но тоже не без недостатков
 

Vadimka

Новичок
SELECT быстро делается, много времени забирает вставка данных ((
нашел переменную myisam_bulk_insert_tree_size, но она на 5.1 не поддерживается

This variable limits the size of the cache tree in bytes per thread. Setting it to 0 disables this optimization. The default value is 8MB. Before MySQL 4.0.3. this variable was named myisam_bulk_insert_tree_size
 
Фанат

Фанат

oncle terrible
Команда форума
Vadimka
А попробуй убрать с временной индекс?
То, что в постоянной бдут тормоза - это понятно. А вот с временной надо разобраться
 

Gas

может по одной?
Vadimka
ну а DELAY_KEY_WRITE пробовал?
можно, конечно, попробовать alter table `tbl` enable/disable keys, но имхо это кривовато не для системных целей.

itprog
но тоже не без недостатков
Нажмите для раскрытия...
а какие недостатки? а то сам пока не юзал.
 
itprog

itprog

Cruftsman
а какие недостатки? а то сам пока не юзал.
Нажмите для раскрытия...
надо делать myisamchk перед стартом mysql, т.к. неизвестно был ли сервер корректно остановлен

Vadimka
попробуй все же DELAY_KEY_WRITE для tmp, там индексы всеравно не критичны
 

Vadimka

Новичок
Автор оригинала: itprog
надо делать myisamchk перед стартом mysql, т.к. неизвестно был ли сервер корректно остановлен

Vadimka
попробуй все же DELAY_KEY_WRITE для tmp, там индексы всеравно не критичны
Нажмите для раскрытия...
к сожалению не заметил какой-то разницы (
 
FractalizeR

FractalizeR

Новичок
Re: Возможна ли оптимизация запросов?

Что произойдет, если указать модификаторы HIGH_PRIORITY и QUICK в соответствующих местах?

Код: 
INSERT HIGH_PRIORITY INTO view_news2 SELECT HIGH_PRIORITY * FROM view_news2_tmp WHERE dd < '2008-02-03 23:27:17'
DELETE QUICK FROM view_news2_tmp WHERE dd < '2008-02-03 23:27:17'
HIGH_PRIORITY, конечно, замедлит выборку из таблиц на время вставки, но, возможно, в вашем случае, это приемлемо?

Кстати, выполнение OPTIMIZE TABLE увеличивает скорость выполнения ваших запросов? Если так, то эту операцию можно попробовать выполнять по крону во время, когда сервер нагружен меньше всего.
 

Vadimka

Новичок
OPTIMIZE TABLE - не выполнял

попробывал вот такой вариант:

ALTER TABLE view_news2 DISABLE KEYS - 0.0241179466248
SELECT * FROM view_news2_mem WHERE dd < '2008-02-04 20:04:22' - 0.00617003440857
INSERT HIGH_PRIORITY INTO view_news2 SELECT * FROM view_news2_mem WHERE dd < '2008-02-04 20:04:22' - 0.0337569713593
DELETE QUICK FROM view_news2_mem WHERE dd < '2008-02-04 20:04:22' - 0.0177118778229
ALTER TABLE view_news2 ENABLE KEYS - 11.0728061199


воссоздание индексов конечно занимает много времени ((
 

Gas

может по одной?
Vadimka
проверил, да, не удачно посоветовал ENABLE/DISABLE KEYS.

у себя только что затестил:
из t2 - вставляем 10K записей (avg.row length=30 байт) в таблицу t1 (10M rows, myisam, 4 индекса, один из них primary, 2 составных), без всяких "хитростей" (обычный insert...select), результат 0,9 сек, при вставке 100K rows - падение скорости линейное (9 сек) сервер в этот момент ничем другим не нагружен.
Поcле ALTER TABLE `t2` DELAY_KEY_WRITE=1; (delay_key_write=ON в настройках mysqld) - результат аналогичный.
То-есть, в общем, случае mysql не такой уж и тормоз :)

A много индексов в таблице view_news2 и сколько из них строковых?
 

Vadimka

Новичок
Автор оригинала: Gas
Vadimka
проверил, да, не удачно посоветовал ENABLE/DISABLE KEYS.

у себя только что затестил:
из t2 - вставляем 10K записей (avg.row length=30 байт) в таблицу t1 (10M rows, myisam, 4 индекса, один из них primary, 2 составных), без всяких "хитростей" (обычный insert...select), результат 0,9 сек, при вставке 100K rows - падение скорости линейное (9 сек) сервер в этот момент ничем другим не нагружен.
Поcле ALTER TABLE `t2` DELAY_KEY_WRITE=1; (delay_key_write=ON в настройках mysqld) - результат аналогичный.
То-есть, в общем, случае mysql не такой уж и тормоз :)

A много индексов в таблице view_news2 и сколько из них строковых?
Нажмите для раскрытия...
да индексов хватает, из -за них похоже и тормозит INSERT

CREATE TABLE `view_news2` (
`id_kto` mediumint(9) NOT NULL,
`id_site` mediumint(9) NOT NULL,
`id_news` int(11) NOT NULL,
`id_inf` mediumint(9) NOT NULL,
`refera` varchar(255) NOT NULL,
`usag` varchar(255) NOT NULL,
`ip2` int(4) unsigned NOT NULL,
`dd` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`rnd` char(32) DEFAULT NULL,
`click` tinyint(1) DEFAULT '1',
KEY `dd` (`dd`),
KEY `rnd` (`rnd`),
KEY `view` (`click`),
KEY `id_kto` (`id_kto`),
KEY `id_site` (`id_site`),
KEY `id_news+rnd` (`id_news`,`rnd`),
KEY `id_news+dd` (`id_news`,`dd`),
KEY `id_kto+dd+click` (`id_kto`,`dd`,`click`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
 

Gas

может по одной?
да индексов хватает
Нажмите для раскрытия...
ага :)

Если эти все индексы нужны для статистики или прочих нужд админа, где актуальность данных не обязательно real time - то можно по классике:
убрать индексы нах, добавить primary (чтоб к нему клики вязать и знать откуда начинать "дорасчёт"). Создать доп.таблицу(ы) с агрегированными данными и периодически её пополнять, запоминая последний id, чтоб в следующий раз с него начать выборку новых.
Для кликов можно создать отдельную heap таблицу и тоже периодически скопом обновлять из неё отчёты и view_news2 (хотя не вижу смысла её тогда трогать).

-~{}~ 04.02.08 21:54:

Поле `rnd`char(32) - похоже используется для хранения md5-хеша? Если так, можешь попробовать заменить его на bigint. Сейчас в `rnd` хранится 128bit'ов значение но занимает 32 байта, а так будет 8 байт (первые или последние 64 бита хеша) и размер общего индекса почти в 2 раза станет меньше. Хотя радильно на скорость это врят ли повлияет.
 

Vadimka

Новичок
спасибо за подробные советы,
первое что надо пересмотреть необходимость всех индексов

п.с. большое всем спасибо, буду заниматься индексами

п.с.с. `rnd`char(32) случайная строка состоящая из букв и цифр, хотя ты прав можно применить только цифры и тип bigint
 
Войдите или зарегистрируйтесь для ответа.
Сверху