索引还是唯一? MySql 哪个更好

发布于 2024-11-11 09:53:20 字数 544 浏览 2 评论 0原文

所以我有一个问题。

假设您有一个表请求,它代表一个图表。请求表中有3列,A、B、时间。 A-> B 到时候。因此,每一行代表的是在时间 T 处从 A(请求者)到 B(被请求者)的定向连接(时间只是用于组织数据,而不是用于其他任何事情)。

那么,如果假设请求为 1,000,000 行,什么会更快。
索引(A、B) 索引(A)和索引(B) 唯一(A,B)?

谢谢你们! A、B 是 VARCHAR(32)(MD5)

抱歉,我忘记了一个典型的查询。
我需要能够查看用户 A(已登录)是否有任何请求!
我还需要进行搜索以验证用户是否已接受正确的请求,A 接受 B。

因此语句如下所示。

有什么新要求吗?

SELECT B, time
FROM requests
WHERE A='$id';  

A 有 B 的请求吗?

SELECT time
FROM requests
WHERE A='$A' and B='$B';

So i have a question.

Say you have a table requests, which represent a graph. There are 3 columns in the request table, A, B, time. A -> B At time. So what each row represents is a directed connection from A (the requestor) to B (the requestee) at Time T (time is just for organizing data, not really for anything else).

So what is faster if say requests were 1,000,000 rows.
Index(A, B)
Index(A) and Index(B)
Unique(A, B)?

Thanks guys! And A, B are VARCHAR(32) (MD5's)

Sorry, i forgot a typical query.
I need to be able to see if User A (who logged on) has any requests!
I also will need to search to verify that a user has accepted a correct request, A Accepts B.

So the statements will look like.

Any new requests?

SELECT B, time
FROM requests
WHERE A='$id';  

Does A have a request from B?

SELECT time
FROM requests
WHERE A='$A' and B='$B';

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

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

发布评论

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

评论(2

狂之美人 2024-11-18 09:53:20

索引和唯一性是两个完全不同的概念。

索引
索引是一个隐藏的额外列,保存与实际数据的指针排序的相同数据。使用索引,您可以

  1. 快速查找特定项目
  2. 快速查找一系列项目(x 和 y 之间)
  3. 使用 order by 时节省时间,因为项目已预先排序
  4. 节省时间使用group by因为group by需要匹配相同的项

这是一个普通的索引,它不介意重复的值,除了主键总是唯一的。

唯一(索引)
如果您想避免重复值,可以在其上放置唯一索引。这将完成上述所有操作,但对每次更新和插入添加额外检查,以检查该值是否尚未存在于数据库中。如果您尝试在唯一列上插入重复行,MySQL 将给出错误并拒绝您的插入。
(不使用索引就无法使行唯一

使用索引会减慢插入和更新速度。
使用唯一索引会减慢甚至更慢。

然而索引大大加快了选择的速度。
Unique 不会加快任何速度,它可以确保您不会意外插入重复行。

何时使用索引,何时不使用索引
不要在每个字段上都放置索引。如上所述,它会减慢插入更新的速度。
始终在连接条件上放置索引。并认真考虑在 where 子句中经常使用的列上放置索引。
如果 50% 的行在某个字段中具有相同的值,MySQL 将拒绝使用索引,因此请忘记布尔 (Y/N) 字段上的索引,99% 的情况下它们将不起作用.
(低基数字段中的索引没有用)

始终分配主键
不过,请始终在表上分配一个主键。最好是整数自动增量类型。如果没有分配主键,MySQL将为您分配一个“隐藏”主键(整数自动增量类型),但您不能使用隐藏的PK来加快报价或识别您的行,并且隐藏 PK 还存在许多其他缓慢问题,这使它们非常糟糕。

希望这有帮助。

链接:
MySQL 如何使用索引: http://dev.mysql.com/doc/refman/5.5 /en/mysql-indexes.html
何时使用索引: http://www.howtoforge.com/when-to-use -mysql 数据库中的索引
更多相关内容: http://www.databasejournal .com/features/mysql/article.php/1382791/Optimizing-MySQL-Queries-and-Indexes.htm
如果你想了解更多关于MySQL的信息,最后潜伏在这里:http://planet.mysql.com/

Index and unique are two completely different concepts.

Indexes
An index is a hidden extra column holding the same data sorted with a pointer to your real data. Using an index you can

  1. Quickly find a particular item
  2. Quickly find a range of items (between x and y)
  3. Save time when using order by because the items are presorted
  4. Save time when using group by because group by needs to match identical items

This is a normal index, it doesn't mind duplicate values, except for the primary key which is always unique.

Unique (Index)
If you want to avoid duplicate values you can put a unique index on it. This will do all of the above, but add an extra check on every update and insert to check whether that values is not already in the database. If you try to insert a duplicate row on a unique column, MySQL will give an error and refuse your insert.
(you cannot make a row unique without using an index)

Use of indexes slows inserts and updates down.
Use of unique indexes slows then even more down.

However indexes speed up select a lot, a whole lot.
Unique doesn't speed up anything it makes sure you don't accidentally insert a duplicate row.

When to use indexes and when not
Don't put an index on every field. As stated above it will slow you inserts and updates down.
Always put an index on join criteria. And seriously consider putting an index on column you use in where clauses a lot.
MySQL will refuse to use an index if 50% of your rows have the same value in a field, so forget about indexes on boolean (Y/N) fields, 99% of the time they will not work.
(Indexes in low cardinality fields are not useful)

Always assign a primary key
Always assign a primary key on your table though. Preferably of type integer autoincrement. If you don't assign a primary key, MySQL will assign a 'hidden' primary key for you (of type integer autoincrement), but you cannot use the hidden PK to speed up quotes or identify your rows and there are a host of other slowness problems with hidden PK's which make them suck very badly.

Hope this helps.

Links:
How MySQL uses indexes: http://dev.mysql.com/doc/refman/5.5/en/mysql-indexes.html
When to use indexes: http://www.howtoforge.com/when-to-use-indexes-in-mysql-databases
More of that stuff: http://www.databasejournal.com/features/mysql/article.php/1382791/Optimizing-MySQL-Queries-and-Indexes.htm
Finally lurk here if you want to know more about MySQL: http://planet.mysql.com/

季末如歌 2024-11-18 09:53:20

在这种特定情况下,请使用包含 A 和 B 的复合索引。确保 A 位于索引中的第一个。这样,当您运行这两个查询时,索引将用于这两个查询。

有关复合索引的更多信息:

http://dev.mysql。 com/doc/refman/5.5/en/multiple-column-indexes.html

此外,唯一性(A,B)并不重要,除非您的要求是 B 最多只能请求 A强>一次。

In this specific case, use a composite index including A and B. Make sure that A is first in the index. That way when you run these two queries, the index would be used for both.

More on composite indexes:

http://dev.mysql.com/doc/refman/5.5/en/multiple-column-indexes.html

Also, uniqueness (A,B) shouldn't matter unless your requirement is that B can only request A at most once.

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