Django是個(gè)好工具，使用的很廣泛。 在應(yīng)用比較小的時(shí)候，會(huì)覺(jué)得它很快，但是隨著應(yīng)用復(fù)雜和壯大，就顯得沒(méi)那么高效了。當(dāng)你了解所用的Web框架一些內(nèi)部機(jī)制之后，才能寫成比較高效的代碼。

怎么查問(wèn)題

Web系統(tǒng)是個(gè)挺復(fù)雜的玩意，有時(shí)候有點(diǎn)無(wú)從下手哈。可以采用 自底向上 的順序，從數(shù)據(jù)存儲(chǔ)一直到數(shù)據(jù)展現(xiàn)，按照這個(gè)順序一點(diǎn)一點(diǎn)查找性能問(wèn)題。

數(shù)據(jù)庫(kù) (缺少索引/數(shù)據(jù)模型)

數(shù)據(jù)存儲(chǔ)接口 (ORM/低效的查詢)

展現(xiàn)/數(shù)據(jù)使用 (Views/報(bào)表等)

Web應(yīng)用的大部分問(wèn)題都會(huì)跟 數(shù)據(jù)庫(kù) 扯上關(guān)系。除非你正在處理大量的數(shù)據(jù)并知道你在做什么，否則不要去考慮用Big-O表示法思考View的問(wèn)題。 數(shù)據(jù)庫(kù)調(diào)用的開(kāi)銷將使循環(huán)和模板渲染的開(kāi)銷相形見(jiàn)絀。 不首先解決數(shù)據(jù)庫(kù)使用中的問(wèn)題，您就不能繼續(xù)解決其他問(wèn)題。

Django的文檔中有那么一節(jié)，詳細(xì)的描述了DB部分優(yōu)化, ORM 從一開(kāi)始就應(yīng)該寫的比較高效一些（畢竟有那么多最佳實(shí)踐)

優(yōu)化，很多時(shí)候意味著代碼可能變得不太清晰。當(dāng)你遇到選擇清晰的代碼，還是犧牲清晰代碼來(lái)獲取性能上的一點(diǎn)點(diǎn)提高的時(shí)候，請(qǐng)優(yōu)先考慮要代碼的清晰整潔

工具

解決問(wèn)題的第一步是找到問(wèn)題，面對(duì) ORM，有時(shí)間事情可以做。

理解 django.db.connection, 這個(gè)對(duì)象可以用來(lái)記錄當(dāng)前查詢花費(fèi)的時(shí)間（知道了SQL語(yǔ)句查詢的時(shí)間，當(dāng)然就知道那里慢了)

>>> from django.db import connection>>> connection.queries[]>>> Author.objects.all()<QuerySet [<Author: Author object>]>>>> connection.queries[{u’time’: u’0.002’, u’sql’: u’SELECT 'library_author'.'id', 'library_author'.'name' FROM 'library_author' LIMIT 21’}]

但是使用起來(lái)好像不是很方面。

在shell命令行的環(huán)境下，可以使用 django-exension’s shell_plus 命令并打開(kāi) --print-sql 選項(xiàng)。

python manage.py shell_plus --print-sql>>> Author.objects.all()SELECT 'library_author'.'id', 'library_author'.'name' FROM 'library_author' LIMIT 21Execution time: 0.001393s [Database: default]<QuerySet [<Author: Author object>]>

還有個(gè)更方面的方式, 使用 Django-debug-toolbar 工具，就可以在web端查看SQL查詢的詳細(xì)統(tǒng)計(jì)結(jié)果，其實(shí)它功能遠(yuǎn)不止這個(gè)。

總結(jié)下3個(gè)方式

django.db.connection django自身提供，比較底層

django-extensions 可以在shell環(huán)境下方面調(diào)試

django-debug-toolbar 可以在web端直接看到debug結(jié)果

案例

下面是用個(gè)具體的例子來(lái)說(shuō)明一些問(wèn)題

model 定義

很經(jīng)典的外鍵關(guān)系, Author 和 Book 一對(duì)多的關(guān)系

class Author(models.Model): name = models.TextField()class Book(models.Model): title = models.TextField() author = models.ForeignKey( Author, on_delete=models.PROTECT, related_name=’books’, null=True )

多余的查詢

