MySQL：一个巨大的表。无法查询，甚至是简单的选择！答案

【问题标题】：MySQL: a huge table. can't query, even a simple select!MySQL：一个巨大的表。无法查询，甚至是简单的选择！
【发布时间】：2010-03-05 12:38:17
【问题描述】：

我有一个包含大约 200,000 条记录的表。做一个简单的选择查询需要很长时间。我很困惑，因为我在 4 核 cpu 和 4GB 内存下运行。我应该如何写我的查询？或者与索引有什么关系？

重要提示：我的表格是静态的（它的数据不会改变）。

你的解决方案是什么？

附言

1 - 我的表有一个主键 id

2 - 我的表有一个唯一键 serial

3 - 我想查询 where param_12 not like '%I.S%' 等其他字段或where param_13 = '1'

4 - 200,000 并不大，这正是我感到惊讶的原因。

5 - 添加简单字段时我什至遇到问题：my question

6 - 我可以为 BOOL 字段创建索引吗？（或者有用吗）

PS并感谢您的回答

7 - 我的选择应该返回已指定“I.S”或未指定的字段。

select * from `table` where `param_12` like '%I.S%'

这就是我想要的。似乎没有索引在这里有帮助。火腿肠？

【问题讨论】：

了解有关表大小、正在运行的选择查询类型、存储的数据类型、架构等的更多信息会有所帮助。另外，您对“很长一段时间”的定义是什么？秒？分钟？
Dav 所说的，是的，它可能与索引有关。

标签： mysql performance select

【解决方案1】：

索引会有所帮助。请发布表定义并选择查询。
为 where 子句中的所有“=”列添加索引。

【讨论】：

【解决方案2】：

是的，您希望/需要为该表编制索引，并且分区也会有所帮助。正确执行此操作是您需要提供更多信息的事情。您将需要使用 EXPLAIN PLAN 并查看您的查询以确定哪些列以及您应该如何索引它们。

另一个需要考虑的方面是您的表格是否标准化。由于降低了 I/O，规范化表往往会提供更好的性能。

我意识到这很模糊，但没有更多信息，我们可以尽可能具体。

顺便说一句：200,000 行的表相对较小。

Here 是另一个你可能会觉得有用的 SO 问题

【讨论】：

正如您自己所说，200.000 条记录并不多。我相信不应该需要分区。内存中的良好索引和索引缓存应该可以解决问题。
我同意，我通常不会对这种大小的表进行分区，尽管根据情况和表的宽度，它仍然可以提供性能优势。

【解决方案3】：

1 - 我的表有一个主键 id：除非你使用一些需要数字主键的方案，否则没什么用处

2 - 我的表有一个唯一的密钥序列： id 根据定义也是唯一的；为什么不使用串行作为主要？这个是自动索引的，因为您将它定义为唯一的。

3 - 我想查询其他字段，例如 where param_12 not like '%I.S%' 或 where param_13 = '1': A like '%something%' 查询不能真正使用索引；有什么方法可以将 param12 更改为 param 12a（第一个 %）和 param12b（'I.S%'）？如果起始字符串已知，则可以在 like 语句上使用索引。

4 - 200,000 并不大，这正是我感到惊讶的原因：是的，200.000 并不多。但是如果没有良好的索引、查询和/或缓存大小，MySQL 将需要从磁盘读取所有数据进行比较，这很慢。

5 - 添加简单字段时我什至遇到问题：我的问题

6 - 我可以为 BOOL 字段创建索引吗？是的，你可以，但是匹配一半时间的索引是相当无用的，索引用于限制 MySQL 必须尽可能完全加载的记录数量；如果索引没有显着限制该数字，就像布尔值（在 50-50 分布中）一样，使用索引只需要更多的磁盘 IO 并且可能会减慢搜索速度。因此，除非您期望像 80-20 分布或更好的分布，否则创建索引将花费时间，而不是赢得时间。

【讨论】：

【解决方案4】：

可能会使用param_13 上的索引，但在此示例中不会使用param_12 上的索引，因为使用LIKE '% 会否定索引的使用。

【讨论】：

【解决方案5】：

如果您使用LIKE '%asdasdasd%' 查询数据，那么没有索引可以帮助您。每次都必须进行全面扫描。这里的问题是领先的%，因为这意味着您要查找的子字符串可以在该字段中的任何位置 - 所以它必须全部检查。

您可能会考虑全文索引，但根据您的需要可能不合适。

【讨论】：

【解决方案6】：

首先，确保您的表有一个主键。

要更详细地回答，您需要提供有关表结构和正在运行的查询类型的更多信息。

【讨论】：

主键不是解决方案，除非它是查询数据的键。

【解决方案7】：

我不相信你拥有的钥匙会有帮助。您必须对 WHERE 子句中使用的列进行索引。

我还想知道 LIKE 是否需要不考虑索引的表扫描。使用这样的函数的那一刻，您就会丢失索引的值，因为您必须检查每一行。

你说得对：200K 并不是一张大桌子。解释计划将在这里提供帮助。如果您看到 TABLE SCAN，请重新设计。

【讨论】：