对超过 100 万行的表运行查询

发布于 2024-11-06 02:05:46 字数 238 浏览 0 评论 0原文

我正在对我在“Where / Order by”中使用的所有列建立索引,我还能做些什么来加快查询速度吗?

查询非常简单,例如:

SELECT COUNT(*) 
  FROM TABLE 
 WHERE user = id 
   AND other_column = 'something'`

我使用 PHP 5,MySQL 客户端版本:4.1.22,我的表是 MyISAM。

I am indexing all the columns that I use in my Where / Order by, is there anything else I can do to speed the queries up?

The queries are very simple, like:

SELECT COUNT(*) 
  FROM TABLE 
 WHERE user = id 
   AND other_column = 'something'`

I am using PHP 5, MySQL client version: 4.1.22 and my tables are MyISAM.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

眼眸里的快感 2024-11-13 02:05:46

与您的 DBA 交谈。运行本地的 showplan 等效项。对于像您的示例这样的查询,我怀疑列 idother_column 上的覆盖索引会大大提高性能。 (我假设user是一个变量或niladic函数)。

一个好的通用规则是索引中的列应按方差降序从左到右排列。也就是说,值变化最快的列应该是索引中的第一列,变化最慢的列应该是索引中的最后一列。似乎违反直觉,但就是这样。查询优化器喜欢尽快缩小范围。

Talk to your DBA. Run your local equivalent of showplan. For a query like your sample, I would suspect that a covering index on the columns id and other_column would greatly speed up performance. (I assume user is a variable or niladic function).

A good general rule is the columns in the index should go from left to right in descending order of variance. That is, that column varying most rapidly in value should be the first column in the index and that column varying least rapidly should be the last column in the index. Seems counter intuitive, but there you go. The query optimizer likes narrowing things down as fast as possible.

分开我的手 2024-11-13 02:05:46

如果您的所有查询都包含用户 ID,那么您可以首先假设 userid 应包含在每个索引中,可能作为第一个字段。 (我们可以假设用户 ID 具有高度选择性吗?即任何单个用户都不会拥有超过数千条记录?)

因此您的索引可能是:

user + otherfield1
user + otherfield2
etc.

如果您的用户 ID 确实具有选择性,例如几十条记录,那么仅该字段上的索引应该非常有效(亚秒返回)。

“user + otherfield”索引的好处是mysql甚至不需要查看数据记录。索引对于每条记录都有一个指针,并且它只能对指针进行计数。

If all your queries include a user id then you can start with the assumption that userid should be included in each of your indexes, probably as the first field. (Can we assume that the user id is highly selective? i.e. that any single user doesn't have more than several thousand records?)

So your indexes might be:

user + otherfield1
user + otherfield2
etc.

If your user id is really selective, like several dozen records, then just the index on that field should be pretty effective (sub-second return).

What's nice about a "user + otherfield" index is that mysql doesn't even need to look at the data records. The index has a pointer for each record and it can just count the pointers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文