Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Добрый день.
Опишу БД и запрос, и потом скажу в чем суть проблемы.
Есть БД с двумя табличками
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 принудительно при старте кэшировать инфу нужной мне БД?
Неактивен
1. Не 1000, а 10000 ( = 100 × 100 ).
2. Никак, можете, например, делать SELECT * FROM tablename — оно
загрузит данные в кэш. У XtraDB была, вроде бы, возможность скидывать
кэши на диск (ну и, соответственно, подгружать после старта сервера).
Неактивен
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 что очень хорошо
Но все же было бы удобно иметь какой нибудь инструмент для форсирования нагрева кэша. Поначалу совсем туго все.
Неактивен
В MyISAM есть возможность подгрузить ключи в память
(http://dev.mysql.com/doc/refman/5.0/en/load-index.html)
Если нужен транзакционный движок, то тогда, видимо, XtraDB
(http://www.percona.com/docs/wiki/percon … mp_restore)
Неактивен
paulus написал:
Если нужен транзакционный движок, то тогда, видимо, XtraDB
(http://www.percona.com/docs/wiki/percon … mp_restore)
спасибо за совет. буду смотреть в сторону XtraDB, потестирую и если все будет хорошо введу в использование на серверах.
Неактивен
Страниц: 1