當(dāng)你檢查一個(gè)book是否有author或者想獲取這本書的author 的id的時(shí)候，可能更傾向于直接使用 author 對(duì)象。

if book.author: do_stuff()# Ordo_stuff_with_author_id(book.author.id)

這里 author對(duì)象 其實(shí)并不需要（主要指第一行代碼，其實(shí)只需要author_id)，會(huì)導(dǎo)致一次多余的查詢。 如果后面需要 author對(duì)象，在獲取也不沖突。 比較好的習(xí)慣是，直接使用字段名, 見(jiàn)下面的寫法。

if book.author_id: do_stuff()do_stuff_with_author_id(book.author_id)

count 和 exists

對(duì)于初學(xué)者, 知道什么時(shí)候使用 count 和 exists 還是挺難的。 Django會(huì)緩存查詢結(jié)果, 所以如果后續(xù)的操作會(huì)用到這些查詢出來(lái)的數(shù)據(jù) ，可以使用 Python的內(nèi)置方法(指的是len，if判斷queryset，下面例子)。如果不用查詢出的數(shù)據(jù)，使用queryset提供的方法(count(), exists())

# Don’t waste a query if you are using the querysetbooks = Book.objects.filter(..)if books: do_stuff_with_books(books)# If you aren’t using the queryset use existbooks = Book.objects.filter(..)if books.exists(): do_some_stuff()# But neverif Book.objects.filter(..): do_some_stuff()

下面是關(guān)于count 和 len 的例子

# Don’t waste a query if you are using the querysetbooks = Book.objects.filter(..)if len(books) > 5: do_stuff_with_books(books)# If you aren’t using the queryset use countbooks = Book.objects.filter(..)if books.count() > 5: do_some_stuff()# But neverif len(Book.objects.filter(..)) > 5: do_some_stuff()

只獲取需要的數(shù)據(jù)

默認(rèn)情況下，ORM 查詢的時(shí)候會(huì)把數(shù)據(jù)庫(kù)記錄對(duì)應(yīng)的所有列取出來(lái)，然后轉(zhuǎn)換成 Python對(duì)象，這無(wú)疑是個(gè)很大的浪費(fèi)嘛(有時(shí)候只想要一兩個(gè)列的，寶寶心理��)。當(dāng)你只需要某些列的時(shí)候可以使用 values 或者 values_list, 它們不是把數(shù)據(jù)轉(zhuǎn)換成復(fù)雜的 python 對(duì)象，而是dicts, tuples等。

# Retrieve values as a dictionary>>> Book.objects.values(’title’, ’author__name’)<QuerySet [{’author__name’: u’Nikolai Gogol’, ’title’: u’The Overcoat’}, {’author__name’: u’Leo Tolstoy’, ’title’: u’War and Peace’}]># Retrieve values as a tuple>>> Book.objects.values_list(’title’, ’author__name’)<QuerySet [(u’The Overcoat’, u’Nikolai Gogol’),(u’War and Peace’, u’Leo Tolstoy’)]>>>> Book.objects.values_list(’title’)<QuerySet [(u’The Overcoat’,), (u’War and Peace’,)]># With one value, it is easier to flatten the list>>> Book.objects.values_list(’title’, flat=True)<QuerySet [u’The Overcoat’, u’War and Peace’]>

處理很多記錄

當(dāng)你獲得一個(gè) queryset 的時(shí)候，Django會(huì)緩存這些數(shù)據(jù)。 如果你需要對(duì)查詢結(jié)果進(jìn)行好幾次循環(huán)，這種緩存是有意義的，但是對(duì)于 queryset 只循環(huán)一次的情況，緩存就沒(méi)什么意義了。

for book in Books.objects.all():

do_stuff(book)

上面的查詢，django會(huì)把books所有的數(shù)據(jù)歐載入內(nèi)存，然后進(jìn)行一次循環(huán)。其實(shí)我們更想要保持這個(gè)數(shù)據(jù)庫(kù) connection, 每次循環(huán)的取出一條book數(shù)據(jù)，然后調(diào)用 do_stuff。iterator 就是我們的救星。

for book in Books.objects.all().iterator():

do_stuff(book)

有了 iterator，你就可以編寫線性數(shù)據(jù)表或者CSV流了。就能增量寫入文件或者發(fā)送給用戶。

特別是跟 values，values_list 結(jié)合在一起的時(shí)候，能盡可能少的使用內(nèi)存。在需要對(duì)表中的每一行進(jìn)行修改的遷移期間，使用iterator也非常方便。 不能因?yàn)檫w移不是面向客戶的就可以降低對(duì)效率的要求。 長(zhǎng)時(shí)間運(yùn)行的遷移可能意味著事務(wù)鎖定或停機(jī)。

關(guān)聯(lián)查詢問(wèn)題

Django ORM的API使得我們使用關(guān)系型數(shù)據(jù)庫(kù)的時(shí)候就像使用面向?qū)ο蟮?Python 語(yǔ)言那樣自然。

# Get the Author’s name of a Bookbook = Book.objects.first()book.author.name

上面的代碼相當(dāng)?shù)那逦秃美斫狻jango 使用 lazy loading（懶加載)的方式，只有用到了 author 對(duì)象時(shí)候才會(huì)加載。這樣做有好處，但是會(huì)造成爆炸��式的查詢。

>>> Author.objects.count()20>>> Book.objects.count()100# This block is 101 queries.# 1 for the books and 1 for each author that lazy-loaded books = Book.objects.all()for book in books: do_stuff(book.title, book.author.name)# This block is 20 queries.# 1 for the author and 1 for the books of each authorauthors = Author.objects.all()for author in authors: do_stuff_with_books(author.name, author.books.all())

Django 意識(shí)到了這種問(wèn)題，并提供 select_related 和 prefetch_related 來(lái)解決。

# This block is 1 query# The authors of all the books are pre-fetched in one querybook = Book.objects.selected_related(’author’).all()for book in books: do_stuff(book.title, book.author)# This block is 1 query# The books of all the authors are pre-fetched in one queryauthors = Author.objects.prefetch_related(’books’).all()for author in authors: do_stuff_with_books(author.name, author.books.all())

在Django app中使用 prefetch_related 和 select_related 的時(shí)候要謹(jǐn)慎。

prefetch_related 有個(gè)坑，當(dāng)你像要在related查詢中使用 filter時(shí)候author.books.filter(..), 之前在 prefetch_related 中的緩存就無(wú)法使用了，相對(duì)于 author.books.all() 來(lái)說(shuō)的。有些事情會(huì)變的復(fù)雜了，你最好2次查詢來(lái)解決這種問(wèn)題，上級(jí)對(duì)象和它的子對(duì)象各一次，然后在進(jìn)行聚合。 如果 prefetch太復(fù)雜了，這時(shí)候就要在代碼的整潔清晰和應(yīng)用性能之間做一個(gè)取舍了。

最好是了解下 prefetch_related 和 select_related 的區(qū)別，文檔在這

select_related 不好用的時(shí)候

某些情況下 select_related 會(huì)變得不好使。 看看下面的例子，id() 方法用來(lái)判斷 Python 對(duì)象實(shí)例的唯一性，如果 id結(jié)果相同，表示同一個(gè) 對(duì)象實(shí)例。

>>> [(id(book.author), book.author.pk) for book in Book.objects.select_related(’author’)]

[(4504798608, 1), (4504799824, 1)]

select_related 為查詢的每個(gè)row，創(chuàng)建了一個(gè)新對(duì)象，耗費(fèi)了大量的內(nèi)存（上面的結(jié)果中，對(duì)于數(shù)據(jù)庫(kù)中的同一個(gè)author對(duì)象創(chuàng)建了不同的python對(duì)象）。SQL一會(huì)為每行返回重復(fù)的信息。 如果你進(jìn)行一個(gè)查詢，其中select_related 查詢的所有值都是相同的，你就需要使用別的東西。 使用相關(guān)查詢或翻轉(zhuǎn)(flip)查詢并使用prefetch_related。

使用 author.books.all() 結(jié)合對(duì)象相關(guān)查詢，Django會(huì)為每個(gè)已經(jīng)查詢的book記錄保存相同的author對(duì)象

>> id(author)4504693520>>> [(id(book.author), book.author.pk) for book in author.books.all()][(4504693520, 1), (4504693520, 1)]

