Django's database layer provides various ways to help developers get the most\nout of their databases. This document gathers together links to the relevant\ndocumentation, and adds various tips, organized under a number of headings that\noutline the steps to take when attempting to optimize your database usage.
\nAs general programming practice, this goes without saying. Find out what\nqueries you are doing and what they are costing you. You may also want to use an external project like\ndjango-debug-toolbar, or a tool that monitors your database directly.
\nRemember that you may be optimizing for speed or memory or both, depending on\nyour requirements. Sometimes optimizing for one will be detrimental to the\nother, but sometimes they will help each other. Also, work that is done by the\ndatabase process might not have the same cost (to you) as the same amount of\nwork done in your Python process. It is up to you to decide what your\npriorities are, where the balance must lie, and profile all of these as required\nsince this will depend on your application and server.
\nDengan apapun yang mengikuti, ingat untuk menggambarkan raut muka setelah setiap perubahan untuk memastikan bahwa perubahan adalah menguntungkan, dan keuntungan cukup besar diberikan menurunkan dalam kesiapan kode anda. Semua dari saran-saran dibawah datang dengan surat keberatan yang dalam keadaan anda prinsip umum mungkin tidak berlaku, atau mungkin bahkan dibalikkan.
\n...termasuk:
\nIndexes. This is a number one priority, after you have determined from\nprofiling what indexes should be added. Use\nField.db_index or\nMeta.index_together to add\nthese from Django. Consider adding indexes to fields that you frequently\nquery using filter(),\nexclude(),\norder_by(), etc. as indexes may help\nto speed up lookups. Note that determining the best indexes is a complex\ndatabase-dependent topic that will depend on your particular application.\nThe overhead of maintaining an index may outweigh any gains in query speed.
Penggunaan sesuai dari jenis-jenis bidang
We will assume you have done the obvious things above. The rest of this document\nfocuses on how to use Django in such a way that you are not doing unnecessary\nwork. This document also does not address other optimization techniques that\napply to all expensive operations, such as general purpose caching.
\nQuerySetLink to this heading#Memahami QuerySets adalah vital untuk mendapatkan penampilan baik dengan kode sederhana. Khususnya:
\nQuerySetLink to this heading#Untuk menghindari masalah penampilan, sangatlah penting memahami:
\nitu QuerySets malas.
ketika mereka dinilai.
bagaimana data ditahan dalam memori.
As well as caching of the whole QuerySet, there is caching of the result of\nattributes on ORM objects. In general, attributes that are not callable will be\ncached. For example, assuming the example Weblog models:
>>> entry = Entry.objects.get(id=1)\n>>> entry.blog # Blog object is retrieved at this point\n>>> entry.blog # cached version, no DB access\nTetapi secara umum, atribut callable menyebabkan pencarian DB setiap waktu:
\n>>> entry = Entry.objects.get(id=1)\n>>> entry.authors.all() # query performed\n>>> entry.authors.all() # query performed again\nHati-hati ketika membaca kode cetakan - sistem cetakan tidak mengizinkan penggunaan tanda kurun, tetapi akan memanggil callable secara otomatis, memnyembunyikan perbedaan diatas.
\nBe careful with your own custom properties - it is up to you to implement\ncaching when required, for example using the\ncached_property decorator.
withLink to this heading#Untuk menggunakan perilaku cache dari QuerySet, anda mungkin butuh menggunakan etiket cetakan with.
iterator()Link to this heading#Ketika anda mempunyai banyak obyek, perilaku cache dari QuerySet dapat menyebabkan sejumlah besar memori digunakan. Dalam kasus ini, iterator() mungkin membantu.
Sebagai contoh:
\nPada paling tingkat dasar, gunakan filter and exclude melakukan penyaringan di basisdata
Gunakan F expressions untukmenyaring berdasarkan pada bidang-bidang lain dalam model sama.
Jika ini tidak cukup membangkitkan SQL yang anda butuhkan:
\nRawSQLLink to this heading#A less portable but more powerful method is the\nRawSQL expression, which allows some SQL\nto be explicitly added to the query. If that still isn't powerful enough:
Write your own custom SQL to retrieve data or populate models. Use django.db.connection.queries to find out what Django\nis writing for you and start from there.
There are two reasons to use a column with\nunique or\ndb_index when using\nget() to retrieve individual objects.\nFirst, the query will be quicker because of the underlying database index.\nAlso, the query could run much slower if multiple objects match the lookup;\nhaving a unique constraint on the column guarantees this will never happen.
Jadi menggunakan example Weblog models:
\n>>> entry = Entry.objects.get(id=10)\nakan lebih cepat daripada:
\n>>> entry = Entry.objects.get(headline="News Item Title")\nkarena id diindeks oleh basisdata dan dijamin menjadi unik.
Melakukan berikut berpotensi sangat lambat:
\n>>> entry = Entry.objects.get(headline__startswith="News")\nFirst of all, headline is not indexed, which will make the underlying\ndatabase fetch slower.
Second, the lookup doesn't guarantee that only one object will be returned.\nIf the query matches more than one object, it will retrieve and transfer all of\nthem from the database. This penalty could be substantial if hundreds or\nthousands of records are returned. The penalty will be compounded if the\ndatabase lives on a separate server, where network overhead and latency also\nplay a factor.
\nHitting the database multiple times for different parts of a single 'set' of\ndata that you will need all parts of is, in general, less efficient than\nretrieving it all in one query. This is particularly important if you have a\nquery that is executed in a loop, and could therefore end up doing many database\nqueries, when only one was needed. So:
\n\nQuerySet.values() dan values_list()Link to this heading#When you just want a dict or list of values, and don't need ORM model\nobjects, make appropriate usage of\nvalues().\nThese can be useful for replacing model objects in template code - as long as\nthe dicts you supply have the same attributes as those used in the template,\nyou are fine.
QuerySet.defer() dan only()Link to this heading#Use defer() and\nonly() if there are database columns\nyou know that you won't need (or won't need in most cases) to avoid loading\nthem. Note that if you do use them, the ORM will have to go and get them in\na separate query, making this a pessimization if you use it inappropriately.
Also, be aware that there is some (small extra) overhead incurred inside\nDjango when constructing a model with deferred fields. Don't be too aggressive\nin deferring fields without profiling as the database has to read most of the\nnon-text, non-VARCHAR data from the disk for a single row in the results, even\nif it ends up only using a few columns. The defer() and only() methods\nare most useful when you can avoid loading a lot of text data or for fields\nthat might take a lot of processing to convert back to Python. As always,\nprofile first, then optimize.
QuerySet.count()Link to this heading#..jika anda hanya ingin menghitung, daripada melakukan len(queryset).
QuerySet.exists()Link to this heading#...if you only want to find out if at least one result exists, rather than if\nqueryset.
Tetapi:
\ncount() dan exists()Link to this heading#If you are going to need other data from the QuerySet, just evaluate it.
\nFor example, assuming an Email model that has a body attribute and a\nmany-to-many relation to User, the following template code is optimal:
{% if display_inbox %}\n {% with emails=user.emails.all %}\n {% if emails %}\n <p>You have {{ emails|length }} email(s)</p>\n {% for email in emails %}\n <p>{{ email.body }}</p>\n {% endfor %}\n {% else %}\n <p>No messages today.</p>\n {% endif %}\n {% endwith %}\n{% endif %}\nDIa optimal karena:
\nSince QuerySets are lazy, this does no database queries if 'display_inbox'\nis False.
Use of with means that we store user.emails.all in a variable\nfor later use, allowing its cache to be re-used.
The line {% if emails %} causes QuerySet.__bool__() to be called,\nwhich causes the user.emails.all() query to be run on the database, and\nat the least the first line to be turned into an ORM object. If there aren't\nany results, it will return False, otherwise True.
The use of {{ emails|length }} calls QuerySet.__len__(), filling\nout the rest of the cache without doing another query.
The for loop iterates over the already filled cache.
In total, this code does either one or zero database queries. The only\ndeliberate optimization performed is the use of the with tag. Using\nQuerySet.exists() or QuerySet.count() at any point would cause\nadditional queries.
QuerySet.update() dan delete()Link to this heading#Rather than retrieve a load of objects, set some values, and save them\nindividual, use a bulk SQL UPDATE statement, via QuerySet.update(). Similarly, do bulk deletes where possible.
\nNote, however, that these bulk update methods cannot call the save() or\ndelete() methods of individual instances, which means that any custom\nbehavior you have added for these methods will not be executed, including\nanything driven from the normal database object signals.
If you only need a foreign key value, use the foreign key value that is already on\nthe object you've got, rather than getting the whole related object and taking\nits primary key. i.e. do:
\nentry.blog_id\ndari pada:
\nentry.blog.id\nPengurutan tidak bebas; setiap bidang yang diurutkan adalah sebuah operai basisdata harus dilakukan. Jika sebuah model awal mengurutkan (Meta.ordering) dan anda tidak membutuhkannya, pindahkan dia pada QuerySet dengan memanggil order_by() dengan tidak ada parameter.
Menambahkan indeks ke basisdata anda mungkin membantu meningkatkan penampilan pengurutan.
\nWhen creating objects, where possible, use the\nbulk_create() method to reduce the\nnumber of SQL queries. For example:
Entry.objects.bulk_create([\n Entry(headline='This is a test'),\n Entry(headline='This is only a test'),\n])\n...is preferable to:
\nEntry.objects.create(headline='This is a test')\nEntry.objects.create(headline='This is only a test')\nCatat bahwa ada angka dari caveats to this method, jadi pastikan dia sesuai untuk kasus digunakan anda.
Ini juga berlaku pada ManyToManyFields, demikian:
my_band.members.add(me, my_friend)\n...is preferable to:
\nmy_band.members.add(me)\nmy_band.members.add(my_friend)\n...where Bands and Artists have a many-to-many relationship.