@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 支持。

说几个 django orm 坑爹的地方。
1. 有些 group by 无法用 orm 实现。
2. 有些连表查询，用 djanog orm 写出来的 sql 是子查询。
3. 速度感人，一个两万条记录的查询，用时三秒。 sql<100ms

1 和 2sqlalchemy 有很好的解决方案。
3 我不确定 sqlalchemy 是更快还是更慢。