django的文檔看了非常多。也用了不少，有的時候感覺性能非常不好，知道非常多地方是惰性查詢。可是對于復雜的邏輯。僅僅是表面上發現執行非常慢，機器資源消耗非常多。卻不知道orm究竟是什么來轉化成sql和查詢的。

之前django1.3版本號在google上找到了寫方法，通過配置settings就能看到每次查詢的原始sql，如今用1.6的版本號也懶得去找了，反正在自己機子上看法。僅僅是些簡單的監視直接改下源代碼就好了。

?

于是翻了下django的源代碼。基本的sql運行語句在

D:\devsofts\python2.7\Lib\site-packages\django\db\models\sql\compiler.py 文件里

這里的D:\devsofts\python2.7是python的安裝文件夾，每一個人安裝的可能不一樣。自己找一下即可了，后面的文件夾基本是同樣的。

在這個文件里查找execute_sql 方法，在758行左右。

在方法中運行sql之前增加一個print。就能在控制臺看到sql運行的情況了。

這里用的msyql數據庫

print "connexesql ->%s"%sqlcursor = self.connection.cursor()cursor.execute(sql, params)
效果：

connexesql ->SELECT `mngm_area`.`id` FROM `mngm_area` WHERE `mngm_area`.`parentid` = %s connexesql ->SELECT `mngm_device`.`mac` FROM `mngm_device` WHERE `mngm_device`.`area_id` IN (%s, %s, %s, %s, %s) ORDER BY `mngm_device`.`hostname` ASC connexesql ->SELECT `ad_material`.`id`, `ad_material`.`user_id`, `ad_material`.`name`, `ad_material`.`category`, `ad_material`.`anchor`, `ad_material`.`target`, `ad_material`.`note`, `ad_material`.`status`, `ad_material`.`addtime`, `ad_material`.`lastmodified` FROM `ad_material` WHERE `ad_material`.`id` = %s {connexesql ->SELECT `mngm_area`.`id` FROM `mngm_area` WHERE `mngm_area`.`parentid` = %s connexesql ->SELECT `mngm_device`.`mac` FROM `mngm_device` WHERE `mngm_device`.`area_id` IN (%s, %s, %s, %s, %s) ORDER BY `mngm_device`.`hostname` ASC connexesql ->SELECT `ad_material`.`id`, `ad_material`.`user_id`, `ad_material`.`name`, `ad_material`.`category`, `ad_material`.`anchor`, `ad_material`.`target`, `ad_material`.`note`, `ad_material`.`status`, `ad_material`.`addtime`, `ad_material`.`lastmodified` FROM `ad_material` WHERE `ad_material`.`id` = %s {

這樣就比較easy發現程序不好的寫法，及時糾正了。?

興許：

這樣改動之后打印的日志僅僅有查詢語句，插入更新刪除語句的debug，在讀源代碼之后分享出來。

本文出自?“orangleliu筆記本”?博客。請務必保留此出處http://blog.csdn.net/orangleliu/article/details/40115471

轉載于:https://www.cnblogs.com/gccbuaa/p/6803583.html

總結

以上是生活随笔為你收集整理的[Django] 查看orm自己主动运行的原始查询sql的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。