QSqlQuery性能优化、不同执行方式差异及查询耗时获取方法

• 先声明对象再调用exec()传SQL、构造函数直接传SQL这两种写法不存在可测量的性能差异。翻看Qt对应版本的源码就能看到，传入SQL语句的QSqlQuery构造函数，内部逻辑就是先初始化空的QSqlQuery实例，再直接调用exec(sql)完成执行，两者走的是完全一致的代码路径，没有任何额外的性能损耗，选哪种写法纯看个人代码风格偏好。
• 先prepare()再exec()的写法，性能表现完全取决于你的使用场景：
  • 如果是单次执行某条SQL，执行完就丢弃QSqlQuery对象：这种写法和前两种性能基本持平，只会因为驱动和数据库端的预处理流程产生可以忽略的极微小开销，不会成为性能瓶颈。
  • 如果是批量重复执行结构相同、参数不同的SQL（这也是大量查询场景下的绝大多数情况）：这种写法的性能会远高于直接拼接SQL调用exec()的方案。Qt对接SQL Server用的QODBC驱动是支持服务端预处理的，SQL Server会为prepare后的语句缓存执行计划，后续重复执行时不需要重复做SQL语法解析、执行计划生成的工作；同时配合参数绑定还能省去反复拼接SQL字符串的开销，还能天然避免SQL注入问题，批量查询场景下优先用这种方案。
    注意：如果你的大量查询都是完全不同结构、没有重复模式的SQL，每次prepare后只执行一次，那预处理不会带来性能收益，但额外开销极小，也不需要刻意规避。

• 客户端全链路耗时统计：用Qt自带的高精度计时器统计即可，覆盖从调用执行接口到结果处理完成的全流程耗时，示例代码：

#include <QElapsedTimer>
#include <QSqlQuery>
#include <QDebug>

QElapsedTimer costTimer;
costTimer.start();

// 替换成你实际的查询执行、结果处理逻辑
QSqlQuery query;
// 支持直接exec / prepare+bindValue+exec 任意执行方式
query.exec("SELECT name, salary FROM employee WHERE salary > 50000");
while (query.next()) {
    // 读取结果集的逻辑也可以纳入统计范围
    QString name = query.value(0).toString();
    int salary = query.value(1).toInt();
}

qint64 totalCostMs = costTimer.elapsed(); // 毫秒级总耗时，需要更高精度可以调用nsecsElapsed()获取纳秒级时间差
qDebug() << "Query cost:" << totalCostMs << "ms";

• 服务端纯执行耗时统计：如果需要排除客户端网络传输、结果集序列化的影响，拿到SQL Server侧的纯执行时间，可以在执行目标查询前先执行SET STATISTICS TIME ON语句，后续执行查询时，SQL Server会在返回结果的同时附带语法解析、语句编译、实际执行各阶段的耗时统计，通过QSqlQuery的消息接口就能读取到对应数值。

内容的提问来源于stack exchange，提问作者Sébastien B.