我有一个网站，每年这个时候都会有很多流量（每天大约50，000用户）。流量每年都在上升，我服务器上的所有网站都开始崩溃，显然是因为未优化的MySQL查询。
我在一个缓慢的日志查询中发现的最严重的违规者是下面这个。这个特定的表有2，655，197行。
这会被归类为一个小问题，大问题还是一个可怕的/立即解决的问题？
我没有“索引”的经验，但似乎在做了一些谷歌搜索后，我应该为这个查询创建一个索引。这会有很大帮助吗？如果是这样，如果有人可以推荐任何解释如何创建索引的网站/视频，请分享。
计数：798时间= 5.75秒（4589秒）锁定= 0.24秒（189秒）发送=0.9（739），检查=2592353.9（2068698439），影响=0.0（0），撤回@localhost SELECT * 从表中唯一的_id= 'S' LIMIT 1
2条答案
按热度按时间wkftcu5l1#
添加
INDEX(unique_id)后，简单查询的时间将从4589秒下降到0.01秒。这是否足以激励学习索引？
5万用户/天是1/秒--不是很忙碌。200万行中等大小。但由于缺乏索引，他们表现得很大。
如果
unique_id是“unique”，则使用UNIQUE或PRIMARY KEY而不是简单的INDEX。此外，如果它是唯一的，那么LIMIT 1是不必要的。nhjlsmyf2#
这会被归类为一个小问题，大问题还是一个可怕的/立即解决的问题？
这不是任何人都能替你回答的您需要多少查询才能以最佳方式运行？我们并不比你们更清楚。
我做了一个演讲，帮助了很多人：How to Design Indexes, Really这里有一段视频：https://www.youtube.com/watch?v=ELR7-RdU9XU这是从2012年开始的，但原则是相当万年青的。
想想我在演讲中使用的电话簿类比：电话簿分类不是很好吗？它使您可以更快地查找条目。
快多少？
计算机科学家将性能描述为相对于数据集的大小，执行任务（如搜索数据集）需要多少步骤。
如果电话簿没有排序，则步骤数与数据集的大小成正比。如果书中有N个条目，那么可能需要进行N次查找才能找到您要查找的条目（它总是在您查找的最后一个位置，对吗？）.
但是，由于电话簿是排序的，搜索可以从中间开始，并查看该位置的条目是否大于或小于您要查找的条目。所以你知道你想要的是在上半场还是下半场。然后你走到一半的中点，再试一次。每次查找都会再次将搜索减少一半。这就是所谓的“二进制细分”。
而不是采取最多N个步骤来搜索N个条目的数据集，二进制细分需要log 2N个步骤。这是一个游戏规则改变者，而且数据集越大，它的优势就越大。
所以，如果你想优化你的查询，并在数据集增长时保持良好的性能，索引是一件需要注意的重要事情（它们似乎总是在增长，不是吗？）.