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"%sql
        cursor = 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

[Django] 查看orm自己主動運行的原始查詢sql