寻求用于访问唯一 MySQL 条目的高性能解决方案

Question

I know very little about MySQL (or web development in general). I'm a Unity game dev and I've got a situation where users (of a region the size of which I haven't decided yet, possibly globally) can submit entries to an online database. The users must be able to then locate their entry at any time.

For this reason, I've generated a guid from.Net (System.Guid.NewGuid()) and am storing that in the database entry. This works for me. However.., I'm no expert. but my gut tells me that looking up a complex string in what could be a gargantuan table might have terrible performance.

That said, it doesn't seem like anything other than a globally unique identifier will solve my problem. Is there a more elegant solution that I'm not seeing, or a way to mitigate against any issues this design pattern might create?

Thanks!

Answer 1

Make sure you define the GUID column as the primary key in the MySQL table. That will cause MySQL to create an index on it, which will enable MySQL to quickly find a row given the GUID. The table might be gargantuan but (assuming a regular B-tree index) the time required for a lookup will increase logarithmically relative to the size of the table. In other words, if it requires 2 reads to find a row in a 1,000-row table, finding a row in a 1,000,000-row table will only require 2 more reads, not 1,000 times as many.

As long as you have defined the primary key, the performance should be good. This is what the database is designed to do.

Obviously there are limits to everything. If you have a billion users and they're submitting thousands of these entries every second, then maybe a regular indexed MySQL table won't be sufficient. But I wouldn't go looking for some exotic solution before you even have a problem.

Answer 2

If you have a key of the row you want, and you have an index on that key, then this query will take less than a second, even if the table has a billion rows:

SELECT ... FROM t WHERE id = 1234.

The index in question might be the PRIMARY KEY , or it could be a secondary key.

GUIDs/UUIDs should be used only if you need to manufacture unique ids in multiple clients without asking the database for an id. If you do use such, be aware that GUIDs perform poorly if the table is bigger than RAM.