# 转载自：https://www.cnblogs.com/miaojiyao/articles/5217757.html
下面讨论一下用peewee的些许提高性能的方法。
避免N+1查询
N+1查询指的是当应用提交一次查询获取结果，然后在取得结果数据集的每一行时，应用至少再次查询一次（也可以看做是嵌套循环）。
大多数情况下，n 查询可以通过使用SQL join或子查询来避免。数据库本身可能做了嵌套循环，但是它比在你的应用代码本身里做这些n查询更高效，后者通常会导致与数据库再次潜在通讯，没有利用数据库本身关联和执行子查询时会进行切片等优化工作。
Peewee提供了几种API去减轻N+1查询的行为。再看看贯串我们这篇文档的模型，User和Tweet，这部分我们重点讲一下一些N+1场景，说明peewee怎么帮助我们避免N+1查询。
在一些场景里，N+1查询不会明显表现为显著地或可测量的性能瓶颈点。它也由你要查询的数据，使用的数据库本身，以及执行查询获取结果的潜在因素。优化前后可以测试性能，确保和你预测的变化相同。
raw执行时也会出现这种情况：
### all_res = Results.raw(sql, "2012", "2013","2014", "2015")
列出最近的tweets
tweets时间轴显示最近用户的tweets。除了tweet的内容，还要显示tweet作者的用户名。N+1场景描述为：
获取最近的10条tweets
每个tweet，查询作者信息（10次查询）
通过用join选择两个表，peewee使得在一次查询里完成任务：
复制代码
query = (Tweet
.select(Tweet, User) # Note that we are selecting both models.
.join(User) # Use an INNER join because every tweet has an author.
.order_by(Tweet.id.desc()) # Get the most recent tweets.
.limit(10))
for tweet in query:
print tweet.user.username, '-', tweet.message
复制代码
没有用join时，得到tweet.user.username会触发一次查询去解析外键tweet.user从而得到相关联的user。
由于我们在User上关联并选择，peewee自动为我们解析外键。
列出所有用户和他们的tweets
你想要显示若干用户和他们所有的tweets的页面。N+1场景为：
取得些许用户。
每个用户取到他们的tweets。
虽然和上个例子相似，但是重要区别是：我们选择tweets时，每个tweet只有一个关联的用户，所以可以直接赋值到外键，
反过来不对，因为一个用户可有任意数量tweets或者没有。
Peewee提供两两种途径去避免O(n)查询：
1.首先取到用户，然后取到关联这些用户的所有tweets。一旦peewee取到tweets，将它们与合适的用户匹配。
这种方法通常很快，但是会在所选择的每个表上执行一次查询。
2.在一个查询里得到用户和tweets。用户数据将复制，所以peewee将在列举结果集时减少重复和聚合tweets。
这种方法导致有许多数据需要传输，并且要有许多python逻辑去减少行重复。
每种方案根据查询数据的大小和结构都会可能比另一种更好。
使用prefetch
peewee使用子查询可以预获取数据。这种方法需要prefetch特殊API使用。Pre-fetch，像其名字本身，
用子查询去急切加载给定用户的相应的tweets。意味着我们用O(k)查询K张表而不是O(n)查询n行纪录。
下面演示我们如何得到若干用户和他们最近一周的tweets：
复制代码
week_ago = datetime.date.today() - datetime.timedelta(days=7)
users = User.select()
tweets = (Tweet
.select()
.where(
(Tweet.is_published == True) &
(Tweet.created_date >= week_ago)))
# This will perform two queries.
users_with_tweets = prefetch(users, tweets)
for user in users_with_tweets:
print user.username
for tweet in user.tweets_prefetch:
print ' ', tweet.message
复制代码
注意User 查询和Tweet查询都没有JOIN子句，当我们使用prefetch时不必指名join
prefetch可以用于任意数量的表。可以查看API文档看其他例子。
用prefetch时应考虑的事情：
预查询的模型必须存在外键
通常它比aggregate_rows方法更高效
因为数据没有重复的所以传输的数据更少
因为不用减重复所以python逻辑更少
当你想要在最外的查询里使用LIMIT没问题，但是可能正确的实现限制子查询的返回结果大小有些困难。
使用aggregate_rows
aggregeate_rows一次在内存中减少重复，选择所有的数据。它和prefetch都可以完成任意复杂的查询。
使用这个特性需要当创建查询时用到特殊的标志aggregate_rows。它告诉peewee减少那些根据JOIN的结构可能会重复的行。
因为在减少重复聚合数据时有许多计算，所以可能使用aggregate_rows可能在一些查询中会比用prefetch性能低，即使面对的是
O(n)简单的 查询时，所以你不确定使用哪种方法时测试检查你的代码。
复制代码
query = (User
.select(User, Tweet) # As in the previous example, we select both tables.
.join(Tweet, JOIN.LEFT_OUTER)
.order_by(User.username) # We need to specify an ordering here.
.aggregate_rows()) # Tell peewee to de-dupe and aggregate results.
for user in query:
print user.username
for tweet in user.tweets:
print ' ', tweet.message
复制代码
复制代码
query = (User
.select(User, Tweet) # As in the previous example, we select both tables.
.join(Tweet, JOIN.LEFT_OUTER)
.order_by(User.username) # We need to specify an ordering here.
.aggregate_rows()) # Tell peewee to de-dupe and aggregate results.
for user in query:
print user.username
for tweet in user.tweets:
print ' ', tweet.message