【发布时间】：2013-08-20 19:26:54
【问题描述】：
我正在编写一个脚本来 SELECT 查询数据库并解析约 33,000 条记录。不幸的是，我在cursor.fetchone()/cursor.fetchall() 阶段遇到了问题。
我首先尝试像这样一次遍历游标一条记录：
# Run through every record, extract the kanji, then query for FK and weight
printStatus("Starting weight calculations")
while True:
# Get the next row in the cursor
row = cursor.fetchone()
if row == None:
break
# TODO: Determine if there's any kanji in row[2]
weight = float((row[3] + row[4]))/2
printStatus("Weight: " + str(weight))
根据printStatus 的输出（它会打印出时间戳以及传递给它的任何字符串），脚本需要大约 1 秒来处理每一行。这使我相信每次循环迭代时都会重新运行查询（使用 LIMIT 1 或其他值），因为在 SQLiteStudio [i] 和 [/ i] 返回所有 33,000 行。我计算出，按照这个速度，浏览所有 33,000 条记录大约需要 7 个小时。
我没有坐下来，而是尝试使用 cursor.fetchall()：
results = cursor.fetchall()
# Run through every record, extract the kanji, then query for FK and weight
printStatus("Starting weight calculations")
for row in results:
# TODO: Determine if there's any kanji in row[2]
weight = float((row[3] + row[4]))/2
printStatus("Weight: " + str(weight))
不幸的是，Python 可执行文件在到达cursor.fetchall() 行时锁定在 25% 的 CPU 和 ~6MB 的 RAM 上。我让脚本运行了大约 10 分钟，但什么也没发生。
大约 33,000 个返回的行（大约 5MB 的数据）是否太多，Python 无法立即获取？我是否被卡在一次迭代一个？或者我可以做些什么来加快速度？
编辑：这是一些控制台输出
12:56:26.019: Adding new column 'weight' and related index to r_ele
12:56:26.019: Querying database
12:56:28.079: Starting weight calculations
12:56:28.079: Weight: 1.0
12:56:28.079: Weight: 0.5
12:56:28.080: Weight: 0.5
12:56:28.338: Weight: 1.0
12:56:28.339: Weight: 3.0
12:56:28.843: Weight: 1.5
12:56:28.844: Weight: 1.0
12:56:28.844: Weight: 0.5
12:56:28.844: Weight: 0.5
12:56:28.845: Weight: 0.5
12:56:29.351: Weight: 0.5
12:56:29.855: Weight: 0.5
12:56:29.856: Weight: 1.0
12:56:30.371: Weight: 0.5
12:56:30.885: Weight: 0.5
12:56:31.146: Weight: 0.5
12:56:31.650: Weight: 1.0
12:56:32.432: Weight: 0.5
12:56:32.951: Weight: 0.5
12:56:32.951: Weight: 0.5
12:56:32.952: Weight: 1.0
12:56:33.454: Weight: 0.5
12:56:33.455: Weight: 0.5
12:56:33.455: Weight: 1.0
12:56:33.716: Weight: 0.5
12:56:33.716: Weight: 1.0
这是 SQL 查询：
//...snip (it wasn't the culprit)...
来自 SQLiteStudio 的 EXPLAIN QUERY PLAN 的输出：
0 0 0 SCAN TABLE r_ele AS re USING COVERING INDEX r_ele_fk (~500000 rows)
0 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 1
1 0 0 SEARCH TABLE re_pri USING INDEX re_pri_fk (fk=?) (~10 rows)
0 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 2
2 0 0 SEARCH TABLE ke_pri USING INDEX ke_pri_fk (fk=?) (~10 rows)
2 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 3
3 0 0 SEARCH TABLE k_ele USING AUTOMATIC COVERING INDEX (value=?) (~7 rows)
3 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 4
4 0 0 SEARCH TABLE k_ele USING COVERING INDEX idx_k_ele (fk=?) (~10 rows)
0 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 5
5 0 0 SEARCH TABLE k_ele USING COVERING INDEX idx_k_ele (fk=?) (~10 rows)
0 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 6
6 0 0 SEARCH TABLE re_pri USING INDEX re_pri_fk (fk=?) (~10 rows)
0 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 7
7 0 0 SEARCH TABLE ke_pri USING INDEX ke_pri_fk (fk=?) (~10 rows)
7 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 8
8 0 0 SEARCH TABLE k_ele USING AUTOMATIC COVERING INDEX (value=?) (~7 rows)
8 0 0 EXECUTE CORRELATED SCALAR SUBQUERY 9
9 0 0 SEARCH TABLE k_ele USING COVERING INDEX idx_k_ele (fk=?) (~10 rows)
【问题讨论】：
-
您是否尝试过只遍历光标：
for row in cursor: ...？ -
fetchone（或迭代）不可能导致它每次都重新运行查询。cursor对象通常甚至不知道它运行的查询。所以，不管你的问题是什么，都不是。 -
另外，作为旁注：使用
if row is None:，而不是if row == None:。在大多数情况下，它并没有真正的区别，但它更符合习惯（而且它也更快一些，并且在极少数情况下，它确实会有所作为，它会是你想要的)。 -
无论如何……你确定你在 Python 和 SQLite Studio 中对完全相同的数据库运行完全相同的查询吗？像将错误的参数绑定到 LIKE 中的参数这样愚蠢的事情可以将时间从几毫秒变成几小时……
-
你为什么打开这个问题没有显示执行的SQL语句？ AFAIK 很多人使用 SQL 数据库（sqlite 和无），即使使用非常大的数据也没有太多关于性能的问题，所以我怀疑 you 做错了什么（在 SQL 中）。