|
|
|
| Подскажите пожалуйста, есть сайн новостной в нем более 50000 записей новостных, а также комментарии, новостная таблица весит около 430 мб. сайт стал намного медленнее работать, хотя где мог сделал хеширование.
как можно ускорить загрузку сайта? или есть смысл поменять базу MySQl на чтото другое?
еще сказали можно работать через PDO
http://www.google.ru/search?aq=f&sourceid=chrome&ie=UTF-8&q=pdo
но чтото я не понял как это может ускорить работу. подскажите пожалуйста как быть | |
|
|
|
|
|
|
|
для: dirol
(01.07.2011 в 10:30)
| | 50 тыщ записей это не много.
Может у тебя индексы не проставлены на тех полях, по которым происходит выборка?
У меня база на 200 тыщ записей, работает все прекрасно. | |
|
|
|
|
|
|
|
для: dirol
(01.07.2011 в 10:30)
| | появились медленные запросы.
подскажите что в них неправильно
0.42814 сек. - [SELECT a.id, a.cid, a.name, a.title, UNIX_TIMESTAMP(a.time) as formatted, a.hometext, a.comments, a.acomm, a.votes, a.totalvotes, a.code, a.images, c.counter FROM cms_news
AS a LEFT JOIN cms_counter AS c ON (a.id=c.nid) WHERE cid IN (1, 10,11,12)
AND a.time <= NOW() AND a.status ='1' AND c.modul='news' ORDER BY a.time DESC LIMIT 0, 20]
0.00312 сек. - [SELECT a.id, a.cid, Count(b.cid) AS tmp FROM cms_comment AS b INNER JOIN cms_news
AS a ON (a.id=b.cid) WHERE b.status='1' GROUP BY a.id, a.cid]
0.00012 сек. - [SELECT id FROM cms_categories WHERE modul='news' ORDER BY id]
0.09173 сек. - [SELECT Count(id) FROM cms_news WHERE cid IN (1,2,3,4,5,6,7,8,10,11,12,13,14,15,16,17,91,101,111,141,151,161,171,181,191,201)
AND cid IN (1, 10,11,12) AND time <= NOW() AND status ='1' ORDER BY time DESC]
8.0E-5 сек. - [SELECT title, content FROM cms_blocks WHERE bkey='admin']
0.00052 сек. - [SELECT * FROM cms_users WHERE user_id='8781']
5.0E-5 сек. - [SELECT DAYOFMONTH(time) as day FROM cms_news WHERE DATE_FORMAT(time, '%Y-%m') = '2011-07'
AND time < '2011-07-05 10:40:59' GROUP BY DAYOFMONTH(time)]
0.10934 сек. - [SELECT a.id, a.cid, a.modul, UNIX_TIMESTAMP(a.date) as formatted, a.uid, a.name, a.comment, a.status, u.user_name, u.user_names, u.user_surname FROM cms_comment
AS a LEFT JOIN cms_users AS u ON (a.uid=u.user_id) WHERE a.status='1' ORDER BY a.date DESC LIMIT 10]
|
| |
|
|
|
|
|
|
|
для: dirol
(05.07.2011 в 10:29)
| | Без знания объема таблица, того как они проиндексированы сложно посоветовать что-то конкретное... | |
|
|
|
|
|
|
|
для: cheops
(05.07.2011 в 11:49)
| |
CREATE TABLE IF NOT EXISTS `cms_news` (
`id` int(11) NOT NULL auto_increment,
`cid` int(11) default '0',
`uid` int(11) NOT NULL default '0',
`name` varchar(25) NOT NULL,
`title` varchar(299) default NULL,
`title2` varchar(299) NOT NULL,
`podsubject` varchar(1000) NOT NULL,
`time` datetime default NULL,
`hometext` text,
`bodytext` text NOT NULL,
`banner` text NOT NULL,
`field` text NOT NULL,
`comments` int(11) default '0',
`counter` int(11) NOT NULL default '0',
`ihome` int(1) NOT NULL default '0',
`acomm` int(1) NOT NULL default '0',
`votes` int(11) default '0',
`totalvotes` int(11) default '0',
`associated` text NOT NULL,
`ip_sender` varchar(60) default NULL,
`status` int(1) NOT NULL default '0',
`code` int(15) NOT NULL,
`images` varchar(200) NOT NULL,
`keywords` varchar(300) NOT NULL,
`consol` int(1) default '0',
`star` int(1) NOT NULL default '0',
`subscription` varchar(200) NOT NULL,
`election` int(1) NOT NULL,
`gender` int(1) NOT NULL default '0',
`izbranoe` int(1) NOT NULL,
`author` varchar(200) NOT NULL,
`nomer` varchar(50) NOT NULL,
`sortirofka` int(1) NOT NULL default '0',
`fix` int(1) NOT NULL,
`anons` int(1) NOT NULL,
`perewod` int(1) NOT NULL default '0',
`fixup` int(1) NOT NULL,
`fixcenter` int(1) NOT NULL,
PRIMARY KEY (`id`),
KEY `counter` (`counter`),
KEY `cid` (`cid`),
KEY `acomm` (`acomm`),
KEY `consol` (`consol`),
KEY `star` (`star`),
KEY `election` (`election`),
KEY `gender` (`gender`),
KEY `izbranoe` (`izbranoe`),
KEY `sortirofka` (`sortirofka`),
KEY `fix` (`fix`),
KEY `anons` (`anons`),
KEY `perewod` (`perewod`),
KEY `fixup` (`fixup`),
KEY `fixcenter` (`fixcenter`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=67622 ;
|
объем таблицы 30,520 строк и 400мб | |
|
|
|
|
|
|
|
для: dirol
(05.07.2011 в 12:14)
| | А cms_counter? Вообще таблицы уже довольно большие. Вам все новости в них нужны, может стоит их разделить на несколько? | |
|
|
|
|
|
|
|
для: dirol
(05.07.2011 в 12:14)
| | >cid IN (1, 10,11,12)
cid - это что такое и как много записей условие отбирает, и как много записей оно отбрасывает? | |
|
|
|
|
|
|
|
для: cheops
(05.07.2011 в 12:23)
| | cid это категории новостей. вот выводятся новости из категорий 1,10,11,12 всего записей в категориях 62 | |
|
|
|
|
|
|
|
для: dirol
(05.07.2011 в 12:27)
| | Попробуйте это условие передвинуть в ON, чтобы объединенные таблицы были поменьше. Дело в том, что WHERE применяется к записям когда уже сформирована промежуточная таблица. | |
|
|
|
|
|
|
|
для: cheops
(05.07.2011 в 12:43)
| | и звените а примером не покажите ? в запросе ON надо поставить?
щас запрос выполняется так
$result = $db->sql_query("(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM ".$prefix."_news WHERE cid IN (".$id.") AND
status!='0' AND time <= NOW() ORDER BY time DESC LIMIT $ord, $lim)");
|
| |
|
|
|
|
|
|
|
для: dirol
(05.07.2011 в 13:01)
| | Погодите, это же однотабличный запрос, разве он медленно выполняется? Насколько я понял из отчета, проблема именно с многотабличными запросами? | |
|
|
|
|
|
|
|
для: cheops
(05.07.2011 в 13:27)
| | он тоже не быстрый
0.5542 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (1,10,11,12) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.10686 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (1,10,11,12) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
0.12245 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (2,13,14,15,16) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.11618 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (2,13,14,15,16) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
0.02667 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (6,91,101) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.02664 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (6,91,101) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
0.02086 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (3,111) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.02062 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (3,111) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
0.01316 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (5,181,191) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.01539 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (5,181,191) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
0.01903 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (4,161) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.01773 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (4,161) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
0.02358 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (7,201,141,151,17) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.02407 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (7,201,141,151,17) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
0.01037 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (8,171) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 3, 5)]
0.01005 сек. - [(SELECT id, cid, title, UNIX_TIMESTAMP(time) as formatted, hometext, bodytext, acomm, status, code, images FROM cms_news WHERE cid IN (8,171) AND status!='0' AND time <= NOW() ORDER BY time DESC LIMIT 0, 3)]
|
| |
|
|
|
|
|
|
|
для: dirol
(05.07.2011 в 13:34)
| | Скорее всего он быстрый, просто ресурсы MySQL оттянуты на действительно медленные запросы, они работают, потребляют процессорное время и память - это приводит к замедлению всех остальных запросов. Если бы их не было, скорее всего скорость однотабличных запросов возрасла.
В любом случае для ускорения этого запроса нужны другие индексы - многотабличные, у вас индекс используется только для cid IN (8,171) - все остальные сравнения не участвуют в индексах, а просто перелопачивают всю таблицу. Кроме этого time лучше перевести в UNIXSTAMP - занимать он будет в несколько раз меньше времени, а сравнение будет протекать в несколько раз быстрее. | |
|
|
|
|
|
|
|
для: cheops
(05.07.2011 в 14:48)
| | PRIMARY KEY (`id`),
KEY `cid` (`cid `, `sortirofka`,`fix`,`anons`,`perewod`,`fixup`,`fixcenter`)
а так правильнее? | |
|
|
|
|
|
|
|
для: dirol
(05.07.2011 в 15:12)
| | Да вы сами проверьте, ускоряются у вас эти запросы или нет? | |
|
|
|
|