求助：基于UniDAC实现带中断按钮的UniQuery进度条稳定方案

兄弟，我之前踩过UniDAC多线程查询的不少坑，看你遇到的问题简直感同身受！结合实践经验，给你几个能落地的稳定方案：

一、先解决最核心的线程不稳定问题：绝对不要共享UniDAC组件实例 #

这是90%的UniDAC线程不稳定的根源！主线程和子线程必须各自创建独立的TUniConnection和TUniQuery实例，绝对不能跨线程复用同一个组件。

给你一个完整的线程实现示例：

type
  TQueryThread = class(TThread)
  private
    FOnFetchProgress: TFetchProgressEvent;
    procedure SetOnFetchProgress(const Value: TFetchProgressEvent);
  protected
    procedure Execute; override;
  public
    property OnFetchProgress: TFetchProgressEvent read FOnFetchProgress write SetOnFetchProgress;
  end;

procedure TQueryThread.SetOnFetchProgress(const Value: TFetchProgressEvent);
begin
  FOnFetchProgress := Value;
end;

procedure TQueryThread.Execute;
var
  LocalUniConn: TUniConnection;
  LocalUniQuery: TUniQuery;
begin
  // 每个线程独立创建连接和查询组件
  LocalUniConn := TUniConnection.Create(nil);
  LocalUniQuery := TUniQuery.Create(nil);
  try
    // 完全独立配置连接参数，和主线程保持一致但不共享实例
    LocalUniConn.ProviderName := 'SQL Server';
    LocalUniConn.Server := '你的数据库地址';
    LocalUniConn.Database := '目标库';
    LocalUniConn.Username := '账号';
    LocalUniConn.Password := '密码';
    LocalUniConn.Connect;

    LocalUniQuery.Connection := LocalUniConn;
    LocalUniQuery.SQL.Text := 'WAITFOR DELAY ''00:00:05''; SELECT top(200000) * FROM dbo.MYTable';
    // 启用非阻塞模式+进度回调
    LocalUniQuery.NonBlocking := True;
    LocalUniQuery.OnFetchProgress := FOnFetchProgress;
    LocalUniQuery.Execute;

    // 循环处理查询，同时监听中断信号
    while (not Terminated) and LocalUniQuery.Active do
    begin
      if LocalUniQuery.NeedExecute then
        LocalUniQuery.ExecuteNext;
      Sleep(10); // 降低CPU占用，给UI线程留资源
    end;

    // 如果收到中断信号，安全取消查询
    if Terminated and LocalUniQuery.Active then
    begin
      LocalUniQuery.Cancel;
    end;
  finally
    // 确保资源释放
    LocalUniQuery.Free;
    if LocalUniConn.Connected then
      LocalUniConn.Disconnect;
    LocalUniConn.Free;
  end;
end;

二、修复NonBlocking模式下表单延迟显示的问题 #

你遇到的“表单要等5秒查询完成才显示”，本质是主线程被查询的初始化阶段（比如WAITFOR、执行计划生成）阻塞了。解决方法很简单：把整个查询的启动逻辑全丢到子线程，主线程只负责启动线程，绝对不要在主线程里调用查询的Execute。

主线程的按钮点击逻辑应该是这样：

var
  FQueryThread: TQueryThread;

procedure TMainForm.btnStartQueryClick(Sender: TObject);
begin
  btnStartQuery.Enabled := False;
  btnBreakQuery.Enabled := True;
  ProgressBar1.Position := 0;

  // 创建并启动查询线程，挂起状态创建避免提前执行
  FQueryThread := TQueryThread.Create(True);
  FQueryThread.OnFetchProgress := FetchProgressUpdate;
  FQueryThread.OnTerminate := QueryThreadFinish;
  FQueryThread.Start;
end;

// 进度更新的回调，必须用Synchronize保证线程安全
procedure TMainForm.FetchProgressUpdate(Sender: TObject; Progress, MaxProgress: Integer);
begin
  Synchronize(procedure
  begin
    ProgressBar1.Max := MaxProgress;
    ProgressBar1.Position := Progress;
  end);
end;

// 线程结束后的清理
procedure TMainForm.QueryThreadFinish(Sender: TObject);
begin
  btnStartQuery.Enabled := True;
  btnBreakQuery.Enabled := False;
  FQueryThread := nil;
  ShowMessage('查询完成或已中断');
end;

三、可靠的中断按钮实现 #

中断绝对不能直接在主线程调用UniQuery.Cancel，跨线程操作组件实例会导致各种诡异错误。正确的做法是：

1. 主线程点击中断按钮时，给子线程发Terminate信号
2. 子线程在循环里检测Terminated标志，主动调用本地查询实例的Cancel

主线程的中断按钮逻辑：

procedure TMainForm.btnBreakQueryClick(Sender: TObject);
begin
  if Assigned(FQueryThread) then
  begin
    FQueryThread.Terminate;
    btnBreakQuery.Enabled := False;
  end;
end;

四、如果UniDAC还是不稳定，试试替代方案 #

如果严格遵循线程安全后还是有问题，可以换成原生的TADOQuery配合多线程实现，逻辑和上面完全一致——每个线程独立创建连接和查询实例，启用OnFetchProgress事件，中断方式相同。我之前在某些复杂查询场景下，ADO的线程稳定性反而比UniDAC好一些，你可以根据自己的场景测试。

针对你提到的具体SQL：

UniQuery1.SQL.Text := 'WAITFOR DELAY ''00:00:05''; SELECT top(200000) * FROM dbo.MYTable';

这个SQL的WAITFOR阶段会阻塞查询的初始化，所以必须放到子线程里执行，主线程绝对不能碰这个查询的启动逻辑，否则必然会卡住表单。

备注：内容来源于stack exchange，提问作者Safonov Alexey