2010-04-30 44 views
3

从德尔福2010到远程MySQL 5.09服务器的插入速度极慢,这是一个主要的问题。从Delphi远程插入到远程MySQL数据库的速度非常慢

到目前为止,我曾尝试:用

  • Zeoslib V7阿尔法
  • MyDAC
  • 我用配料和直接插入使用ADO(使用表MySQL的ODBC驱动程序

    • ADO访问),并与Zeos我已经使用SQL插入与查询,然后使用表直接模式,并使用applyupdates和提交缓存更新表模式。使用MyDAC我使用表访问模式,然后直接SQL插入,然后批量SQL插入

      我试过的所有技术,我设置压缩打开和关闭没有可辨别的差异。

      到目前为止,我已经看到了一个全面的相同7.5记录每秒!

      现在,我想从这一点来看,假设远程服务器速度很慢,但MySQL Workbench速度非常快,并且迁移工具包可以非常快速地管理初始迁移(说实话,我不记得有多快 - 哪种意味着它很快)

      编辑1

      速度会更快,我到SQL写入文件,通过FTP上传文件到服务器,然后将它导入直接在远程服务器 - 我想知道他们是否会限制传入的MySQL流量,但这并不能解释为什么MySQL Workbench太快了!

      编辑2

      在最基本的层面上,代码已经:

      while not qMSSQL.EOF do 
      begin 
          qMySQL.SQL.Clear; 
          qMySQL.SQL.Add('INSERT INTO tablename (fieldname1) VALUES (:fieldname1)'); 
          qMySQL.ParamByName('fieldname1').asString:=qMSSQL.FieldByName('fieldname1').asString; 
          qMySQL.ExecSQL; 
          qMSSQL.Next; 
      end; 
      

      我又试图

      qMySQL.CachedUpdates:=true; 
      i:=0; 
      while not qMSSQL.EOF do 
      begin 
          qMySQL.SQL.Clear; 
          qMySQL.SQL.Add('INSERT INTO tablename (fieldname1) VALUES (:fieldname1)'); 
          qMySQL.ParamByName('fieldname1').asString:=qMSSQL.FieldByName('fieldname1').asString; 
          qMySQL.ExecSQL; 
          inc(i); 
          if i>100 then 
          begin 
          qMySQL.ApplyUpdates; 
          i:=0; 
          end; 
          qMSSQL.Next; 
      end; 
      qMySQL.ApplyUpdates; 
      

      现在,这个代码与CachedUpdates:=False(这显然从来没有真正写回到数据库)速度快得要命!

      坦率地说,我认为这是连接 - 我感觉这是连接...只是等待他们回到我身边!

      感谢您的帮助!

    +0

    如果您显示您的代码,检测您的瓶颈将非常有帮助 – 2010-04-30 15:46:10

    +1

    如果您使用本地服务器,插入速度有多快?也许这是一个与运输有关的问题(连接速度慢)。 – mjn 2010-04-30 16:40:36

    +0

    您的代码不正确。设置循环外部的SQL代码*,然后调用Prepare。在循环内只分配参数并执行,否则会失去参数的优点。在循环之外明确地开始一个事务,并在最后提交。 CachedUpdates设置为False意味着数据直接转到数据库,并且不会在本地缓存。不要使用CachedUpdates,它们不是为了速度。 – 2010-05-04 12:15:31

    回答

    0

    你使用查询参数吗?插入的最快方法应该是使用普通查询和参数(即INSERT INTO表(字段)VALUES(:field)),准备查询,然后根据需要在单个事务中分配参数并执行多次 - 最后提交(不要使用任何味道的自动提交)

    在大多数数据库中,每次执行查询时都会避免硬解析,这需要时间。参数只允许查询一次,然后根据需要重新执行多次。

    使用服务器设施来检查发生了什么 - 许多提供了一种方法来检查正在运行的语句正在做什么。

    +0

    我起初使用查询参数和批量插入(我总是尝试使用SQL第一,如果我可以)但平均速度是相同的:( – 2010-04-30 12:29:50

    +0

    我不会使用ADO批量插入,它可能会减少往返,但它获得控制的插入,就像缓存更新一样,恕我直言,方法是让语句直接进入数据库,尽可能减少开销。无论如何,首先你必须找到瓶颈真正的位置。 – 2010-04-30 19:26:16

    +0

    正确答案Idsandon谁提到检查服务器在这种情况下,可能会回答我的问题的设施(数据库工作台结果必须是虚假的) – 2010-05-03 08:08:12

    0

    我不知道ZeosLib,但使用ADO与ODBC驱动程序,您将无法获得最快的方式插入的记录,这里没几步,可能使您的插入速度快:

    1. 使用Mydac对于直接访问,它们不需要缓慢的ODBC> ADO> OLEDB> MySqlLib就可以连接到Mysql。

    2. 插入前首先打开连接。

    3. 如果您有大量插入,如1000或更多,请尝试使用事务并在100条记录或更多取决于记录数后提交。

    即使使用ZeosLib或ADO,第3点可能会使您的插入速度更快。

    +0

    感谢您的回答,但是我已经尝试过2&3(目前仍然安装MyDAC) 我本来希望批量插入会更快,但它仍然以与插入一条记录相同的平均速度出现在电线上的时间!? – 2010-04-30 12:28:53

    3

    你可以试试AnyDAC和它的Array DML功能。它可能会加速标准SQL INSERT几次。

    +0

    感谢德米特里,我尝试了一个演示,并且Array DML功能看起来非常有趣 - 但速度相当类似 – 2010-05-03 07:58:04

    +0

    我们尝试使用MySQL数组dml - 这真的很快,看起来你的系统上有些东西会造成麻烦, – oodesigner 2010-09-23 05:25:23

    0

    你有两件独立的事情发生在这里。首先,你的Delphi程序正在创建Insert语句并将它们发送到数据库服务器,然后服务器正在处理它们。您需要检查两端以找到瓶颈。我不熟悉MySql工具,但我敢打赌,你可以很容易地找到一个SQL分析器。使用它来从Delphi应用程序中分析插入,并将其与Workbench工具中正在运行的插入进行比较,看看是否有显着差异。

    如果不是,则放慢速度在您的应用程序中。尝试将其连接到Sampling Profiler或其他一些了解Delphi的分析工具,它会告诉你在哪里花费大量时间。一旦你知道了,那么你可以努力攻击这个问题,或者回到这里问一个更具体的问题。但是,除非你知道问题来自哪里,否则你在这里得到的任何答案都只会被教育的猜测充其量。

    +0

    谢谢梅森,我是p retty确定它是服务器速度而不是我的代码,我只是不是100%确定我正在使用mysql库,和/或关于Delphi的最佳实践是什么,但它们似乎与我尝试的类似无论如何。 – 2010-05-03 07:59:07

    1

    对不起,这个答复很长时间后,你问这个问题。

    我有一个类似的问题。 BDS2006通过ODBC通过ODBC连接到MySQL - 花费25分钟运行 - 每秒25个插入。我正在使用TDatabase连接并将TTable Tquery附加到它。准备好SQL语句。

    主要改进是当我开始在循环内开始交易。一个简单的例子,Memebrships有会员期限。在插入成员和成员之前开始交易,之后再提交。成员数量为01585,在交易之前花了279.90秒处理所有的会员记录,但花了6.71秒。

    几乎太好了,我们仍然在努力修复其他慢比特的代码。

    也许马克你已经解决了你的问题,但它可能会帮助别人。

    +0

    做了一些更改。 Commit是昂贵的,所以性能好的关键是选择一个提交频率,以平衡提交的开销与持有事务的开销太长。 – DavidG 2010-06-20 02:39:26

    +0

    经过进一步的调整后,我设法使用交易将运行时间从19分钟减少到51秒。 – DavidG 2010-06-20 03:12:05

    +0

    +1非常感谢大卫!我实际上现在不记得我是否尝试过交易,当你说在整个网络中你是指通过本地网络还是互联网? – 2010-06-21 10:43:17