我该如何改进此查询？ 请告诉我我在这里的所有选项，因为我的社交网络数据库只是变大了
此查询耗时2.1231秒
SELECT friend_friend.friendid, friend_reg_user.disp_name, friend_reg_user.pic_url, friend_reg_user.online
FROM friend_friend
INNER JOIN friend_reg_user ON friend_friend.friendid = friend_reg_user.auto_id
WHERE userid =1
AND friend_friend.status =1
ORDER BY autoid DESC
LIMIT 59535 , 15
#####################################################################################################################################
# id # select_type # table # type # possible_keys # key # key_len # ref # rows # Extra #
#####################################################################################################################################
# 1 # SIMPLE # friend_friend # ref # userid # userid # 5 # const # 59843 # Using where#
# 1 # SIMPLE # friend_reg_user # eq_ref # PRIMARY # PRIMARY # 4 # friend_friend.friendid # 1 # #
#####################################################################################################################################
当这张表说一百万甚至两百万行时，我有什么选择？此表用于确定谁是用户朋友
答案 0 :(得分：2)
我认识一个程序员在他的数据库中处理了800万条记录，但实际上并没有太大改变速度。它只是创建正确的索引并确保您以有效的方式获取数据。 （关系的数字ID非常有用）
此外，您的查询在很大程度上是非常准确的。没什么太花哨的。它可能只是您的服务器延迟。
答案 1 :(得分：2)
也许我并不真正了解您的架构，但您真的需要LEFT JOIN吗？你能否使用INNER JOIN？
（我经常听说它可能更适合表演，因为它会减少线条;在你的情况下，如果你想要一个人的朋友，我看不到左联盟的意义：朋友会“链接“，所以，在”链接“表中有一个条目，不是吗？）
另外，请确保您使用的字段包含索引：
MySQL在某些应用程序中使用了非常大的表，如果索引/配置正常，它可以非常快地回答;所以，我们应该能够在这里做一些事情; - ）
作为旁注：你用表格的名称为几乎所有字段的名称添加前缀（因为我认为字段名称中有重复）;为什么你总是那样做？它会使查询更容易理解; - ）
答案 2 :(得分：1)
只要WHERE子句中的列是索引，您就可以了。我会生成一组重要的测试数据并运行一些基准测试。
另外，更重要的是，熟悉MySQL's EXPLAIN语法。它将帮助您确定查询中实际使用的行数（以及其他内容），并且是优化查询和表索引的绝佳工具。
答案 3 :(得分：0)
你应该找出导致它变慢的原因。
您的数据库是否适合内存？如果没有，获得更多 - 不，真的。无论你怎么看，光盘都很慢。
如果您的查询绝对无法使用光盘（假设您的数据库对于合理的内存来说只是FAR太大，100G +说），那么您应该尝试最小化所需的IO操作数量。
实际上这意味着一定程度的非规范化（你真的需要一个连接吗？你能不能在外部参照表上存储（副本）所有需要的字段吗？），并明智地使用覆盖索引。
在InnoDB中（我假设您在这里使用Innodb），主键是群集的。这意味着使用主键的查询比其他索引执行的IO更少（因为索引与数据存储在同一页面中），因为它们不需要为每一行执行可能单独的IO，这通常是二级索引需要。
基本原则是：
如果成功，您可以做任何正常的QA程序（例如回归测试等）来释放变更。
在某些情况下，更改将需要进行重大数据迁移，因此需要部署（例如，您需要更改10Tb数据表的架构）。