在我的网站中，主页（用户大部分时间都在其中）有大约 140 个查询（其中 70 个来自django-avatar模块——我必须看看有一天我是否能找到替代方案）。但是它需要 5 秒才能加载（指标来自django-toolbar）。
我可以将查询数量增加到 170，并将加载时间减少到 2.5 秒（！）。
为此，我必须通过迭代较小的查询来简化使用annotate()和创建字典的复杂查询。我注意到虽然查询数量增加了，但 django 更喜欢它，因为我通过删除注释来减轻复杂查询的负载。
我应该怎么办？
PS：除了MySql我也用memcached
首先，django-debug-toolbar 提供了一个主观的性能衡量标准，用于快速检查自己。如果您发现您的查询激增或请求突然比以前花费更长的时间，那么这让您知道您需要深入研究并查看是否可以对其进行一些优化。但是，它不适合泛化的“我的网站响应速度如何”类型测试；django-debug-toolbar，它本身引入了一些低效率的地方来给你它所做的数据。禁用工具栏后，您的代码将不可避免地比启用时执行得更好。如果您真的想衡量您的网站，您需要使用分析后端在最佳条件下对您的网站进行猛烈攻击，并为您提供有关瓶颈发生位置的统计信息。
也就是说，您获得的时间统计信息不仅取决于查询；它们还依赖于文件 I/O、模板渲染等。如果您在开发中使用 memcached，那么请求之间不可避免地会发生一些缓存，即使它只是被缓存的模板。不必重新解析模板并创建响应对象会占用大量时间。因此，看起来 170 次查询似乎更快，但这可能只是因为已经有一些缓存。如果关闭缓存，时间可能会显着增加。如果您正在开发和优化查询负载，您应该通过将缓存设置为DummyCache.
最后，在开发中，传输请求的实际时间不是问题，因为它是本地到本地的，这几乎是瞬时的。在现实世界的场景中，客户端向您的服务器发送请求需要花费数百毫秒的时间。如果您的数据库服务器与您的 Web 服务器不在同一台服务器上，则从 Web 应用程序到数据库来回发送请求需要时间，最后将响应发送回客户端需要时间。实际传输时间通常最终会比实际查询时间造成更多的瓶颈，因此通常更少、更复杂的查询总是比更多、更小的查询更可取。
基本上，在开发中测试这些东西的变量太多了。像 django-debug-toolbar 这样的东西是一个很好的指南，但它并不全面，也不是万无一失的。将您的代码放在类似生产的机器上并对其进行猛烈攻击——这是唯一确定的方法。