前言
pycharm是python的一个商业的集成开发工具，本人感觉做python开发还是很好用的，django是一个很流行的python web开源框架，本文将通过实例代码给大家介绍了关于Django代码性能优化与Pycharm Profile使用的相关内容，分享出来供大家参考学习，下面话不多说了，来一起看看详细的介绍吧
是一段导出数据月报的脚本，原先需要十几秒，优化后只需要1秒多。
Pycharm Profile
优化第一步就是Profile，先看看慢在哪里。Pycharm自带Profile工具，很方便。
拿一张官方图说明一下。
图表说明:
- 给出了函数调用关系。
- 红色->黄绿色->绿色，颜色越深说明耗时越多。
- 右上角的“x数字”代表函数调用次数。
- Own代表该函数本身的耗时，不包括调用子函数；而Total包括调用子函数的耗时。还给出了耗时的百分比。
- 可以右键“jump to source”，跳到对应的源码。
有了Profile，剩下的事情就好办了。
首先，看到了有个工具函数调用了9千多次，这个函数用到了nametupled，花了很多时间，于是把nametupled去掉，节省了好几秒的时间。
开启Django logger并设置DEBUG级别
继续Profile，看到时间主要在ORM查询数据库那里。
这时，开启Django本身的logger，级别调到DEBUG，这样就会打印出查询的SQL语句。
N+1问题
首先意识到的是ORM查询的N+1问题。
比如有个Order表，里面有个外键user_id是关联User表.当我们
|
1
2
|
for order in Order.objects.all(): order.user.id |
的时候，Order.objects.all()只有1条sql语句，获取Order表本身的字段到内存，而不会将关联的外键也获取。
当我们order.user_id的时候，不会触发额外的sql查询，而order.user.id的时候，会额外查询User表。
for循环执行了N次，就额外sql查询了N次。故叫N+1问题。
解决N+1的方法:
- 如果是只用到id字段，则可以直接用user_id代替user.id
- select_related。将相关的表也一同查询。select_related如果不传参数，表示查询所有外键的表。
又节省了几秒的时间。
只查询需要的字段
继续看log，发现sql查询次数是减少了很多，然而sql查询语句很长，看来是把所有字段都查询出来。
然而我很多时候只需要某几个字段而已，这样全查出来就浪费了。
解决方法:
- only()。只查询想要的字段。比如Order.objects.only(‘user_id', ‘pay_date', ‘price')
- annotate()。 可指定虚拟字段，如果外键关联的表只用到小部分字段，可以直接annotate过来。比如将User表的realname字段赋给Order表叫user_realname虚拟字段.这样就不需要order.user.realname查询，只需要order.user_realname来查询，不用select_related把user表全部字段给取出来。Order.objects.annotate(user_realname=F(‘user__realname'))。注意还用到了F()，表示纯数据库层面的操作，不需要拉到python内存进行处理。
An F() object represents the value of a model field or annotated column. It makes it possible to refer to model field values and perform database operations using them without actually having to pull them out of the database into Python memory.
至此，将整段代码的执行时间减少到了1.5秒。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对服务器之家的支持。
原文链接：https://blog.csdn.net/handsomekang/article/details/78944705
