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` ASCconnexesql ->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` ASCconnexesql ->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，在读源代码之后分享出来。

本文出自 博客。请务必保留此出处