使用 select_related 還有一個(gè)隱含問(wèn)題，當(dāng)你修改一個(gè)author 對(duì)象的時(shí)候，如果其他book也關(guān)聯(lián)到這個(gè)author，這個(gè)改變不會(huì)傳播過(guò)去，因?yàn)樗鼈冊(cè)趐ython內(nèi)存中是不同的對(duì)象實(shí)例。如果使用 對(duì)象相關(guān)查詢，修改就能傳播。

簡(jiǎn)單不一定更好

Django使得關(guān)系查詢太容易了，這也帶來(lái)了一些副作用。當(dāng)你將一個(gè)對(duì)象傳入函數(shù)中，接著使用了 relationship (對(duì)象關(guān)系), 實(shí)際上無(wú)法知道這種關(guān)聯(lián)的數(shù)據(jù)是否已經(jīng)從數(shù)據(jù)庫(kù)取出來(lái)。

def author_name_length(book): return len(book.author.name)def process_author_books(author): for book in author.books.all(): do_stuff(book)

上面的函數(shù)中 author_name_length 和 process_author_books, 誰(shuí)將會(huì)查詢？ 我們無(wú)從所知。 Django ORM中的關(guān)聯(lián)查詢非常好用，我們自然希望使用這種方式。在一個(gè)循環(huán)中，如果不使用 select_related 或者 prefetch_related，可能會(huì)導(dǎo)致幾百個(gè)查詢。Django只會(huì)知道查詢，而不會(huì)多看一眼。這種情況只能依靠SQL的logs，還有函數(shù)調(diào)用來(lái)監(jiān)控，然后確定是否進(jìn)行預(yù)查詢。

我們可以重寫函數(shù)，參數(shù)的傳遞采用扁平的數(shù)據(jù)結(jié)構(gòu)，類似 namedtuple, 而不是 model，但這種別考慮這種方案。

怎么修復(fù)?

我們已經(jīng)知道了這個(gè)問(wèn)題，那么怎樣拓展Django能讓我們更明確的知道資源的消耗呢。很多數(shù)據(jù)庫(kù)的封裝已經(jīng)通過(guò)不同的方式解決了這個(gè)問(wèn)題。在Ecto中，Elixir的數(shù)據(jù)庫(kù)封裝，一個(gè)沒(méi)有獲取數(shù)據(jù)的關(guān)系調(diào)用會(huì)返回 Ecto.Association.NotLoaded 提示，而不是默默的查詢。

我們可以想象Django的某個(gè)版本使用 pythonic 的方式實(shí)現(xiàn)了這種功能。

>>> book.author.nameTraceback (most recent call last):File '<console>', line 1, in <module>File '/Users/kyle/orm_test/library/models.py', line 18, in __get__’Use `select_related` or `fetch_{rel}`’.format(rel=self.field.name)RelationNotLoaded: Relation `author` not loaded. Use `select_related` or `fetch_author`# We explicitly fetch the resource>>> book.fetch_author()<Author: Author object>>>> book.author.name'Fyodor Dostoevsky'# Select related works just as well>>> book = Book.objects.select_related(’author’).first()>>> book.author.name'Anton Chekhov'

總結(jié)

ORM 的使用并沒(méi)有固定的標(biāo)準(zhǔn)。對(duì)于小的應(yīng)用來(lái)說(shuō)，優(yōu)化可能并沒(méi)有多么明顯的效果。應(yīng)該以代碼清晰為優(yōu)先，然后在考慮優(yōu)化的事情。程序增長(zhǎng)過(guò)程中，對(duì) ORM 的使用一定要保持好的習(xí)慣。養(yǎng)成對(duì)資源消耗敏感的習(xí)慣，以后會(huì)有很多好處。

優(yōu)化的方法很多，對(duì)于長(zhǎng)遠(yuǎn)來(lái)說(shuō)了解一些原則更為實(shí)用

習(xí)慣隔離代碼并記錄產(chǎn)生的查詢

不要在循環(huán)中查詢

了解 ORM 是怎么緩存數(shù)據(jù)的

知道 Django 何時(shí)會(huì)做查詢

不要以犧牲清晰度為代價(jià)過(guò)度優(yōu)化

以上這篇淺談優(yōu)化Django ORM中的性能問(wèn)題就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持好吧啦網(wǎng)。