SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 28.06.2010 14:46:29

boa
Завсегдатай
Зарегистрирован: 22.06.2010
Сообщений: 38

Странное поведение Mysql до и после Optimize table

Добрый день.
Опишу БД и запрос, и потом скажу в чем суть проблемы.
Есть БД с двумя табличками

CREATE TABLE `t1` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `url` text,
  `title` text NOT NULL,
  `anchor` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=213918 DEFAULT CHARSET=utf8;

CREATE TABLE `t2` (
  `id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `idSite` bigint(20) unsigned NOT NULL DEFAULT '0',
  `streamUrl` text NOT NULL,
  `objectTag` varchar(6) NOT NULL DEFAULT '',
  `object` mediumtext NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idSite` (`idSite`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Ипользуя хранимую процедуру извлекаю нужные строки из таблиц

CREATE DEFINER=`root`@`%` PROCEDURE `search`(IN src text, in Soffset int, in Srowcount int)
    READS SQL DATA
    DETERMINISTIC
    SQL SECURITY INVOKER
BEGIN

set @q=concat('
Select
t1.id AS t1_id,
t1.url AS host_url,
t2.id AS t2_id,
t2.streamUrl AS t2_url,
t2.object AS object_body,
t1.title AS t1_title,
t1.anchor AS t1_anchor
From t1
inner join t2 On t1.id = t2.idSite         
where t1.id in (',src,')
ORDER BY FIELD (t1.ID,',src,')
LIMIT ',Soffset,',',Srowcount,';');

PREPARE STMT FROM @q;
EXECUTE STMT;
END;

Через параметр src передаю список ID, разделенные запятой. Список может содержать до 1000 разных ID
пример вызова процедуры
call search("95420,43743,94112,95414,56021,56024,166704",0,10);

В таблицах t1 и t2 содержится примерно по ~200 и ~350 тысяч записей соответственно

Так вот проблема в том что сразу после старта(или рестарта) mysqld подобные запросы выполняются оч медленно - от 0.5 до 1.5 секунд

НО! если сделать Optimize table t1, t2; то сразу после этого  запросы начинают работать нормально и среднее время выполнения запроса - около 0.01~0.02 секунды

Explain запроса хранимой процедуры
id    select_type    table    type    possible_keys    key    key_len    ref    rows    filtered    Extra
1    SIMPLE    t1    range    PRIMARY    PRIMARY    8        1000    100    Using where; Using filesort
1    SIMPLE    t2    ref    idSite    idSite    8    info.t1.id    1    100   

Используется filesort, но думаю проблема не в этом, т.к. отсортировать 1000 строк ерундовое дело.
Мне кажется что после старта Mysql может быть не загружает в свой кэш информацию о индексах таблиц или чтото подобное, и поэтому тормозит. И еще небольшое наблюдение - до выполнения команды Optimize table t1, t2; объем потребляемой памяти около 250мб, а после уже около 400-500мб. Т.е. он чтото загрузил в память.

В чем может быть проблема? Если это проблема в кэшировании индексов(или чегото другого важного) как заставить mysql принудительно при старте кэшировать инфу нужной мне БД?

Неактивен

 

#2 28.06.2010 15:30:43

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: Странное поведение Mysql до и после Optimize table

1. Не 1000, а 10000 ( = 100 × 100 ).
2. Никак, можете, например, делать SELECT * FROM tablename — оно
загрузит данные в кэш. У XtraDB была, вроде бы, возможность скидывать
кэши на диск (ну и, соответственно, подгружать после старта сервера).

Неактивен

 

#3 28.06.2010 16:50:53

boa
Завсегдатай
Зарегистрирован: 22.06.2010
Сообщений: 38

Re: Странное поведение Mysql до и после Optimize table

paulus написал:

1. Не 1000, а 10000 ( = 100 × 100 ).
2. Никак, можете, например, делать SELECT * FROM tablename — оно
загрузит данные в кэш. У XtraDB была, вроде бы, возможность скидывать
кэши на диск (ну и, соответственно, подгружать после старта сервера).

Сделал небольшой эксперимент.
Остановил mysqld, запустил.
Посылаю запросы - среднее время 0.7 сек(разброс от 0.5 до 1.5)

Сделал выборку
SELECT * FROM t1;
SELECT * FROM t2;
Посылаю запросы - среднее время 0.2 сек(разброс от 0.1 до 0.3)

Сделал OPTIMIZE TABLE t1, t2;
Посылаю запросы - среднее время ~0.03 сек(разброс от 0.01 до 0.1)

Заметил что после выборки  SELECT * FROM t1; SELECT * FROM t2; с течением времени время выполнения одного запроса уменьшается.

Написал небольшой тест. В цикле посылал разные запросы, за один цикл прогонял по 1000.
После нескольких циклов время выполнения 1го запроса стало вполне приемлемым.
Как оказалось просто нужно время для разогревания кэша.
После разгоревания кэша запросы выполняются меньше чем за 0,01 что очень хорошо smile
Но все же было бы удобно иметь какой нибудь инструмент для форсирования нагрева кэша. Поначалу совсем туго все.

Неактивен

 

#4 28.06.2010 17:06:03

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: Странное поведение Mysql до и после Optimize table

В MyISAM есть возможность подгрузить ключи в память
(http://dev.mysql.com/doc/refman/5.0/en/load-index.html)

Если нужен транзакционный движок, то тогда, видимо, XtraDB
(http://www.percona.com/docs/wiki/percon … mp_restore)

Неактивен

 

#5 28.06.2010 17:17:56

boa
Завсегдатай
Зарегистрирован: 22.06.2010
Сообщений: 38

Re: Странное поведение Mysql до и после Optimize table

paulus написал:

Если нужен транзакционный движок, то тогда, видимо, XtraDB
(http://www.percona.com/docs/wiki/percon … mp_restore)

спасибо за совет. буду смотреть в сторону XtraDB, потестирую и если все будет хорошо введу в использование на серверах.

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson