如何優化Django中ORM的性能問題

這篇文章主要介紹如何優化Django中ORM的性能問題，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

Django是個好工具，使用的很廣泛。 在應用比較小的時候，會覺得它很快，但是隨著應用復雜和壯大，就顯得沒那么高效了。當你了解所用的Web框架一些內部機制之后，才能寫成比較高效的代碼。

怎么查問題

Web系統是個挺復雜的玩意，有時候有點無從下手哈。可以采用 自底向上 的順序，從數據存儲一直到數據展現，按照這個順序一點一點查找性能問題。

數據庫 (缺少索引/數據模型)

數據存儲接口 (ORM/低效的查詢)

展現/數據使用 (Views/報表等)

Web應用的大部分問題都會跟 數據庫 扯上關系。除非你正在處理大量的數據并知道你在做什么，否則不要去考慮用Big-O表示法思考View的問題。 數據庫調用的開銷將使循環和模板渲染的開銷相形見絀。 不首先解決數據庫使用中的問題，您就不能繼續解決其他問題。

Django的文檔中有那么一節，詳細的描述了DB部分優化, ORM 從一開始就應該寫的比較高效一些（畢竟有那么多最佳實踐)

優化，很多時候意味著代碼可能變得不太清晰。當你遇到選擇清晰的代碼，還是犧牲清晰代碼來獲取性能上的一點點提高的時候，請優先考慮要代碼的清晰整潔

工具

解決問題的第一步是找到問題，面對 ORM，有時間事情可以做。

理解 django.db.connection, 這個對象可以用來記錄當前查詢花費的時間（知道了SQL語句查詢的時間，當然就知道那里慢了)

>>> 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'}]

但是使用起來好像不是很方面。

在shell命令行的環境下，可以使用 django-exension's shell_plus 命令并打開 --print-sql 選項。

python manage.py shell_plus --print-sql

>>> Author.objects.all()
SELECT "library_author"."id", "library_author"."name" FROM "library_author" LIMIT 21
Execution time: 0.001393s [Database: default]
<QuerySet [<Author: Author object>]>

還有個更方面的方式, 使用 Django-debug-toolbar 工具，就可以在web端查看SQL查詢的詳細統計結果，其實它功能遠不止這個。

總結下3個方式

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

django-extensions 可以在shell環境下方面調試

django-debug-toolbar 可以在web端直接看到debug結果

案例

下面是用個具體的例子來說明一些問題

model 定義

很經典的外鍵關系, Author 和 Book 一對多的關系

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
 )

多余的查詢

當你檢查一個book是否有author或者想獲取這本書的author 的id的時候，可能更傾向于直接使用 author 對象。

if book.author:
 do_stuff()
# Or
do_stuff_with_author_id(book.author.id)

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

if book.author_id:
 do_stuff()

do_stuff_with_author_id(book.author_id)

count 和 exists

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

# Don't waste a query if you are using the queryset
books = Book.objects.filter(..)
if books:
 do_stuff_with_books(books)

# If you aren't using the queryset use exist
books = Book.objects.filter(..)
if books.exists():
 do_some_stuff()

# But never
if Book.objects.filter(..):
 do_some_stuff()

下面是關于count 和 len 的例子

# Don't waste a query if you are using the queryset
books = Book.objects.filter(..)
if len(books) > 5:
 do_stuff_with_books(books)

# If you aren't using the queryset use count
books = Book.objects.filter(..)
if books.count() > 5:
 do_some_stuff()

# But never
if len(Book.objects.filter(..)) > 5:
 do_some_stuff()

只獲取需要的數據

默認情況下，ORM 查詢的時候會把數據庫記錄對應的所有列取出來，然后轉換成 Python對象，這無疑是個很大的浪費嘛(有時候只想要一兩個列的，寶寶心理��)。當你只需要某些列的時候可以使用 values 或者 values_list, 它們不是把數據轉換成復雜的 python 對象，而是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']>

處理很多記錄

當你獲得一個 queryset 的時候，Django會緩存這些數據。 如果你需要對查詢結果進行好幾次循環，這種緩存是有意義的，但是對于 queryset 只循環一次的情況，緩存就沒什么意義了。

for book in Books.objects.all():

do_stuff(book)

上面的查詢，django會把books所有的數據歐載入內存，然后進行一次循環。其實我們更想要保持這個數據庫 connection, 每次循環的取出一條book數據，然后調用 do_stuff。iterator 就是我們的救星。

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

do_stuff(book)

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

特別是跟 values，values_list 結合在一起的時候，能盡可能少的使用內存。在需要對表中的每一行進行修改的遷移期間，使用iterator也非常方便。 不能因為遷移不是面向客戶的就可以降低對效率的要求。 長時間運行的遷移可能意味著事務鎖定或停機。

關聯查詢問題

Django ORM的API使得我們使用關系型數據庫的時候就像使用面向對象的 Python 語言那樣自然。

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

上面的代碼相當的清晰和好理解。Django 使用 lazy loading（懶加載)的方式，只有用到了 author 對象時候才會加載。這樣做有好處，但是會造成爆炸��式的查詢。

>>> 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 author
authors = Author.objects.all()
for author in authors:
 do_stuff_with_books(author.name, author.books.all())

Django 意識到了這種問題，并提供 select_related 和 prefetch_related 來解決。

# This block is 1 query
# The authors of all the books are pre-fetched in one query
book = 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 query
authors = 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 的時候要謹慎。

prefetch_related 有個坑，當你像要在related查詢中使用 filter時候author.books.filter(..), 之前在 prefetch_related 中的緩存就無法使用了，相對于 author.books.all() 來說的。有些事情會變的復雜了，你最好2次查詢來解決這種問題，上級對象和它的子對象各一次，然后在進行聚合。 如果 prefetch太復雜了，這時候就要在代碼的整潔清晰和應用性能之間做一個取舍了。

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

select_related 不好用的時候

某些情況下 select_related 會變得不好使。 看看下面的例子，id() 方法用來判斷 Python 對象實例的唯一性，如果 id結果相同，表示同一個 對象實例。

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

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

select_related 為查詢的每個row，創建了一個新對象，耗費了大量的內存（上面的結果中，對于數據庫中的同一個author對象創建了不同的python對象）。SQL一會為每行返回重復的信息。 如果你進行一個查詢，其中select_related 查詢的所有值都是相同的，你就需要使用別的東西。 使用相關查詢或翻轉(flip)查詢并使用prefetch_related。

使用 author.books.all() 結合對象相關查詢，Django會為每個已經查詢的book記錄保存相同的author對象

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

使用 select_related 還有一個隱含問題，當你修改一個author 對象的時候，如果其他book也關聯到這個author，這個改變不會傳播過去，因為它們在python內存中是不同的對象實例。如果使用 對象相關查詢，修改就能傳播。

簡單不一定更好

Django使得關系查詢太容易了，這也帶來了一些副作用。當你將一個對象傳入函數中，接著使用了 relationship (對象關系), 實際上無法知道這種關聯的數據是否已經從數據庫取出來。

def author_name_length(book):
 return len(book.author.name)

def process_author_books(author):
 for book in author.books.all():
 do_stuff(book)

上面的函數中 author_name_length 和 process_author_books, 誰將會查詢？ 我們無從所知。 Django ORM中的關聯查詢非常好用，我們自然希望使用這種方式。在一個循環中，如果不使用 select_related 或者 prefetch_related，可能會導致幾百個查詢。Django只會知道查詢，而不會多看一眼。這種情況只能依靠SQL的logs，還有函數調用來監控，然后確定是否進行預查詢。

我們可以重寫函數，參數的傳遞采用扁平的數據結構，類似 namedtuple, 而不是 model，但這種別考慮這種方案。

怎么修復?

我們已經知道了這個問題，那么怎樣拓展Django能讓我們更明確的知道資源的消耗呢。很多數據庫的封裝已經通過不同的方式解決了這個問題。在Ecto中，Elixir的數據庫封裝，一個沒有獲取數據的關系調用會返回 Ecto.Association.NotLoaded 提示，而不是默默的查詢。

我們可以想象Django的某個版本使用 pythonic 的方式實現了這種功能。

>>> book.author.name
Traceback (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"

ORM 的使用并沒有固定的標準。對于小的應用來說，優化可能并沒有多么明顯的效果。應該以代碼清晰為優先，然后在考慮優化的事情。程序增長過程中，對 ORM 的使用一定要保持好的習慣。養成對資源消耗敏感的習慣，以后會有很多好處。

優化的方法很多，對于長遠來說了解一些原則更為實用

習慣隔離代碼并記錄產生的查詢

不要在循環中查詢

了解 ORM 是怎么緩存數據的

知道 Django 何時會做查詢

不要以犧牲清晰度為代價過度優化

以上是如何優化Django中ORM的性能問題的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！