我正在运行一个cron作业（每15分钟一次），大约需要一分钟才能完成。它会进行大量的API调用并将数据存储到数据库中。
现在我在开头创建一个mysql连接，并在代码中使用相同的连接。大部分时间都花在进行API调用上。
仅在存储数据的时候创建新的数据库连接会更有效吗（下面）？
[编辑]这是MYSQL报告。我是mysql的新手 - 有没有理由根据以下报告重新连接到DB？
1 MySQL 5.1.26-rc-5.1.26r uptime 0 1:8:58 Tue Jun 15 21:25:03 2010
2
3 __ Key _________________________________________________________________
4 Buffer used 33.00k of 24.00M %Used: 0.13
5 Current 4.52M %Usage: 18.84
6 Write hit 33.33%
7 Read hit 69.16%
8
9 __ Questions ___________________________________________________________
10 Total 1.75k 0.4/s
11 COM_QUIT 319.92k 77.3/s %Total: 18312.
12 -Unknown 319.90k 77.3/s 18311.
13 DMS 1.53k 0.4/s 87.58
14 Com_ 199 0.0/s 11.39
15 QC Hits 1 0.0/s 0.06
16 Slow 144 0.0/s 8.24 %DMS: 9.41
17 DMS 1.53k 0.4/s 87.58
18 SELECT 1.22k 0.3/s 69.83 79.74
19 INSERT 155 0.0/s 8.87 10.13
20 UPDATE 155 0.0/s 8.87 10.13
21 REPLACE 0 0/s 0.00 0.00
22 DELETE 0 0/s 0.00 0.00
23 Com_ 199 0.0/s 11.39
24 check 86 0.0/s 4.92
25 show_status 41 0.0/s 2.35
26 set_option 23 0.0/s 1.32
27
28 __ SELECT and Sort _____________________________________________________
29 Scan 653 0.2/s %SELECT: 53.52
30 Range 0 0/s 0.00
31 Full join 0 0/s 0.00
32 Range check 0 0/s 0.00
33 Full rng join 0 0/s 0.00
34 Sort scan 0 0/s
35 Sort range 590 0.1/s
36 Sort mrg pass 0 0/s
37
38 __ Query Cache _________________________________________________________
39 Memory usage 43.57k of 12.00M %Used: 0.35
40 Block Fragmnt 25.35%
41 Hits 1 0.0/s
42 Inserts 916 0.2/s
43 Insrt:Prune 916:1 0.2/s
44 Hit:Insert 0.00:1
45
46 __ Table Locks _________________________________________________________
47 Waited 0 0/s %Total: 0.00
48 Immediate 1.65k 0.4/s
49
50 __ Tables ______________________________________________________________
51 Open 47 of 1024 %Cache: 4.59
52 Opened 54 0.0/s
53
54 __ Connections _________________________________________________________
55 Max used 3 of 60 %Max: 5.00
56 Total 319.92k 77.3/s
57
58 __ Created Temp ________________________________________________________
59 Disk table 2 0.0/s
60 Table 28 0.0/s
61 File 5 0.0/s
62
63 __ Threads _____________________________________________________________
64 Running 3 of 3
65 Cached 0 of 4 %Hit: 100
66 Created 3 0.0/s
67 Slow 0 0/s
68
69 __ Aborted _____________________________________________________________
70 Clients 0 0/s
71 Connects 319.86k 77.3/s
72
73 __ Bytes _______________________________________________________________
74 Sent 52.36M 12.7k/s
75 Received 23.17M 5.6k/s
答案 0 :(得分：2)
删除连接并重新建立它们很少有利。建立与DB的连接通常是一个相当繁重的过程。许多应用程序创建连接池只是为了避免这种情况：建立一些合理数量的连接，然后长时间保留它们，甚至可能永远保持连接，让每个线程或用户在需要时从池中获取连接，然后再将它们返回
如果您遇到孤立连接问题 - 查询失败并且您永远无法释放连接 - 真正的解决方案是实现正确的异常处理，以便不会发生。
如果有一个线程在非活动连接上，而其他线程因为数据库已达到最大连接而失败，那么，是的，你需要考虑释放连接。
附注：MySQL声称它可以非常快速地建立连接，因此与其他数据库引擎相比，这不是一个问题。我从未对此进行过基准测试。
答案 1 :(得分：1)
考虑到我们不知道（2）中发生了什么，给出一个意见有点难。
请记住，优化的第一条规则是：“Don't do it”。从某种意义上说，除非你有充分的理由（对于其他用户来说DB缓慢，在你的cron进程中CPU达到最大值等等）来解决性能问题，否则最好不要做任何事情。
如果你确实有某些理由来提高程序的效率，那么你将有一些难以比较的数字（例如：你的cron批处理需要很长时间，你必须跳过一些运行，或者它结束得太晚了满足用户要求，或填写回滚结构等）你可以简单地在你的测试环境中应用你的修改（它看起来像一个简单的修复，除非你忘了告诉我们实现它会非常复杂）并查看是否它改善了您测量的内容并且在开始时缺乏。
我很抱歉，“我想知道这是否会更有效率”，而不知道你真正试图解决的问题是问题的解决方案。
答案 2 :(得分：1)
如果瓶颈是没有足够的空闲插槽连接到DB，那么，是的，尽可能关闭连接。
否则，使用它并重复使用它（至少在同一请求中）。