MySQL 性能 - 100 万条记录 - 在文本字段前选择 Int

Question

显然，从 100 万条记录中选择一个文本字段会很慢，因此不推荐使用。这里有两种可能的解决方案。

1. 打破数据库，为每个用户提供自己的数据库或表，从而显着减少每个表中的总记录数。

2. 执行 SQL SELECT 查询以匹配 INT，其中 INT 是用户 ID，然后匹配文本字段。

选项 1 会带来明显的性能提升。但是选项 2 也会提供 yield 吗？在语句中，如果我们首先匹配 INT，这是否会将结果集缩小到仅匹配的记录，然后执行文本字段搜索。例如..

$user_id = 1001;
$domain_name = "mydomain.com";
$query = $database->prepare("SELECT * FROM domains_table WHERE user_id = $user_id && domain_name = $domain_name");

在上述查询中切换 user_id 和 domain_name 的位置会破坏性能。首先匹配 user_id 在这里有优势吗？

Answer 1

你一直在说事情是“显而易见的”。您是否对它们进行了测量以进行比较，或者您是否在做出假设？

使用索引，可以非常快速地搜索字符串。如果您没有有索引，肯定比搜索整数快得多。

一旦使用索引，整数搜索和字符串搜索之间的区别几乎是不可察觉的。

最好的索引是两列的复合索引:

ALTER TABLE domains_table ADD INDEX (user_id, domain_name);

想想电话簿。这本书按姓氏排序，然后按名字排序。如果您搜索“Smith, John”，您可以轻松地将搜索范围缩小到所有 Smiths，然后在该子集中，名称按名字排序，因此您可以轻松搜索所有名为 John 的人。这就是复合索引的工作原理。

如果没有索引，就好像要从头到尾搜索整本电话簿。这称为表扫描，它变得越来越昂贵，与表的大小成正比。表的大小也会使索引查找变慢，但这次它增加的成本与表大小的对数成正比。

在其他评论中，您了解到优化器可以重新排序 WHERE 子句中的术语，以匹配索引中列的顺序。这是真实的。这是查询优化器的工作，您可能使用的所有 RDBMS 产品(包括 MySQL)都足够智能来执行此操作。

您可能想阅读我的演示文稿 How to Design Indexes, Really .或者我介绍这个演讲的视频:https://www.youtube.com/watch?v=ELR7-RdU9XU

还有一个很棒的网站，其中包含许多关于索引的提示:Use the Index, Luke .