2010-06-04 100 views
1

我知道我正在写查询的错误,当我们得到大量的流量时,我们的数据库被击中硬盘和页面变慢... 我想我需要写查询基于来自CURDATE的最近30天的CREATE VIEW?但不知道从哪里开始,或者如果这将更有效地查询数据库?最近30天为MYSQL创建视图

不管怎么说,这里是我写了一个简单的查询..

$query_Recordset6 = "SELECT `date`, title, category, url, comments 
         FROM cute_news 
         WHERE category LIKE '%45%' 
        ORDER BY `date` DESC"; 

任何帮助或建议将是巨大的!我有大约11个这样的疑问,但我有信心,如果我能得到其中的一个帮助,那么我可以将它们实施到其余的!

回答

0
SELECT `date`, title, category, url, comments 
         FROM cute_news 
         WHERE category LIKE '%45%' 
        ORDER BY `date` DESC 

LIKE '%45%'表示需要执行全表扫描。你可能在列中存储了一个类别列表?如果这样创建一个新的表存储类别和news_article_id将允许索引被用来更有效地检索匹配记录。

2

把一个通配符上的值进行比较的左侧:

LIKE '%xyz' 

...意味着一个索引不能被使用,即使存在一个。可能要考虑使用Full Text Searching (FTS), which means adding full text indexing

正常化数据是另一个需要考虑的步骤 - 类别应该放在单独的表格中。

+0

想知道这会更好吗? 选择...从...限制50 – eberswine 2010-06-04 19:26:20

0

好吧,精神调试的时间。

在我的大脑中,我发现通过数据库规范化可以大大提高查询性能,具体方法是将类别多值列拆分为具有两列的单独表:cute_news的主键和类别ID。

这也可以让你直接链接所说的表到类别表,而不必先解析它。或者,正如Chris Date所说:“每一行与列的交集都只包含来自适用域的一个值(而不是其他任何东西)”。

0

任何带有'%XXX%'的东西都会变慢。这是一个缓慢的操作。

对于类似的东西,您可能希望将类别分隔到另一个表中,并在cute_news表中使用外键。这样你就可以拥有category_id,并在查询中使用它,速度会更快。


另外,我不太清楚你为什么要讨论使用CREATE VIEW。意见不会真正帮助你提高速度。除非它具有物化视图,MySQL本身并不假设。

0

如果您的数据库受到重创,解决方案不是创建视图(视图基本上与数据库的工作量基本相同),解决方案是缓存结果。

这尤其适用,因为从听起来像,你的数据只需要每30天刷新一次。

0

我猜你的category列是类别值的列表,如“12,34,45,78”?

这不是很好的关系型数据库设计。不好的一个原因是你已经发现:搜索可能出现在该列表中间的子字符串的速度非常慢。

有人建议使用全文搜索,而不是LIKE谓语用通配符,但在这种情况下,它是简单的创建另一个表,所以你可以列出每行一个类别值,与参考回到你cute_news表:

CREATE TABLE cute_news_category (
    news_id INT NOT NULL, 
    category INT NOT NULL, 
    PRIMARY KEY (news_id, category), 
    FOREIGN KEY (news_id) REFERENCES cute_news(news_id) 
) ENGINE=InnoDB; 

然后你就可以查询它会去快了很多:

SELECT n.`date`, n.title, c.category, n.url, n.comments 
FROM cute_news n 
JOIN cute_news_category c ON (n.news_id = c.news_id) 
WHERE c.category = 45 
ORDER BY n.`date` DESC 
0

任何答案是猜测,显示:
- 相关SHOW CREATEŧ ABLE输出
- 常见查询的EXPLAIN输出。

Bill Karwin的评论当然适用。

毕竟这个&优化,只有过去30天的数据采样到一张表格仍然可能是需要的,在这种情况下,你最好运行每日cronjob做到这一点。