189 8069 5689
这篇文章主要为大家展示了“Django代码性能优化与使用Pycharm Profile的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“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表.当我们
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秒。
以上是“Django代码性能优化与使用Pycharm Profile的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联成都网站设计公司行业资讯频道！
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。