我试着轻轻地刺激一些真实的数字。由于您不准备说出您的“ec2 微型实例”在可用的 GHz/RAM/磁盘 I/O 方面实际上有什么,我们将不得不以另一种方式尝试。
CREATE TABLE tokens(tok text, username text);
INSERT INTO tokens SELECT md5(i::text), 'User number ' || i FROM generate_series(1,1000000) i;
SELECT * FROM tokens WHERE username LIKE '%01' LIMIT 19;
-- Now check the timings on some of returned tokens
EXPLAIN ANALYSE SELECT username FROM tokens WHERE tok = '38b3eff8baf56627478ec76a704e9b52';
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
Index Scan using tokens_pkey on tokens (cost=0.42..8.44 rows=1 width=18) (actual time=0.099..0.101 rows=1 loops=1)
Index Cond: (tok = '38b3eff8baf56627478ec76a704e9b52'::text)
Total runtime: 0.133 ms
(3 rows)
如您所见 - 我的运行速度如此之快,以至于时间可能毫无意义。如果我在乎的话,我会从 10 个并行进程中运行 10000 个,并随机等待。我没有——它不到 1 毫秒,即使在我期望的最慢的虚拟机上也小于 5 毫秒。
那么-您的应用程序有问题吗?不能说 - 你没有提供细节。
是你的框架吗?不能说——你不会说。
是连接时间吗?说不出来...
是查询本身吗?说不出来...
不过,PostgreSQL使用索引从 100 万行的小表中读取单行的任何问题都不是问题。
祝你好运!