@Panmax 我也不会,只是又一次参加 pycon 年会的时候 达达的 rest api 负责人在做分享的时候讲到过.
你可以搜搜 2016 python 上海 网上能找到视频和 ppt 以及 github.

@vicalloy
部分认同你的观点:
import MySQLdb

# Open database connection
db = MySQLdb.connect(<略>)

import time
starttime = time.time()
sql0 = "select * from <略>"
cursor = db.cursor(MySQLdb.cursors.DictCursor)
cursor.execute(sql0)
custom_html_data = cursor.fetchall()
print time.time() - starttime
cursor.close()

我这边输出的结果在 1.6 ~ 1.7 秒之间.
吃掉的那 1.3 秒就是 orm 的损耗.

这里有一个不严谨的地方就是,我没有测试当前时间点 django orm 的效率.

最后还有一个问题,如果这种时间的损耗都可以忽略的话,大家所说的 ORM 影响效率的点在哪里呢?

@wangfengmadking 要么是因为你水平到位了.要么是因为项目刚开始没多长时间.等将来业务变动自己撸的就扛不住了.
我为什么这么说?
以为我这么干过.(逃.

@ManjusakaL 多库还行啊...用 db_router...

@vicalloy
对,是我没说清楚.
我就是这个意思
>>> qs = <model>.objects.all().values()
>>> list(qs)
超过 1s 是很正常的，因为你要把所有数据一次性取出来。你可以用调试工具看一下，生成的 SQL 就是`select * from <table name>`，查询速度本身是非常快的，但单 2w 条数据，别的不说，单网络传输都要费不少时间。

你的意思是说,(超过 1s 是很正常的)这一秒钟时间并不是 orm 引起的?

3366.68

@vicalloy
@chaleaoch
1. Django 的查询可以嵌入 SQL ，也可以把自己手写的 SQL 绑定到对象上。
不知道你遇到的具体情况是怎么样的，不过在我看来第一条应当是可以实现。
====
django orm 是有 extra 的写法，不过我把这种写法归于直接 sql 一类。（也是我个人观点）
2. 有些表连接写出来是子查询，这个需要结合具体案例，不是很确定是否是写法问题。
3. 2w 条数据查询用时 3 秒，这个非常不正常，需要结合具体代码进行分析。从我主观角度看是代码写的有问题。
====
非常简单 <model>.objects.all().values() 三秒
<model>.objects.filter(<这里假设出 10000 条数据>).values() 一秒
直接用客户端查询 select * from <table name> <100ms

我的理解问题出在 django orm 在生成映射结构的时候多处使用 for 循环导致的这个问题。

@XhstormR 该用 orm 还是得用 orm 毕竟方便。一直都用 sql 有两个问题，一个是预防 sql 注入，另一个是代码不易读。

还有 django orm 如法实现分表。至少原生不支持。只能分区。
sqlalchemy 支持。