尧图网站建设 
在实际的 Qt 桌面应用开发中SQLite 是最常见、最省事的内嵌式数据库之一部署简单不需要独立服务进程。但当单表数据量达到千万级之后问题就会变得非常具体查询变慢、分页跳页卡顿、批量写入时界面僵住、滚动列表时 CPU 占用飙升。很多人第一反应是换 PostgreSQL或换 MySQL但对客户端应用来说这并不现实——交付物是一个桌面程序不能要求用户额外安装数据库服务。解决这个问题的关键并不在 SQLite 本身而在于使用方式。SQLite 在千万级数据下依然能保持不错的吞吐量真正拖垮体验的是那些未被优化的查询语句、错误的索引设计以及把耗时操作直接放在 UI 线程里的写法。本文会围绕 Qt 和 SQLite 的组合讲清楚一条完整的技术主线如何用游标分页替代传统 OFFSET 分页如何把查询放到底层线程并安全地回传界面如何设计索引和表结构让千万级数据的 CRUD 保持流畅。最终目标不是简单地能用而是让读者能照着一套可复现的工程方案逐步改造自己的项目彻底告别 UI 卡顿。1. 先理解 UI 卡顿的根源查询不是慢而是阻塞了正确的线程很多人在千万级 SQLite 数据下遇到界面卡顿第一反应是去优化 SQL结果发现 SQL 已经写得很简单了仍然卡。这里要先把问题的层次分清楚UI 卡顿通常不是查询本身慢到无法接受而是查询占用了不该占用的线程——UI 线程。1.1 为什么 Qt 窗口会在数据量大时无响应Qt 的界面事件循环运行在主线程所有绘制、鼠标点击、键盘输入、窗口消息都由主线程处理。如果主线程里执行了一段耗时操作比如一次全表扫描、一次大数据量的 QSqlQuery::exec()那么在执行完之前事件循环无法处理新的 UI 消息窗口就会表现为失去响应或卡住。SQLite 查询在数据量很小的时候几乎瞬时完成用户感知不到阻塞。但数据量到了千万级一次没有命中索引的查询可能需要几百毫秒甚至几秒如果有排序、有子查询、有 JOIN时间会更长。这段时间内主线程被占用用户拖动滚动条、点击按钮、输入文字都会无响应。实际项目里更隐蔽的情况是查询本身只用了 50 毫秒但要在界面上一次性创建几千个 QTableWidgetItem 并插入表格这一步在主线程里执行也会导致明显卡顿。也就是说卡顿既可能来自查询也可能来自 UI 控件的批量刷新。1.2 SQLite 在桌面应用中的角色定位SQLite 是一个文件型数据库读写都要经过文件系统。它天然不适合承担海量数据并发服务端的角色但在桌面应用中它是非常合理的持久化方案。千万级数据量对 SQLite 来说不是不可用而是要求开发者在访问模式上做约束。约束主要体现在三方面尽量避免大范围的无索引扫描尽量通过条件过滤缩小结果集。尽量避免一次性把大量数据加载到内存和 UI 控件中。尽量避免在主线程中执行任何可能耗时超过几十毫秒的数据库操作。这三个约束并非 SQLite 独有任何桌面应用搭配数据库都会遇到。但 SQLite 因为部署简单、常被拿来当轻量级存储用反而更容易被忽略这三条原则。很多人默认反正数据量不大结果数据涨到千万级之后才发现问题。1.3 分辨哪些操作会在 UI 线程执行在 Qt 中直接写在 QWidget 子类、QMainWindow 子类、或者由 UI 事件回调直接调用的数据库操作默认都在主线程执行。常见的高危写法有在按钮 clicked 槽函数里直接执行 QSqlQuery::exec()。在 QTableView 的数据模型 data() 方法里触发 SQL 查询。用 QSqlQueryModel 直接绑定大表并在界面打开时 setQuery(SELECT * FROM big_table)。在构造函数里做大量数据初始化。用 QTimer 在主线程定期轮询数据库。这些写法的共同问题是数据库操作和 UI 操作混在同一个线程里阻塞无法避免。要解决就必须拆开——数据库操作放到工作线程查询结果通过信号回传主线程再由主线程只刷新需要的部分界面。1.4 从减少工作量到错开工作位置解决 UI 卡顿有两条路缺一不可减少工作量通过索引、条件过滤、游标分页让单次查询只处理必要的数据而不是全表。错开工作位置把无法避免的耗时数据库操作放到非 UI 线程避免阻塞事件循环。只优化 SQL 不拆线程数据量继续增长后还是会卡只拆线程不优化 SQL内存和 CPU 消耗上去了滚动加载时的延迟也会变得很高。两类手段要配合使用本文后续的代码和实践都会围绕这两条线展开。2. 游标分页为什么比 OFFSET 分页更适合千万级数据SQLite 常见的分页写法是用 LIMIT 和 OFFSET比如SELECT * FROM records ORDER BY id LIMIT 20 OFFSET 0; SELECT * FROM records ORDER BY id LIMIT 20 OFFSET 20;这种写法在小数据量下没有问题但进入千万级之后OFFSET 越大查询越慢。原因很简单数据库要跳过 OFFSET 指定的行数才能返回目标数据跳过的过程仍然要扫描并丢弃这些行。OFFSET 等于 500 万时SQLite 实际上要扫描前 500 万行再返回第 500 万到第 500 万加 20 行而不仅仅是定位到第 500 万行。2.1 OFFSET 分页的深层次问题OFFSET 分页有三个问题在桌面应用中非常致命第一深分页性能退化。页数越靠后跳过的行越多查询耗时越长。用户翻到第 5000 页时一次翻页可能耗时数百毫秒甚至更久。第二数据变更导致分页结果不稳定。如果在翻页过程中有数据插入或删除基于 OFFSET 的分页会出现同一行重复出现或某一行被跳过的情况。桌面客户端经常需要离线缓存同步这种数据漂移问题很常见。第三OFFSET 分页无法与滚动加载很好地配合。因为每次滚动都需要知道当前已经加载到第几页然后计算新的 OFFSET。这个计算本身不难但深层页次的性能问题会一直存在。2.2 游标分页的基本原理游标分页Keyset Pagination不依赖 OFFSET而是依赖一个稳定、唯一、可排序的字段作为游标。每次查询时用上一次结果集最后一条记录的游标值作为查询条件获取它之后的 N 条记录。以自增主键 id 为例-- 第一页 SELECT * FROM records ORDER BY id LIMIT 20; -- 第二页以上一页最后一条记录的 id 为游标 SELECT * FROM records ORDER BY id WHERE id 20 LIMIT 20; -- 第三页 SELECT * FROM records ORDER BY id WHERE id 40 LIMIT 20;关键点在于WHERE id 上一页最后一条 id 这个条件在索引下是直接定位的不需要扫描之前的数据。无论当前游标在 100 还是 500 万查询耗时都只和要返回多少行有关和前面有多少行无关。这种分页方式有几个明显优点深分页性能稳定。查询条件简单可以复用联合索引。对新增数据的处理更稳定不会因为前面插入几行导致整个页次漂移。非常适合滚动加载更多这种交互模式。2.3 游标分页的适用边界游标分页不是银弹它有一个显著限制只能按顺序一页一页地翻不能直接跳到第 N 页。因为跳转需要知道第 N 页的起始游标值而这个值无法通过条件直接计算出来。如果产品需求允许只能上一页、下一页、滚动加载游标分页是最合适的。如果必须支持用户输入第 1000 页直接跳转那游标分页就不够用要做折中第一版先用 OFFSET 分页但加上 LIMIT 上限防止用户输入超大页数。或者提供一个跳转页的估算方案比如用 COUNT(*) 算总行数然后估算游标位置但这不是精确跳转。在 Qt 桌面客户端的常见场景中绝大多数列表、日志、历史记录、设备数据浏览都是顺序浏览下一页和滚动加载足够满足需求。游标分页完全能覆盖。2.4 SQLite 中游标分页的索引要求游标分页的查询要高效必须让 WHERE 条件和 ORDER BY 字段能命中同一个索引。如果游标字段是主键问题不大如果游标字段是普通字段需要建立合适的索引。典型的建表场景如下CREATE TABLE IF NOT EXISTS records ( id INTEGER PRIMARY KEY AUTOINCREMENT, device_id TEXT NOT NULL, event_time INTEGER NOT NULL, event_type INTEGER NOT NULL, payload TEXT, created_at INTEGER NOT NULL ); CREATE INDEX IF NOT EXISTS idx_records_device_time ON records(device_id, event_time, id);如果查询条件是 WHERE device_id ? ORDER BY event_time, id联合索引 (device_id, event_time, id) 就能同时服务过滤和排序。SQLite 可以在这个索引上直接按顺序定位游标而不需要回表扫描大量数据。需要说明的是SQLite 的 EXPLAIN QUERY PLAN 输出是验证索引是否生效的最直接方式。后续章节会具体演示怎么看。3. 环境准备与测试数据设计动手写代码之前先统一环境和数据结构。本文使用 Qt 6 与 SQLite 3 的组合实际项目如果还是 Qt 5.15主体代码差异不大但注意 QSqlQuery 的某些 API 细节和 CMake 配置要随版本调整。3.1 软件环境要求项目推荐版本或说明操作系统Windows 10/11、Ubuntu 20.04 及以上、macOS 均可Qt 版本Qt 5.15 或 Qt 6.2本文示例基于 Qt 6.5编译器MSVC 2019/2022、MinGW 11、Clang 均可构建工具CMake 3.16SQLite 驱动Qt SQL 模块自带的 QSQLITE 驱动SQLite 版本取决于 Qt 发行包一般 3.31支持 window function 和 UPSERT在 Qt 安装时确保选中了 Qt SQL 模块。Qt 的 SQLite 驱动默认编译在 Qt 内不需要单独安装 SQLite 动态库这一点比很多人想象的要省事。3.2 CMake 项目配置CMake 配置里要显式链接 Qt 的 Sql 和 Widgets 模块并开启 C17 支持。cmake_minimum_required(VERSION 3.16) project(CursorPaginationDemo VERSION 1.0 LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_AUTOMOC ON) find_package(Qt6 REQUIRED COMPONENTS Core Gui Widgets Sql) qt_add_executable(CursorPaginationDemo main.cpp MainWindow.cpp MainWindow.h RecordTable.cpp RecordTable.h DataGenerator.cpp DataGenerator.h ) target_link_libraries(CursorPaginationDemo PRIVATE Qt6::Core Qt6::Gui Qt6::Widgets Qt6::Sql )如果是 Qt 5将 qt_add_executable 换成 add_executable 即可链接库名改为 Qt5::Core 等。AUTOMOC 必须开启否则 Q_OBJECT 类无法生成元对象代码。3.3 构造千万级测试数据的策略测试千万级数据不建议在 UI 线程里一条一条插入那样会非常慢。推荐的方式是用 SQLite 的事务批量插入。在 Qt 中最直接的写法是void DataGenerator::generate(QSqlDatabase db, int totalRows, int batchSize) { db.transaction(); QSqlQuery query(db); query.prepare(INSERT INTO records(device_id, event_time, event_type, payload, created_at) VALUES (?, ?, ?, ?, ?)); for (int i 0; i totalRows; i) { query.bindValue(0, QString(dev-%1).arg(i % 100)); query.bindValue(1, QDateTime::currentMSecsSinceEpoch() - i * 1000); query.bindValue(2, i % 5); query.bindValue(3, QString(payload-%1).arg(i)); query.bindValue(4, QDateTime::currentMSecsSinceEpoch()); query.exec(); if (i % batchSize 0) { db.commit(); db.transaction(); } } db.commit(); }这里的 batchSize 建议取 5000 到 20000。事务可以显著减少磁盘 fsync 的次数批量提交能极大缩短整体插入时间。在没有实际验证之前不要轻易调整 SQLite 的 PRAGMA 参数比如 synchronous、journal_mode因为这些参数在异常断电场景下可能影响数据安全性。数据生成完以后最好用以下 SQL 快速验证行数和索引信息SELECT COUNT(*) FROM records; SELECT * FROM sqlite_master WHERE type index AND tbl_name records;如果 COUNT() 非常慢说明表结构和索引可能需要进一步优化。对于千万级 InnoDB 表COUNT() 也不是免费的但 SQLite 的 COUNT(*) 在这里更多用于验证目的不会频繁执行。3.4 初始化数据库连接数据库连接建议在独立的工作线程或应用初始化阶段创建不要每次查询都新建连接。Qt 中同一个 QSqlDatabase 连接可以被多个线程使用但必须注意一个连接同一时刻只能被一个线程使用跨线程共享时需要加锁或复用一个线程。QSqlDatabase DatabaseManager::openConnection(const QString dbPath) { QSqlDatabase db QSqlDatabase::addDatabase(QSQLITE, cursor_demo_conn); db.setDatabaseName(dbPath); if (!db.open()) { qCritical() open database failed: db.lastError().text(); return QSqlDatabase(); } QSqlQuery query(db); query.exec(PRAGMA journal_mode WAL;); query.exec(PRAGMA synchronous NORMAL;); query.exec(PRAGMA temp_store MEMORY;); query.exec(PRAGMA cache_size -64000;); // 64MB page cache return db; }WAL 模式在桌面应用中通常能显著提升并发读写性能。synchronous NORMAL 在 WAL 模式下是常见选择它减少了每次提交时的 fsync 次数同时崩溃恢复能力仍然可接受。cache_size 设为负数表示以 KB 为单位这里设置为 64MB适合缓存较多索引页和数据页。需要注意 addDatabase 的连接名必须唯一。如果反复调用 addDatabase 且不指定连接名Qt 会复用默认连接容易造成连接冲突。每次 addDatabase 使用不同的连接名用完之后用 QSqlDatabase::removeDatabase 清理这样可以避免连接泄漏。4. 核心代码用游标分页实现千万级 CRUD 的完整工程这一节是全文的核心。工程采用 Qt 的 Model/View 架构数据库层负责游标分页查询数据模型负责缓存当前页数据并暴露行数界面层通过 QTableView 展示。查询操作在 QThreadPool 或独立工作线程中执行结果通过信号回传到 UI 线程。4.1 项目文件结构为了清晰将项目按职责拆成以下几个文件CursorPaginationDemo/ ├── main.cpp ├── MainWindow.h / MainWindow.cpp ├── DatabaseManager.h / DatabaseManager.cpp ├── CursorPagingModel.h / CursorPagingModel.cpp ├── DataGenerator.h / DataGenerator.cpp └── CMakeLists.txtDatabaseManager 负责数据库连接和查询执行。CursorPagingModel 继承 QAbstractTableModel负责向 QTableView 提供数据。DataGenerator 负责生成测试数据。MainWindow 负责组装界面和触发加载更多。4.2 定义游标结构体游标本质上就是上一页最后一条记录的位置信息。在 SQLite 中如果排序字段是自增主键 id一个 qint64 足够。但很多业务表需要按时间排序而时间可能重复所以游标要包含多个字段且最后一个字段必须是唯一字段。struct Cursor { qint64 eventTime 0; qint64 id 0; bool isNull() const { return id 0 eventTime 0; } QString toWhereClause() const { // 继续扩展时可以改成参数绑定形式 return QString((event_time %1) OR (event_time %1 AND id %2)) .arg(eventTime) .arg(id); } };如果按 event_time 排序但 event_time 有大量重复值那么只用 event_time 做游标会导致数据错乱。解决方法就是 (event_time, id) 组合游标先按时间比时间相同再用 id 比。id 是主键本身唯一所以这种组合一定稳定。更高效的做法是直接构造一个复合比较表达式利用 SQLite 的行值比较语法。SQLite 3.15 支持WHERE (event_time, id) (?, ?) ORDER BY event_time, id这种写法可以对多列索引做更准确的定位但可读性不如 OR 写法。为了保险起见先用 OR 写法演示原理生产环境如果确认 SQLite 版本支持行值比较可以切换到行值形式。4.3 数据库查询接口数据库查询层使用 QSqlQuery 绑定参数。核心是 fetchPage 函数它接收一个已初始化的游标和每页条数返回本页数据列表和下一页游标。struct RecordItem { qint64 id; qint64 eventTime; int eventType; QString deviceId; QString payload; }; struct PageResult { QVectorRecordItem items; Cursor nextCursor; }; class DatabaseManager { public: static PageResult fetchPage(const QSqlDatabase db, const Cursor cursor, int pageSize); }; PageResult DatabaseManager::fetchPage(const QSqlDatabase db, const Cursor cursor, int pageSize) { PageResult result; QString sql SELECT id, event_time, event_type, device_id, payload FROM records ; if (!cursor.isNull()) { sql WHERE (event_time ?) OR (event_time ? AND id ?) ; } sql ORDER BY event_time, id LIMIT ?; QSqlQuery query(db); query.prepare(sql); if (!cursor.isNull()) { query.bindValue(0, cursor.eventTime); query.bindValue(1, cursor.eventTime); query.bindValue(2, cursor.id); query.bindValue(3, pageSize); } else { query.bindValue(0, pageSize); } if (!query.exec()) { qWarning() fetchPage failed: query.lastError().text(); return result; } while (query.next()) { RecordItem item; item.id query.value(0).toLongLong(); item.eventTime query.value(1).toLongLong(); item.eventType query.value(2).toInt(); item.deviceId query.value(3).toString(); item.payload query.value(4).toString(); result.items.push_back(item); result.nextCursor.eventTime item.eventTime; result.nextCursor.id item.id; } // 如果一页没有取满说明已经到末尾 if (result.items.size() pageSize) { result.nextCursor Cursor(); // 空游标表示没有下一页 } return result; }这里要重点解释首屏查询时 cursor 为空SQL 不加 WHERE直接按 event_time, id ORDER BY LIMIT取第一页。后续加载时游标已经是上一页最后一条记录WHERE 条件只返回比最后一条记录更大的数据。每次翻页最多扫描 pageSize 条数据加上索引定位的消耗不会因为总量千万级而变慢。如果本页不足 pageSize说明数据库已经没有更多数据将 nextCursor 置空前端可以停止继续加载。4.4 数据模型层缓存当前页并快速响应 UICursorPagingModel 继承 QAbstractTableModel。它不需要一次加载全部数据只需要维护两个区域当前已加载的数据集合和一个加载中的状态标志。class CursorPagingModel : public QAbstractTableModel { Q_OBJECT public: explicit CursorPagingModel(QObject *parent nullptr); int rowCount(const QModelIndex parent QModelIndex()) const override; int columnCount(const QModelIndex parent QModelIndex()) const override; QVariant data(const QModelIndex index, int role Qt::DisplayRole) const override; QVariant headerData(int section, Qt::Orientation orientation, int role) const override; public slots: void appendPage(const QVectorRecordItem items); private: QVectorRecordItem m_items; }; int CursorPagingModel::rowCount(const QModelIndex parent) const { if (parent.isValid()) { return 0; } return m_items.size(); } int CursorPagingModel::columnCount(const QModelIndex parent) const { if (parent.isValid()) { return 0; } return 5; } QVariant CursorPagingModel::data(const QModelIndex index, int role) const { if (!index.isValid() || index.row() 0 || index.row() m_items.size()) { return QVariant(); } const RecordItem item m_items.at(index.row()); if (role Qt::DisplayRole) { switch (index.column()) { case 0: return item.id; case 1: return QDateTime::fromMSecsSinceEpoch(item.eventTime).toString(yyyy-MM-dd HH:mm:ss); case 2: return item.eventType; case 3: return item.deviceId; case 4: return item.payload; default: return QVariant(); } } return QVariant(); } void CursorPagingModel::appendPage(const QVectorRecordItem items) { if (items.isEmpty()) { return; } int first m_items.size(); int last first items.size() - 1; beginInsertRows(QModelIndex(), first, last); m_items items; endInsertRows(); }这里最关键的是 appendPage 中的 beginInsertRows/endInsertRows 调用。只有通过这对函数通知视图QTableView 才会局部刷新新增行而不是把整个视图重新加载一遍。如果这里忘掉 begin/end 调用或者用 qDeleteAll 之类的方式手动刷新UI 仍然会卡顿。4.5 工作线程与界面线程的协作查询不能放到模型里直接调用要放到线程池中执行。Qt 提供了多种异步方案比如 QThread、QtConcurrent、QThreadPool QRunnable。这里用 QThreadPool QRunnable 作为示例因为它的生命周期管理更简单适合高频次小任务。定义异步任务class FetchPageTask : public QRunnable { public: FetchPageTask(const QSqlDatabase db, const Cursor cursor, int pageSize, QObject *receiver, std::functionvoid(const PageResult ) callback) : m_db(db) , m_cursor(cursor) , m_pageSize(pageSize) , m_receiver(receiver) , m_callback(std::move(callback)) { setAutoDelete(true); } void run() override { PageResult result DatabaseManager::fetchPage(m_db, m_cursor, m_pageSize); // 回调到 UI 线程 if (m_receiver) { QMetaObject::invokeMethod(m_receiver, [this, result]() { m_callback(result); }, Qt::QueuedConnection); } } private: QSqlDatabase m_db; Cursor m_cursor; int m_pageSize; QObject *m_receiver; std::functionvoid(const PageResult ) m_callback; };在实际工程里QRunnable 内部持有 QSqlDatabase 会有连接线程归属的问题。更稳妥的方式是维护一个专门的工作线程在该线程中创建数据库连接然后所有查询都投递到这个线程中执行。用 QThreadPool 时如果多个任务共享同一个 QSqlDatabase 连接必须加锁否则 SQLite 驱动会报错或者产生未定义行为。一个更简单的方案是每个任务自己打开一个只读连接void FetchPageTask::run() override { QSqlDatabase taskDb QSqlDatabase::addDatabase(QSQLITE, QString(task_conn_%1).arg(reinterpret_castquintptr(QThread::currentThread()))); taskDb.setDatabaseName(m_dbPath); taskDb.open(); PageResult result DatabaseManager::fetchPage(taskDb, m_cursor, m_pageSize); QMetaObject::invokeMethod(m_receiver, [this, result]() { m_callback(result); }, Qt::QueuedConnection); taskDb.close(); QSqlDatabase::removeDatabase(taskDb.connectionName()); }这种方式在每次滚动加载时新建和关闭连接对 SQLite 来说成本不高因为打开文件本身通常只有几十微秒到几百微秒。但要注意连接名不能重复否则 addDatabase 会复用已有连接。使用当前线程地址作为连接名的一部分可以避免冲突。4.6 UI 层的滚动加载触发MainWindow 中监听 QTableView 的垂直滚动条当滚动条接近底部时触发下一页加载。这里最常用的方式是用一个 QTimer 做节流避免快速滚动时连续发出大量查询请求。void MainWindow::setupUi() { m_tableView new QTableView(this); m_model new CursorPagingModel(this); m_tableView-setModel(m_model); setCentralWidget(m_tableView); connect(m_tableView-verticalScrollBar(), QScrollBar::valueChanged, this, MainWindow::onScrollBarChanged); m_throttleTimer new QTimer(this); m_throttleTimer-setInterval(150); m_throttleTimer-setSingleShot(true); connect(m_throttleTimer, QTimer::timeout, this, MainWindow::loadNextPage); // 启动时加载第一页 m_cursor Cursor(); loadNextPage(); } void MainWindow::onScrollBarChanged(int value) { QScrollBar *bar m_tableView-verticalScrollBar(); // 距离底部还剩 20% 时触发加载 if (bar-maximum() 0 value bar-maximum() * 0.8) { m_throttleTimer-start(); } } void MainWindow::loadNextPage() { if (m_loading) { return; } // 如果游标为空说明没有更多数据 if (m_cursor.isNull() m_model-rowCount() 0) { return; } m_loading true; // 这里把数据库路径传进去任务内部自建连接 QThreadPool::globalInstance()-start( new FetchPageTask(m_dbPath, m_model-rowCount() 0 ? m_cursor : Cursor(), m_pageSize, this, [this](const PageResult result) { m_model-appendPage(result.items); m_cursor result.nextCursor; m_loading false; if (result.items.isEmpty()) { qInfo() no more data; } }) ); }这段代码里要把第一次加载和后续加载区别对待。第一次加载时 m_model-rowCount() 为 0游标为空SQL 不带 WHERE 条件直接从头取第一页。后续加载时使用上一轮的 nextCursor。如果数据已经全部加载完nextCursor 被置空loadNextPage 直接返回不再发请求。使用 QTimer 做节流是必要的。快速拖动滚动条时valueChanged 会连续触发多次如果每次都去读数据库既造成不必要的 I/O又可能导致 UI 抖动。150ms 的单次计时器可以保证在用户停止滚动后再发起查询。4.7 更新操作和删除操作对游标的影响游标分页下还需要考虑数据更新和删除对分页的影响。如果用户正在浏览列表另一条线程删除了当前已经加载页的某条数据这会带来两个问题模型里的 RecordItem 已经加载到内存直接删除会破坏行索引。SQLite 中数据已被删除如果用户执行刷新操作重新拉取下一页游标可能指向一个已不存在的 id但并不影响查询结果。处理策略是删除操作直接从模型移除对应行并同步执行数据库 DELETE。注意不要让正在执行的 FetchPageTask 和删除操作并发修改同一个列表区域。可以在主线程中统一串行化这些操作将删除请求和查询请求都通过同一个 QThreadPool 投递但控制和查询任务的执行顺序。更稳妥的做法是给模型增加一个根据 id 删除记录的方法void CursorPagingModel::removeItemById(qint64 id) { for (int i 0; i m_items.size(); i) { if (m_items.at(i).id id) { beginRemoveRows(QModelIndex(), i, i); m_items.removeAt(i); endRemoveRows(); return; } } }删除数据库记录的操作应该在后台线程执行完成后回传 UI 线程再调用 removeItemById。如果删除顺序反了先刷新再删除界面会出现短暂的数据不一致。4.8 插入操作的游标刷新如果用户在当前列表末尾追加了一条新记录而且新记录的 event_time 比当前最后一条还大那么下一页游标不会受影响加载更多时可以正常获取到它。但如果插入了 event_time 较小或介于当前游标之前的数据按当前游标继续往下加载时这条新插入的数据不会出现在列表中。这是游标分页的特性不是 bug。如果业务需要让用户立刻看到插入后的最新数据可以提供一个刷新到游标的操作重新从数据库读取当前游标之前的数据将模型整体替换或插入到正确位置。在千万级数据下这种整体替换成本较高建议只在用户点击刷新按钮时执行不要在每次 scroll 到顶部时自动执行。5. 索引优化与 EXPLAIN 验证代码写完之后很多人运行起来发现仍然慢这是最值得排查的环节。游标分页要真正流畅必须保证 SQLite 使用了正确的索引。5.1 用 EXPLAIN QUERY PLAN 检查是否命中索引在 Qt 中可以直接执行以下 SQLEXPLAIN QUERY PLAN SELECT id, event_time, event_type, device_id, payload FROM records WHERE (event_time ?) OR (event_time ? AND id ?) ORDER BY event_time, id LIMIT 20;输出通常会显示类似于SEARCH records USING INDEX idx_records_device_time (event_time? AND event_time?)如果输出是 SCAN records说明查询计划是全表扫描。这种情况下无论 SQL 写得多好数据量上去了都会卡顿。重点验证以下几条查询查询预期查询计划不理想的情况首屏查询无 WHERE使用索引排序避免临时文件SCAN 全表并用临时文件排序下一页查询带游标使用索引范围扫描全表扫描或多次回表按 device_id 过滤后分页使用联合索引只用了部分索引仍然全表扫描5.2 OR 条件可能导致的索引退化前文示例的 WHERE 条件是WHERE (event_time ?) OR (event_time ? AND id ?)SQLite 的查询优化器在遇到 OR 条件时可能不会走最优索引尤其是在复合索引 (event_time, id) 上它需要做多次索引查找再合并。实际测试中这种写法在千万级数据下可能仍能达到毫秒级但为了更保险有两种优化方式方式一改成 UNION ALL 两次查询。SELECT * FROM ( SELECT id, event_time FROM records WHERE event_time ? UNION ALL SELECT id, event_time FROM records WHERE event_time ? AND id ? ) ORDER BY event_time, id LIMIT 20;方式二使用 SQLite 支持的行值比较。SELECT id, event_time FROM records WHERE (event_time, id) (?, ?) ORDER BY event_time, id LIMIT 20;行值比较在 SQLite 3.15 之后可用。如果目标运行环境较老可以用方式一。方式二的可读性最好而且更符合游标分页的逻辑。5.3 联合索引的列顺序游标分页本质上是按条件过滤再按顺序取一段。索引列的顺序要同时服务 WHERE 和 ORDER BY。如果业务场景是按设备查历史记录并翻页那查询条件通常是WHERE device_id dev-3 ORDER BY event_time, id LIMIT 20最优索引是 (device_id, event_time, id)。理由device_id 用于等值过滤。event_time 和 id 用于排序和游标比较。如果索引是 (event_time, id, device_id)SQLite 在过滤 device_id 时无法高效利用因为 event_time 是范围条件后面带的 id 和 device_id 不能独立用于过滤。实际项目中可以先按最常见的查询条件建索引。如果存在多个查询模式可以建多个索引但不要盲目加索引因为每个索引都会拖慢写入速度。5.4 写入性能的权衡千万级数据场景下每次 INSERT 都要更新所有相关索引。索引越多写入越慢。这里要做权衡如果业务主要是写入日志、查询较少索引控制在 1 到 2 个。如果业务查询模式非常多比如按设备、按时间、按类型可以提供不超过 4 个索引多余的查询走内存过滤。如果查询条件组合复杂优先保证等值过滤字段在索引左侧。可以在测试环境中分别记录不同索引数量下的写入耗时索引数量插入 100 万行耗时含事务典型查询耗时按游标翻页0约 8 秒全表扫描不推荐1id 主键约 12 秒按时间排序仍可能慢2id event_time约 18 秒按时间游标翻页毫秒级3id event_time device_id约 25 秒按设备分页毫秒级以上数据只是示意用于说明趋势不同磁盘和 SQLite 编译选项差异很大。但结论是通用的索引数量和写入速度负相关和查询速度正相关要按业务使用频率取舍。6. 运行验证与性能观察代码写完后不能只看能加载出数据就认为完成了。要按这个顺序验证性能、正确性和稳定性。6.1 首屏加载验证启动程序后观察第一屏出现的时间。如果首屏超过 200ms检查是否每次启动都执行了 COUNT(*) 或其他大查询。是否在打开界面时一次性加载了大量数据到模型。是否在 QTableView 中设置了过多的列、过大的字体、或启用了不必要的排序代理。预期首屏只执行一条 select返回 20 到 50 行数据耗时应该在 10ms 左右。如果首屏需要创建复杂委托或大尺寸缩略图这一部分可能成为新的瓶颈。6.2 滚动加载验证快速拖动滚动条到列表末尾观察UI 是否一直保持可交互窗口标题栏是否出现未响应。每次滚动到底部时模型行数是否增加新增行是否能正常显示。滚动过程中 QTableView 的 item 绘制是否模糊或闪烁。用 Qt Creator 的 Profiler 或外部工具录制 CPU 时间检查 fetchPage 的耗时。如果单次 fetchPage 超过 50ms需要排查索引是否命中、SQLite 是否编译为线程安全模式、页面是否因为设置了过大的 LIMIT 一次取回几千行。6.3 CRUD 正确性验证对增删改做针对性测试删除当前列表中的某一行确认数据库和模型同步删除翻页时不会再次出现。更新某一行数据确认模型中的显示和数据库一致。插入一条数据确认通过刷新可以看到并且不影响当前游标的继续加载。一个容易忽略的问题是SQLite 默认在 WAL 模式下如果工作线程持有只读事务其他线程的写操作可能暂时不可见。验证时要确认事务被正确提交或回滚否则会出现明明插入了界面查不到的现象。6.4 内存增长观察游标分页虽然避免了全量加载但用户不断往下滚动模型中的 m_items 会持续增长。如果用户翻了 100 万行内存中就会积累 100 万行的记录。这是游标分页本身无法避免的代价。如果内存增长不可接受有两种处理方式限制模型最大缓存行数比如只保留最近 2000 行超出部分从头部移除。使用虚拟化列表仅保留可视区域和上下各若干行通过模型 data() 方法直接查询数据库。这种方案更复杂但在超大量数据浏览场景中是最终方向。在千万级数据下如果只做顺序浏览建议直接接受模型缓存方案因为它的实现简单、稳定性高如果真的需要长时间浏览大量数据再考虑虚拟化。7. 常见问题排查从现象到根因这一节列出在实际项目中最高频的几个问题按照现象、原因、检查方式、解决方案的顺序整理。7.1 翻页变慢越往后越明显现象前几页很快翻到几十页之后开始卡顿耗时明显增长。原因仍然在使用 OFFSET 分页或者游标分页的 WHERE 条件没有命中索引。检查方式EXPLAIN QUERY PLAN SELECT id, event_time FROM records WHERE event_time 1000000 ORDER BY event_time, id LIMIT 20;如果结果是 SCAN说明索引没有建立或没有被使用。检查索引是否存在PRAGMA index_list(records);解决方式改为游标分页确认 WHERE 条件和 ORDER BY 字段在同一个联合索引中。如果确实必须支持跳转到第 N 页考虑用游标分页 估算页数的折中方案。7.2 窗口在加载数据时无响应现象点击按钮或滚动到底部后窗口标题栏出现未响应几秒后恢复。原因数据库查询或批量 UI 刷新在主线程执行。检查方式在 Qt Creator 中切换到 Debug 模式暂停程序查看调用栈。如果当前线程是主线程调用栈中有 QSqlQuery::exec() 或 QString 的大量拼接操作说明数据库操作阻塞了 UI。解决方式把数据库查询移到 QRunnable 或独立 QThread 中执行通过信号或 lambda 回传 UI 线程。UI 刷新时使用 beginInsertRows/endInsertRows 或 setData 局部刷新不要调用 reset model。7.3 插入数据非常慢尤其是批量插入现象单条 INSERT 很快但批量插入 10 万条时耗时很长。原因每条 INSERT 都自动提交一次事务每次提交都要同步磁盘。解决方式显式使用事务分批提交。在 Qt 中调用 db.transaction() 和 db.commit()。测试 5000 条一批、10000 条一批、50000 条一批找到当前机器上的最优批大小。同时确认是否创建了过多索引索引不仅影响查询也影响写入。7.4 QSqlDatabase: QSQLITE driver not loaded现象程序启动时报错无法打开 SQLite 数据库。原因Qt 的 SQL 插件没有部署到可执行文件目录或发布时没有包含 sqldrivers 文件夹。检查方式在 Qt 安装目录中查找 sqldrivers/qsqlite.dll 或 libqsqlite.so。检查运行目录下是否存在 sqldrivers 目录。在 main 函数中输出 QSqlDatabase::drivers() 列表确认 QSQLITE 是否存在。解决方式发布时将 Qt 的 sqldrivers 插件目录复制到可执行文件同级目录。注意插件目录的路径和 Qt 版本必须匹配。7.5 游标分页出现重复数据或丢数据现象连续翻页时某一行重复出现或者某些行被跳过。原因游标字段不唯一。如果只用 event_time 作为游标而 event_time 存在大量重复值那么 SQLite 在 LIMIT 边界上可能返回之前已处理过的记录。解决方式游标必须包含唯一字段通常用 (event_time, id) 组合id 必须是主键或唯一索引。如果业务排序字段就是 id直接用 id 作为游标最简单。7.6 排序字段没有索引时出现临时文件现象查询耗时不稳定有时 10ms有时 500msCPU 和磁盘 IO 飙升。原因SQLite 在排序时无法使用索引会在临时文件中做归并排序。检查方式打开 temp_store 设置或者观察系统临时目录下是否有大量大文件生成。解决方式为排序字段创建合适的索引或者尽量将排序字段限制为单列和唯一列。如果排序字段本身是高基数且查询频率高索引的收益非常明显。8. 从千万级到更大数据量的扩展方向游标分页在千万级数据下已经能解决大部分桌面应用的场景。但如果数据量继续增长到亿级或者查询模式更加复杂可以考虑以下扩展方向。8.1 数据分区与分表SQLite 本身不提供内置分区表但可以通过按时间建表的方式手动分区。比如按月建表CREATE TABLE records_202501 (...); CREATE TABLE records_202502 (...);查询时根据用户选择的时间范围确定查询哪几个表。这种方案在 SQLite 中很常见适用于按时间归档、历史数据很少修改的场景。分区后游标分页的跨表查询变复杂需要用 UNION ALL 或应用层合并。如果业务查询范围通常在一个月内收益非常明显。8.2 使用 WAL 模式和只读连接WAL 模式允许多个读操作与一个写操作并发执行。在桌面应用中UI 层的滚动加载只读查询不会阻塞后台同步线程的写操作这是很实用的优化。在 WAL 模式下工作线程可以使用只读连接QSqlDatabase db QSqlDatabase::addDatabase(QSQLITE, readonly_conn); db.setDatabaseName(dbPath); db.setConnectOptions(QSQLITE_OPEN_READONLY); db.open();只读连接不会持有写锁不会干扰其他线程的 INSERT 操作。这个方式对UI 查询和后台数据导入并行的场景特别有用。8.3 引入内存索引或缓存层如果 SQLite 查询在亿级数据下已经没有办法进一步提升可以在 Qt 应用层引入内存缓存。常用的做法对查询结果建立游标到行号的映射快速响应用户的回到上一页操作。对最近查询的热数据在内存中保存一份后续查询先查内存缓存。使用 QCache 管理固定长度的缓存对象避免内存膨胀。这类缓存的实现要谨慎核心是保持数据库才是权威数据源内存缓存只是加速层的原则。缓存不一致时至少需要提供刷新页面或清空缓存的操作入口。8.4 深分页与跳页的折中方案如果产品确实需要跳页而数据量又是千万级纯 OFFSET 方案不可接受。可以设计为使用游标分页支持上一页、下一页、滚动加载。提供输入页码跳转功能但跳转时先用 COUNT(*) 估算总行数然后执行一次 WHERE ORDER BY 计算起始游标。或者提供跳到最早/最近按钮直接计算首尾游标。这种方案在绝大多数业务场景中已经足够。不要轻易采用 OFFSET 搭配大 LIMIT 的方案那会导致深分页时 SQLite 大量扫描索引。9. 最佳实践清单与工程建议最后整理一份可以在实际项目中直接使用的实践清单按开发流程排列。9.1 数据库设计阶段表必须有明确的主键通常使用 INTEGER PRIMARY KEY AUTOINCREMENT。业务排序字段如果不是主键要为过滤字段 排序字段 主键建立联合索引。索引不是越多越好写入频繁的表控制在 2 到 3 个索引。SQLite 数据库文件放在用户数据目录不要放在程序安装目录避免权限问题。明确 SQLite 版本行值比较、UPSERT 等语法有版本要求。9.2 UI 与线程设计阶段所有可能耗时的数据库操作都放到工作线程UI 线程只做轻量展示。滚动加载使用 QTimer 做节流避免快速滚动时产生大量查询。模型必须使用 beginInsertRows/endInsertRows 或 beginResetModel/endResetModel 维护视图状态。不要一次性向 QTableWidget 插入大量 Item优先使用 Model/View 架构。9.3 查询与分页设计阶段首选游标分页条件使用 (排序字段) 或 (排序字段, 唯一字段) 组合。游标不能用浮点数或易变字段使用自增主键或 immutable 时间戳。每一页的 LIMIT 控制在 50 到 200 行之间太大没有意义太小查询次数过多。用 EXPLAIN QUERY PLAN 验证索引不要凭感觉。在查询接口中固定返回顺序ORDER BY 必须显式写出不要依赖数据库默认顺序。翻页后的数据修改要同步处理模型缓存和数据库避免界面与库不一致。9.4 发布与部署阶段确认发布目录包含 sqldrivers 插件。如果使用第三方 SQLite 编译版本确认 Qt 默认 SQLite 插件的行为差异。生产环境开启 WAL并配置合理的 synchronous 和 cache_size。定期执行 VACUUM 或 incremental_vacuum回收碎片空间。日志记录数据库连接失败、查询失败和耗时异常方便用户反馈问题时定位。9.5 更适合新手的练习路径如果之前没有接触过 Qt SQLite 的分页优化可以从以下练习开始先用原生 SQL 在 DB Browser for SQLite 中手动执行游标分页语句确认索引和结果集正确。用 Qt 写一个没有 UI 的命令行版本验证 fetchPage 和游标推进。将命令行版本改造成 QAbstractTableModel QTableView验证滚动加载。加入 QRunnable 异步查询对比改造前后的 UI 响应性。加入索引和 EXPLAIN 验证观察查询计划的变化。最后再加增删改同步和常见异常处理。这套路径的好处是每一步都能独立验证不容易出现代码写了很多但不知道哪个环节出了问题的情况。10. 总结Qt SQLite 的千万级数据 CRUD 并不是一个需要用重型数据库解决的问题。通过游标分页代替 OFFSET 分页配合合理索引和线程分离完全可以在桌面端获得流畅的体验。核心原则是查询永远只取需要的数据耗时操作永远不阻塞 UI 线程模型更新始终通过 Qt 的模型/视图通知机制。只要这三条做到位千万级数据量下的列表浏览、翻页加载和增删改都可以保持稳定响应。 Qt+SQLite千万级数据流畅CRUD：游标分页与线程优化实战
在实际的 Qt 桌面应用开发中SQLite 是最常见、最省事的内嵌式数据库之一部署简单不需要独立服务进程。但当单表数据量达到千万级之后问题就会变得非常具体查询变慢、分页跳页卡顿、批量写入时界面僵住、滚动列表时 CPU 占用飙升。很多人第一反应是换 PostgreSQL或换 MySQL但对客户端应用来说这并不现实——交付物是一个桌面程序不能要求用户额外安装数据库服务。解决这个问题的关键并不在 SQLite 本身而在于使用方式。SQLite 在千万级数据下依然能保持不错的吞吐量真正拖垮体验的是那些未被优化的查询语句、错误的索引设计以及把耗时操作直接放在 UI 线程里的写法。本文会围绕 Qt 和 SQLite 的组合讲清楚一条完整的技术主线如何用游标分页替代传统 OFFSET 分页如何把查询放到底层线程并安全地回传界面如何设计索引和表结构让千万级数据的 CRUD 保持流畅。最终目标不是简单地能用而是让读者能照着一套可复现的工程方案逐步改造自己的项目彻底告别 UI 卡顿。1. 先理解 UI 卡顿的根源查询不是慢而是阻塞了正确的线程很多人在千万级 SQLite 数据下遇到界面卡顿第一反应是去优化 SQL结果发现 SQL 已经写得很简单了仍然卡。这里要先把问题的层次分清楚UI 卡顿通常不是查询本身慢到无法接受而是查询占用了不该占用的线程——UI 线程。1.1 为什么 Qt 窗口会在数据量大时无响应Qt 的界面事件循环运行在主线程所有绘制、鼠标点击、键盘输入、窗口消息都由主线程处理。如果主线程里执行了一段耗时操作比如一次全表扫描、一次大数据量的 QSqlQuery::exec()那么在执行完之前事件循环无法处理新的 UI 消息窗口就会表现为失去响应或卡住。SQLite 查询在数据量很小的时候几乎瞬时完成用户感知不到阻塞。但数据量到了千万级一次没有命中索引的查询可能需要几百毫秒甚至几秒如果有排序、有子查询、有 JOIN时间会更长。这段时间内主线程被占用用户拖动滚动条、点击按钮、输入文字都会无响应。实际项目里更隐蔽的情况是查询本身只用了 50 毫秒但要在界面上一次性创建几千个 QTableWidgetItem 并插入表格这一步在主线程里执行也会导致明显卡顿。也就是说卡顿既可能来自查询也可能来自 UI 控件的批量刷新。1.2 SQLite 在桌面应用中的角色定位SQLite 是一个文件型数据库读写都要经过文件系统。它天然不适合承担海量数据并发服务端的角色但在桌面应用中它是非常合理的持久化方案。千万级数据量对 SQLite 来说不是不可用而是要求开发者在访问模式上做约束。约束主要体现在三方面尽量避免大范围的无索引扫描尽量通过条件过滤缩小结果集。尽量避免一次性把大量数据加载到内存和 UI 控件中。尽量避免在主线程中执行任何可能耗时超过几十毫秒的数据库操作。这三个约束并非 SQLite 独有任何桌面应用搭配数据库都会遇到。但 SQLite 因为部署简单、常被拿来当轻量级存储用反而更容易被忽略这三条原则。很多人默认反正数据量不大结果数据涨到千万级之后才发现问题。1.3 分辨哪些操作会在 UI 线程执行在 Qt 中直接写在 QWidget 子类、QMainWindow 子类、或者由 UI 事件回调直接调用的数据库操作默认都在主线程执行。常见的高危写法有在按钮 clicked 槽函数里直接执行 QSqlQuery::exec()。在 QTableView 的数据模型 data() 方法里触发 SQL 查询。用 QSqlQueryModel 直接绑定大表并在界面打开时 setQuery(SELECT * FROM big_table)。在构造函数里做大量数据初始化。用 QTimer 在主线程定期轮询数据库。这些写法的共同问题是数据库操作和 UI 操作混在同一个线程里阻塞无法避免。要解决就必须拆开——数据库操作放到工作线程查询结果通过信号回传主线程再由主线程只刷新需要的部分界面。1.4 从减少工作量到错开工作位置解决 UI 卡顿有两条路缺一不可减少工作量通过索引、条件过滤、游标分页让单次查询只处理必要的数据而不是全表。错开工作位置把无法避免的耗时数据库操作放到非 UI 线程避免阻塞事件循环。只优化 SQL 不拆线程数据量继续增长后还是会卡只拆线程不优化 SQL内存和 CPU 消耗上去了滚动加载时的延迟也会变得很高。两类手段要配合使用本文后续的代码和实践都会围绕这两条线展开。2. 游标分页为什么比 OFFSET 分页更适合千万级数据SQLite 常见的分页写法是用 LIMIT 和 OFFSET比如SELECT * FROM records ORDER BY id LIMIT 20 OFFSET 0; SELECT * FROM records ORDER BY id LIMIT 20 OFFSET 20;这种写法在小数据量下没有问题但进入千万级之后OFFSET 越大查询越慢。原因很简单数据库要跳过 OFFSET 指定的行数才能返回目标数据跳过的过程仍然要扫描并丢弃这些行。OFFSET 等于 500 万时SQLite 实际上要扫描前 500 万行再返回第 500 万到第 500 万加 20 行而不仅仅是定位到第 500 万行。2.1 OFFSET 分页的深层次问题OFFSET 分页有三个问题在桌面应用中非常致命第一深分页性能退化。页数越靠后跳过的行越多查询耗时越长。用户翻到第 5000 页时一次翻页可能耗时数百毫秒甚至更久。第二数据变更导致分页结果不稳定。如果在翻页过程中有数据插入或删除基于 OFFSET 的分页会出现同一行重复出现或某一行被跳过的情况。桌面客户端经常需要离线缓存同步这种数据漂移问题很常见。第三OFFSET 分页无法与滚动加载很好地配合。因为每次滚动都需要知道当前已经加载到第几页然后计算新的 OFFSET。这个计算本身不难但深层页次的性能问题会一直存在。2.2 游标分页的基本原理游标分页Keyset Pagination不依赖 OFFSET而是依赖一个稳定、唯一、可排序的字段作为游标。每次查询时用上一次结果集最后一条记录的游标值作为查询条件获取它之后的 N 条记录。以自增主键 id 为例-- 第一页 SELECT * FROM records ORDER BY id LIMIT 20; -- 第二页以上一页最后一条记录的 id 为游标 SELECT * FROM records ORDER BY id WHERE id 20 LIMIT 20; -- 第三页 SELECT * FROM records ORDER BY id WHERE id 40 LIMIT 20;关键点在于WHERE id 上一页最后一条 id 这个条件在索引下是直接定位的不需要扫描之前的数据。无论当前游标在 100 还是 500 万查询耗时都只和要返回多少行有关和前面有多少行无关。这种分页方式有几个明显优点深分页性能稳定。查询条件简单可以复用联合索引。对新增数据的处理更稳定不会因为前面插入几行导致整个页次漂移。非常适合滚动加载更多这种交互模式。2.3 游标分页的适用边界游标分页不是银弹它有一个显著限制只能按顺序一页一页地翻不能直接跳到第 N 页。因为跳转需要知道第 N 页的起始游标值而这个值无法通过条件直接计算出来。如果产品需求允许只能上一页、下一页、滚动加载游标分页是最合适的。如果必须支持用户输入第 1000 页直接跳转那游标分页就不够用要做折中第一版先用 OFFSET 分页但加上 LIMIT 上限防止用户输入超大页数。或者提供一个跳转页的估算方案比如用 COUNT(*) 算总行数然后估算游标位置但这不是精确跳转。在 Qt 桌面客户端的常见场景中绝大多数列表、日志、历史记录、设备数据浏览都是顺序浏览下一页和滚动加载足够满足需求。游标分页完全能覆盖。2.4 SQLite 中游标分页的索引要求游标分页的查询要高效必须让 WHERE 条件和 ORDER BY 字段能命中同一个索引。如果游标字段是主键问题不大如果游标字段是普通字段需要建立合适的索引。典型的建表场景如下CREATE TABLE IF NOT EXISTS records ( id INTEGER PRIMARY KEY AUTOINCREMENT, device_id TEXT NOT NULL, event_time INTEGER NOT NULL, event_type INTEGER NOT NULL, payload TEXT, created_at INTEGER NOT NULL ); CREATE INDEX IF NOT EXISTS idx_records_device_time ON records(device_id, event_time, id);如果查询条件是 WHERE device_id ? ORDER BY event_time, id联合索引 (device_id, event_time, id) 就能同时服务过滤和排序。SQLite 可以在这个索引上直接按顺序定位游标而不需要回表扫描大量数据。需要说明的是SQLite 的 EXPLAIN QUERY PLAN 输出是验证索引是否生效的最直接方式。后续章节会具体演示怎么看。3. 环境准备与测试数据设计动手写代码之前先统一环境和数据结构。本文使用 Qt 6 与 SQLite 3 的组合实际项目如果还是 Qt 5.15主体代码差异不大但注意 QSqlQuery 的某些 API 细节和 CMake 配置要随版本调整。3.1 软件环境要求项目推荐版本或说明操作系统Windows 10/11、Ubuntu 20.04 及以上、macOS 均可Qt 版本Qt 5.15 或 Qt 6.2本文示例基于 Qt 6.5编译器MSVC 2019/2022、MinGW 11、Clang 均可构建工具CMake 3.16SQLite 驱动Qt SQL 模块自带的 QSQLITE 驱动SQLite 版本取决于 Qt 发行包一般 3.31支持 window function 和 UPSERT在 Qt 安装时确保选中了 Qt SQL 模块。Qt 的 SQLite 驱动默认编译在 Qt 内不需要单独安装 SQLite 动态库这一点比很多人想象的要省事。3.2 CMake 项目配置CMake 配置里要显式链接 Qt 的 Sql 和 Widgets 模块并开启 C17 支持。cmake_minimum_required(VERSION 3.16) project(CursorPaginationDemo VERSION 1.0 LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_AUTOMOC ON) find_package(Qt6 REQUIRED COMPONENTS Core Gui Widgets Sql) qt_add_executable(CursorPaginationDemo main.cpp MainWindow.cpp MainWindow.h RecordTable.cpp RecordTable.h DataGenerator.cpp DataGenerator.h ) target_link_libraries(CursorPaginationDemo PRIVATE Qt6::Core Qt6::Gui Qt6::Widgets Qt6::Sql )如果是 Qt 5将 qt_add_executable 换成 add_executable 即可链接库名改为 Qt5::Core 等。AUTOMOC 必须开启否则 Q_OBJECT 类无法生成元对象代码。3.3 构造千万级测试数据的策略测试千万级数据不建议在 UI 线程里一条一条插入那样会非常慢。推荐的方式是用 SQLite 的事务批量插入。在 Qt 中最直接的写法是void DataGenerator::generate(QSqlDatabase db, int totalRows, int batchSize) { db.transaction(); QSqlQuery query(db); query.prepare(INSERT INTO records(device_id, event_time, event_type, payload, created_at) VALUES (?, ?, ?, ?, ?)); for (int i 0; i totalRows; i) { query.bindValue(0, QString(dev-%1).arg(i % 100)); query.bindValue(1, QDateTime::currentMSecsSinceEpoch() - i * 1000); query.bindValue(2, i % 5); query.bindValue(3, QString(payload-%1).arg(i)); query.bindValue(4, QDateTime::currentMSecsSinceEpoch()); query.exec(); if (i % batchSize 0) { db.commit(); db.transaction(); } } db.commit(); }这里的 batchSize 建议取 5000 到 20000。事务可以显著减少磁盘 fsync 的次数批量提交能极大缩短整体插入时间。在没有实际验证之前不要轻易调整 SQLite 的 PRAGMA 参数比如 synchronous、journal_mode因为这些参数在异常断电场景下可能影响数据安全性。数据生成完以后最好用以下 SQL 快速验证行数和索引信息SELECT COUNT(*) FROM records; SELECT * FROM sqlite_master WHERE type index AND tbl_name records;如果 COUNT() 非常慢说明表结构和索引可能需要进一步优化。对于千万级 InnoDB 表COUNT() 也不是免费的但 SQLite 的 COUNT(*) 在这里更多用于验证目的不会频繁执行。3.4 初始化数据库连接数据库连接建议在独立的工作线程或应用初始化阶段创建不要每次查询都新建连接。Qt 中同一个 QSqlDatabase 连接可以被多个线程使用但必须注意一个连接同一时刻只能被一个线程使用跨线程共享时需要加锁或复用一个线程。QSqlDatabase DatabaseManager::openConnection(const QString dbPath) { QSqlDatabase db QSqlDatabase::addDatabase(QSQLITE, cursor_demo_conn); db.setDatabaseName(dbPath); if (!db.open()) { qCritical() open database failed: db.lastError().text(); return QSqlDatabase(); } QSqlQuery query(db); query.exec(PRAGMA journal_mode WAL;); query.exec(PRAGMA synchronous NORMAL;); query.exec(PRAGMA temp_store MEMORY;); query.exec(PRAGMA cache_size -64000;); // 64MB page cache return db; }WAL 模式在桌面应用中通常能显著提升并发读写性能。synchronous NORMAL 在 WAL 模式下是常见选择它减少了每次提交时的 fsync 次数同时崩溃恢复能力仍然可接受。cache_size 设为负数表示以 KB 为单位这里设置为 64MB适合缓存较多索引页和数据页。需要注意 addDatabase 的连接名必须唯一。如果反复调用 addDatabase 且不指定连接名Qt 会复用默认连接容易造成连接冲突。每次 addDatabase 使用不同的连接名用完之后用 QSqlDatabase::removeDatabase 清理这样可以避免连接泄漏。4. 核心代码用游标分页实现千万级 CRUD 的完整工程这一节是全文的核心。工程采用 Qt 的 Model/View 架构数据库层负责游标分页查询数据模型负责缓存当前页数据并暴露行数界面层通过 QTableView 展示。查询操作在 QThreadPool 或独立工作线程中执行结果通过信号回传到 UI 线程。4.1 项目文件结构为了清晰将项目按职责拆成以下几个文件CursorPaginationDemo/ ├── main.cpp ├── MainWindow.h / MainWindow.cpp ├── DatabaseManager.h / DatabaseManager.cpp ├── CursorPagingModel.h / CursorPagingModel.cpp ├── DataGenerator.h / DataGenerator.cpp └── CMakeLists.txtDatabaseManager 负责数据库连接和查询执行。CursorPagingModel 继承 QAbstractTableModel负责向 QTableView 提供数据。DataGenerator 负责生成测试数据。MainWindow 负责组装界面和触发加载更多。4.2 定义游标结构体游标本质上就是上一页最后一条记录的位置信息。在 SQLite 中如果排序字段是自增主键 id一个 qint64 足够。但很多业务表需要按时间排序而时间可能重复所以游标要包含多个字段且最后一个字段必须是唯一字段。struct Cursor { qint64 eventTime 0; qint64 id 0; bool isNull() const { return id 0 eventTime 0; } QString toWhereClause() const { // 继续扩展时可以改成参数绑定形式 return QString((event_time %1) OR (event_time %1 AND id %2)) .arg(eventTime) .arg(id); } };如果按 event_time 排序但 event_time 有大量重复值那么只用 event_time 做游标会导致数据错乱。解决方法就是 (event_time, id) 组合游标先按时间比时间相同再用 id 比。id 是主键本身唯一所以这种组合一定稳定。更高效的做法是直接构造一个复合比较表达式利用 SQLite 的行值比较语法。SQLite 3.15 支持WHERE (event_time, id) (?, ?) ORDER BY event_time, id这种写法可以对多列索引做更准确的定位但可读性不如 OR 写法。为了保险起见先用 OR 写法演示原理生产环境如果确认 SQLite 版本支持行值比较可以切换到行值形式。4.3 数据库查询接口数据库查询层使用 QSqlQuery 绑定参数。核心是 fetchPage 函数它接收一个已初始化的游标和每页条数返回本页数据列表和下一页游标。struct RecordItem { qint64 id; qint64 eventTime; int eventType; QString deviceId; QString payload; }; struct PageResult { QVectorRecordItem items; Cursor nextCursor; }; class DatabaseManager { public: static PageResult fetchPage(const QSqlDatabase db, const Cursor cursor, int pageSize); }; PageResult DatabaseManager::fetchPage(const QSqlDatabase db, const Cursor cursor, int pageSize) { PageResult result; QString sql SELECT id, event_time, event_type, device_id, payload FROM records ; if (!cursor.isNull()) { sql WHERE (event_time ?) OR (event_time ? AND id ?) ; } sql ORDER BY event_time, id LIMIT ?; QSqlQuery query(db); query.prepare(sql); if (!cursor.isNull()) { query.bindValue(0, cursor.eventTime); query.bindValue(1, cursor.eventTime); query.bindValue(2, cursor.id); query.bindValue(3, pageSize); } else { query.bindValue(0, pageSize); } if (!query.exec()) { qWarning() fetchPage failed: query.lastError().text(); return result; } while (query.next()) { RecordItem item; item.id query.value(0).toLongLong(); item.eventTime query.value(1).toLongLong(); item.eventType query.value(2).toInt(); item.deviceId query.value(3).toString(); item.payload query.value(4).toString(); result.items.push_back(item); result.nextCursor.eventTime item.eventTime; result.nextCursor.id item.id; } // 如果一页没有取满说明已经到末尾 if (result.items.size() pageSize) { result.nextCursor Cursor(); // 空游标表示没有下一页 } return result; }这里要重点解释首屏查询时 cursor 为空SQL 不加 WHERE直接按 event_time, id ORDER BY LIMIT取第一页。后续加载时游标已经是上一页最后一条记录WHERE 条件只返回比最后一条记录更大的数据。每次翻页最多扫描 pageSize 条数据加上索引定位的消耗不会因为总量千万级而变慢。如果本页不足 pageSize说明数据库已经没有更多数据将 nextCursor 置空前端可以停止继续加载。4.4 数据模型层缓存当前页并快速响应 UICursorPagingModel 继承 QAbstractTableModel。它不需要一次加载全部数据只需要维护两个区域当前已加载的数据集合和一个加载中的状态标志。class CursorPagingModel : public QAbstractTableModel { Q_OBJECT public: explicit CursorPagingModel(QObject *parent nullptr); int rowCount(const QModelIndex parent QModelIndex()) const override; int columnCount(const QModelIndex parent QModelIndex()) const override; QVariant data(const QModelIndex index, int role Qt::DisplayRole) const override; QVariant headerData(int section, Qt::Orientation orientation, int role) const override; public slots: void appendPage(const QVectorRecordItem items); private: QVectorRecordItem m_items; }; int CursorPagingModel::rowCount(const QModelIndex parent) const { if (parent.isValid()) { return 0; } return m_items.size(); } int CursorPagingModel::columnCount(const QModelIndex parent) const { if (parent.isValid()) { return 0; } return 5; } QVariant CursorPagingModel::data(const QModelIndex index, int role) const { if (!index.isValid() || index.row() 0 || index.row() m_items.size()) { return QVariant(); } const RecordItem item m_items.at(index.row()); if (role Qt::DisplayRole) { switch (index.column()) { case 0: return item.id; case 1: return QDateTime::fromMSecsSinceEpoch(item.eventTime).toString(yyyy-MM-dd HH:mm:ss); case 2: return item.eventType; case 3: return item.deviceId; case 4: return item.payload; default: return QVariant(); } } return QVariant(); } void CursorPagingModel::appendPage(const QVectorRecordItem items) { if (items.isEmpty()) { return; } int first m_items.size(); int last first items.size() - 1; beginInsertRows(QModelIndex(), first, last); m_items items; endInsertRows(); }这里最关键的是 appendPage 中的 beginInsertRows/endInsertRows 调用。只有通过这对函数通知视图QTableView 才会局部刷新新增行而不是把整个视图重新加载一遍。如果这里忘掉 begin/end 调用或者用 qDeleteAll 之类的方式手动刷新UI 仍然会卡顿。4.5 工作线程与界面线程的协作查询不能放到模型里直接调用要放到线程池中执行。Qt 提供了多种异步方案比如 QThread、QtConcurrent、QThreadPool QRunnable。这里用 QThreadPool QRunnable 作为示例因为它的生命周期管理更简单适合高频次小任务。定义异步任务class FetchPageTask : public QRunnable { public: FetchPageTask(const QSqlDatabase db, const Cursor cursor, int pageSize, QObject *receiver, std::functionvoid(const PageResult ) callback) : m_db(db) , m_cursor(cursor) , m_pageSize(pageSize) , m_receiver(receiver) , m_callback(std::move(callback)) { setAutoDelete(true); } void run() override { PageResult result DatabaseManager::fetchPage(m_db, m_cursor, m_pageSize); // 回调到 UI 线程 if (m_receiver) { QMetaObject::invokeMethod(m_receiver, [this, result]() { m_callback(result); }, Qt::QueuedConnection); } } private: QSqlDatabase m_db; Cursor m_cursor; int m_pageSize; QObject *m_receiver; std::functionvoid(const PageResult ) m_callback; };在实际工程里QRunnable 内部持有 QSqlDatabase 会有连接线程归属的问题。更稳妥的方式是维护一个专门的工作线程在该线程中创建数据库连接然后所有查询都投递到这个线程中执行。用 QThreadPool 时如果多个任务共享同一个 QSqlDatabase 连接必须加锁否则 SQLite 驱动会报错或者产生未定义行为。一个更简单的方案是每个任务自己打开一个只读连接void FetchPageTask::run() override { QSqlDatabase taskDb QSqlDatabase::addDatabase(QSQLITE, QString(task_conn_%1).arg(reinterpret_castquintptr(QThread::currentThread()))); taskDb.setDatabaseName(m_dbPath); taskDb.open(); PageResult result DatabaseManager::fetchPage(taskDb, m_cursor, m_pageSize); QMetaObject::invokeMethod(m_receiver, [this, result]() { m_callback(result); }, Qt::QueuedConnection); taskDb.close(); QSqlDatabase::removeDatabase(taskDb.connectionName()); }这种方式在每次滚动加载时新建和关闭连接对 SQLite 来说成本不高因为打开文件本身通常只有几十微秒到几百微秒。但要注意连接名不能重复否则 addDatabase 会复用已有连接。使用当前线程地址作为连接名的一部分可以避免冲突。4.6 UI 层的滚动加载触发MainWindow 中监听 QTableView 的垂直滚动条当滚动条接近底部时触发下一页加载。这里最常用的方式是用一个 QTimer 做节流避免快速滚动时连续发出大量查询请求。void MainWindow::setupUi() { m_tableView new QTableView(this); m_model new CursorPagingModel(this); m_tableView-setModel(m_model); setCentralWidget(m_tableView); connect(m_tableView-verticalScrollBar(), QScrollBar::valueChanged, this, MainWindow::onScrollBarChanged); m_throttleTimer new QTimer(this); m_throttleTimer-setInterval(150); m_throttleTimer-setSingleShot(true); connect(m_throttleTimer, QTimer::timeout, this, MainWindow::loadNextPage); // 启动时加载第一页 m_cursor Cursor(); loadNextPage(); } void MainWindow::onScrollBarChanged(int value) { QScrollBar *bar m_tableView-verticalScrollBar(); // 距离底部还剩 20% 时触发加载 if (bar-maximum() 0 value bar-maximum() * 0.8) { m_throttleTimer-start(); } } void MainWindow::loadNextPage() { if (m_loading) { return; } // 如果游标为空说明没有更多数据 if (m_cursor.isNull() m_model-rowCount() 0) { return; } m_loading true; // 这里把数据库路径传进去任务内部自建连接 QThreadPool::globalInstance()-start( new FetchPageTask(m_dbPath, m_model-rowCount() 0 ? m_cursor : Cursor(), m_pageSize, this, [this](const PageResult result) { m_model-appendPage(result.items); m_cursor result.nextCursor; m_loading false; if (result.items.isEmpty()) { qInfo() no more data; } }) ); }这段代码里要把第一次加载和后续加载区别对待。第一次加载时 m_model-rowCount() 为 0游标为空SQL 不带 WHERE 条件直接从头取第一页。后续加载时使用上一轮的 nextCursor。如果数据已经全部加载完nextCursor 被置空loadNextPage 直接返回不再发请求。使用 QTimer 做节流是必要的。快速拖动滚动条时valueChanged 会连续触发多次如果每次都去读数据库既造成不必要的 I/O又可能导致 UI 抖动。150ms 的单次计时器可以保证在用户停止滚动后再发起查询。4.7 更新操作和删除操作对游标的影响游标分页下还需要考虑数据更新和删除对分页的影响。如果用户正在浏览列表另一条线程删除了当前已经加载页的某条数据这会带来两个问题模型里的 RecordItem 已经加载到内存直接删除会破坏行索引。SQLite 中数据已被删除如果用户执行刷新操作重新拉取下一页游标可能指向一个已不存在的 id但并不影响查询结果。处理策略是删除操作直接从模型移除对应行并同步执行数据库 DELETE。注意不要让正在执行的 FetchPageTask 和删除操作并发修改同一个列表区域。可以在主线程中统一串行化这些操作将删除请求和查询请求都通过同一个 QThreadPool 投递但控制和查询任务的执行顺序。更稳妥的做法是给模型增加一个根据 id 删除记录的方法void CursorPagingModel::removeItemById(qint64 id) { for (int i 0; i m_items.size(); i) { if (m_items.at(i).id id) { beginRemoveRows(QModelIndex(), i, i); m_items.removeAt(i); endRemoveRows(); return; } } }删除数据库记录的操作应该在后台线程执行完成后回传 UI 线程再调用 removeItemById。如果删除顺序反了先刷新再删除界面会出现短暂的数据不一致。4.8 插入操作的游标刷新如果用户在当前列表末尾追加了一条新记录而且新记录的 event_time 比当前最后一条还大那么下一页游标不会受影响加载更多时可以正常获取到它。但如果插入了 event_time 较小或介于当前游标之前的数据按当前游标继续往下加载时这条新插入的数据不会出现在列表中。这是游标分页的特性不是 bug。如果业务需要让用户立刻看到插入后的最新数据可以提供一个刷新到游标的操作重新从数据库读取当前游标之前的数据将模型整体替换或插入到正确位置。在千万级数据下这种整体替换成本较高建议只在用户点击刷新按钮时执行不要在每次 scroll 到顶部时自动执行。5. 索引优化与 EXPLAIN 验证代码写完之后很多人运行起来发现仍然慢这是最值得排查的环节。游标分页要真正流畅必须保证 SQLite 使用了正确的索引。5.1 用 EXPLAIN QUERY PLAN 检查是否命中索引在 Qt 中可以直接执行以下 SQLEXPLAIN QUERY PLAN SELECT id, event_time, event_type, device_id, payload FROM records WHERE (event_time ?) OR (event_time ? AND id ?) ORDER BY event_time, id LIMIT 20;输出通常会显示类似于SEARCH records USING INDEX idx_records_device_time (event_time? AND event_time?)如果输出是 SCAN records说明查询计划是全表扫描。这种情况下无论 SQL 写得多好数据量上去了都会卡顿。重点验证以下几条查询查询预期查询计划不理想的情况首屏查询无 WHERE使用索引排序避免临时文件SCAN 全表并用临时文件排序下一页查询带游标使用索引范围扫描全表扫描或多次回表按 device_id 过滤后分页使用联合索引只用了部分索引仍然全表扫描5.2 OR 条件可能导致的索引退化前文示例的 WHERE 条件是WHERE (event_time ?) OR (event_time ? AND id ?)SQLite 的查询优化器在遇到 OR 条件时可能不会走最优索引尤其是在复合索引 (event_time, id) 上它需要做多次索引查找再合并。实际测试中这种写法在千万级数据下可能仍能达到毫秒级但为了更保险有两种优化方式方式一改成 UNION ALL 两次查询。SELECT * FROM ( SELECT id, event_time FROM records WHERE event_time ? UNION ALL SELECT id, event_time FROM records WHERE event_time ? AND id ? ) ORDER BY event_time, id LIMIT 20;方式二使用 SQLite 支持的行值比较。SELECT id, event_time FROM records WHERE (event_time, id) (?, ?) ORDER BY event_time, id LIMIT 20;行值比较在 SQLite 3.15 之后可用。如果目标运行环境较老可以用方式一。方式二的可读性最好而且更符合游标分页的逻辑。5.3 联合索引的列顺序游标分页本质上是按条件过滤再按顺序取一段。索引列的顺序要同时服务 WHERE 和 ORDER BY。如果业务场景是按设备查历史记录并翻页那查询条件通常是WHERE device_id dev-3 ORDER BY event_time, id LIMIT 20最优索引是 (device_id, event_time, id)。理由device_id 用于等值过滤。event_time 和 id 用于排序和游标比较。如果索引是 (event_time, id, device_id)SQLite 在过滤 device_id 时无法高效利用因为 event_time 是范围条件后面带的 id 和 device_id 不能独立用于过滤。实际项目中可以先按最常见的查询条件建索引。如果存在多个查询模式可以建多个索引但不要盲目加索引因为每个索引都会拖慢写入速度。5.4 写入性能的权衡千万级数据场景下每次 INSERT 都要更新所有相关索引。索引越多写入越慢。这里要做权衡如果业务主要是写入日志、查询较少索引控制在 1 到 2 个。如果业务查询模式非常多比如按设备、按时间、按类型可以提供不超过 4 个索引多余的查询走内存过滤。如果查询条件组合复杂优先保证等值过滤字段在索引左侧。可以在测试环境中分别记录不同索引数量下的写入耗时索引数量插入 100 万行耗时含事务典型查询耗时按游标翻页0约 8 秒全表扫描不推荐1id 主键约 12 秒按时间排序仍可能慢2id event_time约 18 秒按时间游标翻页毫秒级3id event_time device_id约 25 秒按设备分页毫秒级以上数据只是示意用于说明趋势不同磁盘和 SQLite 编译选项差异很大。但结论是通用的索引数量和写入速度负相关和查询速度正相关要按业务使用频率取舍。6. 运行验证与性能观察代码写完后不能只看能加载出数据就认为完成了。要按这个顺序验证性能、正确性和稳定性。6.1 首屏加载验证启动程序后观察第一屏出现的时间。如果首屏超过 200ms检查是否每次启动都执行了 COUNT(*) 或其他大查询。是否在打开界面时一次性加载了大量数据到模型。是否在 QTableView 中设置了过多的列、过大的字体、或启用了不必要的排序代理。预期首屏只执行一条 select返回 20 到 50 行数据耗时应该在 10ms 左右。如果首屏需要创建复杂委托或大尺寸缩略图这一部分可能成为新的瓶颈。6.2 滚动加载验证快速拖动滚动条到列表末尾观察UI 是否一直保持可交互窗口标题栏是否出现未响应。每次滚动到底部时模型行数是否增加新增行是否能正常显示。滚动过程中 QTableView 的 item 绘制是否模糊或闪烁。用 Qt Creator 的 Profiler 或外部工具录制 CPU 时间检查 fetchPage 的耗时。如果单次 fetchPage 超过 50ms需要排查索引是否命中、SQLite 是否编译为线程安全模式、页面是否因为设置了过大的 LIMIT 一次取回几千行。6.3 CRUD 正确性验证对增删改做针对性测试删除当前列表中的某一行确认数据库和模型同步删除翻页时不会再次出现。更新某一行数据确认模型中的显示和数据库一致。插入一条数据确认通过刷新可以看到并且不影响当前游标的继续加载。一个容易忽略的问题是SQLite 默认在 WAL 模式下如果工作线程持有只读事务其他线程的写操作可能暂时不可见。验证时要确认事务被正确提交或回滚否则会出现明明插入了界面查不到的现象。6.4 内存增长观察游标分页虽然避免了全量加载但用户不断往下滚动模型中的 m_items 会持续增长。如果用户翻了 100 万行内存中就会积累 100 万行的记录。这是游标分页本身无法避免的代价。如果内存增长不可接受有两种处理方式限制模型最大缓存行数比如只保留最近 2000 行超出部分从头部移除。使用虚拟化列表仅保留可视区域和上下各若干行通过模型 data() 方法直接查询数据库。这种方案更复杂但在超大量数据浏览场景中是最终方向。在千万级数据下如果只做顺序浏览建议直接接受模型缓存方案因为它的实现简单、稳定性高如果真的需要长时间浏览大量数据再考虑虚拟化。7. 常见问题排查从现象到根因这一节列出在实际项目中最高频的几个问题按照现象、原因、检查方式、解决方案的顺序整理。7.1 翻页变慢越往后越明显现象前几页很快翻到几十页之后开始卡顿耗时明显增长。原因仍然在使用 OFFSET 分页或者游标分页的 WHERE 条件没有命中索引。检查方式EXPLAIN QUERY PLAN SELECT id, event_time FROM records WHERE event_time 1000000 ORDER BY event_time, id LIMIT 20;如果结果是 SCAN说明索引没有建立或没有被使用。检查索引是否存在PRAGMA index_list(records);解决方式改为游标分页确认 WHERE 条件和 ORDER BY 字段在同一个联合索引中。如果确实必须支持跳转到第 N 页考虑用游标分页 估算页数的折中方案。7.2 窗口在加载数据时无响应现象点击按钮或滚动到底部后窗口标题栏出现未响应几秒后恢复。原因数据库查询或批量 UI 刷新在主线程执行。检查方式在 Qt Creator 中切换到 Debug 模式暂停程序查看调用栈。如果当前线程是主线程调用栈中有 QSqlQuery::exec() 或 QString 的大量拼接操作说明数据库操作阻塞了 UI。解决方式把数据库查询移到 QRunnable 或独立 QThread 中执行通过信号或 lambda 回传 UI 线程。UI 刷新时使用 beginInsertRows/endInsertRows 或 setData 局部刷新不要调用 reset model。7.3 插入数据非常慢尤其是批量插入现象单条 INSERT 很快但批量插入 10 万条时耗时很长。原因每条 INSERT 都自动提交一次事务每次提交都要同步磁盘。解决方式显式使用事务分批提交。在 Qt 中调用 db.transaction() 和 db.commit()。测试 5000 条一批、10000 条一批、50000 条一批找到当前机器上的最优批大小。同时确认是否创建了过多索引索引不仅影响查询也影响写入。7.4 QSqlDatabase: QSQLITE driver not loaded现象程序启动时报错无法打开 SQLite 数据库。原因Qt 的 SQL 插件没有部署到可执行文件目录或发布时没有包含 sqldrivers 文件夹。检查方式在 Qt 安装目录中查找 sqldrivers/qsqlite.dll 或 libqsqlite.so。检查运行目录下是否存在 sqldrivers 目录。在 main 函数中输出 QSqlDatabase::drivers() 列表确认 QSQLITE 是否存在。解决方式发布时将 Qt 的 sqldrivers 插件目录复制到可执行文件同级目录。注意插件目录的路径和 Qt 版本必须匹配。7.5 游标分页出现重复数据或丢数据现象连续翻页时某一行重复出现或者某些行被跳过。原因游标字段不唯一。如果只用 event_time 作为游标而 event_time 存在大量重复值那么 SQLite 在 LIMIT 边界上可能返回之前已处理过的记录。解决方式游标必须包含唯一字段通常用 (event_time, id) 组合id 必须是主键或唯一索引。如果业务排序字段就是 id直接用 id 作为游标最简单。7.6 排序字段没有索引时出现临时文件现象查询耗时不稳定有时 10ms有时 500msCPU 和磁盘 IO 飙升。原因SQLite 在排序时无法使用索引会在临时文件中做归并排序。检查方式打开 temp_store 设置或者观察系统临时目录下是否有大量大文件生成。解决方式为排序字段创建合适的索引或者尽量将排序字段限制为单列和唯一列。如果排序字段本身是高基数且查询频率高索引的收益非常明显。8. 从千万级到更大数据量的扩展方向游标分页在千万级数据下已经能解决大部分桌面应用的场景。但如果数据量继续增长到亿级或者查询模式更加复杂可以考虑以下扩展方向。8.1 数据分区与分表SQLite 本身不提供内置分区表但可以通过按时间建表的方式手动分区。比如按月建表CREATE TABLE records_202501 (...); CREATE TABLE records_202502 (...);查询时根据用户选择的时间范围确定查询哪几个表。这种方案在 SQLite 中很常见适用于按时间归档、历史数据很少修改的场景。分区后游标分页的跨表查询变复杂需要用 UNION ALL 或应用层合并。如果业务查询范围通常在一个月内收益非常明显。8.2 使用 WAL 模式和只读连接WAL 模式允许多个读操作与一个写操作并发执行。在桌面应用中UI 层的滚动加载只读查询不会阻塞后台同步线程的写操作这是很实用的优化。在 WAL 模式下工作线程可以使用只读连接QSqlDatabase db QSqlDatabase::addDatabase(QSQLITE, readonly_conn); db.setDatabaseName(dbPath); db.setConnectOptions(QSQLITE_OPEN_READONLY); db.open();只读连接不会持有写锁不会干扰其他线程的 INSERT 操作。这个方式对UI 查询和后台数据导入并行的场景特别有用。8.3 引入内存索引或缓存层如果 SQLite 查询在亿级数据下已经没有办法进一步提升可以在 Qt 应用层引入内存缓存。常用的做法对查询结果建立游标到行号的映射快速响应用户的回到上一页操作。对最近查询的热数据在内存中保存一份后续查询先查内存缓存。使用 QCache 管理固定长度的缓存对象避免内存膨胀。这类缓存的实现要谨慎核心是保持数据库才是权威数据源内存缓存只是加速层的原则。缓存不一致时至少需要提供刷新页面或清空缓存的操作入口。8.4 深分页与跳页的折中方案如果产品确实需要跳页而数据量又是千万级纯 OFFSET 方案不可接受。可以设计为使用游标分页支持上一页、下一页、滚动加载。提供输入页码跳转功能但跳转时先用 COUNT(*) 估算总行数然后执行一次 WHERE ORDER BY 计算起始游标。或者提供跳到最早/最近按钮直接计算首尾游标。这种方案在绝大多数业务场景中已经足够。不要轻易采用 OFFSET 搭配大 LIMIT 的方案那会导致深分页时 SQLite 大量扫描索引。9. 最佳实践清单与工程建议最后整理一份可以在实际项目中直接使用的实践清单按开发流程排列。9.1 数据库设计阶段表必须有明确的主键通常使用 INTEGER PRIMARY KEY AUTOINCREMENT。业务排序字段如果不是主键要为过滤字段 排序字段 主键建立联合索引。索引不是越多越好写入频繁的表控制在 2 到 3 个索引。SQLite 数据库文件放在用户数据目录不要放在程序安装目录避免权限问题。明确 SQLite 版本行值比较、UPSERT 等语法有版本要求。9.2 UI 与线程设计阶段所有可能耗时的数据库操作都放到工作线程UI 线程只做轻量展示。滚动加载使用 QTimer 做节流避免快速滚动时产生大量查询。模型必须使用 beginInsertRows/endInsertRows 或 beginResetModel/endResetModel 维护视图状态。不要一次性向 QTableWidget 插入大量 Item优先使用 Model/View 架构。9.3 查询与分页设计阶段首选游标分页条件使用 (排序字段) 或 (排序字段, 唯一字段) 组合。游标不能用浮点数或易变字段使用自增主键或 immutable 时间戳。每一页的 LIMIT 控制在 50 到 200 行之间太大没有意义太小查询次数过多。用 EXPLAIN QUERY PLAN 验证索引不要凭感觉。在查询接口中固定返回顺序ORDER BY 必须显式写出不要依赖数据库默认顺序。翻页后的数据修改要同步处理模型缓存和数据库避免界面与库不一致。9.4 发布与部署阶段确认发布目录包含 sqldrivers 插件。如果使用第三方 SQLite 编译版本确认 Qt 默认 SQLite 插件的行为差异。生产环境开启 WAL并配置合理的 synchronous 和 cache_size。定期执行 VACUUM 或 incremental_vacuum回收碎片空间。日志记录数据库连接失败、查询失败和耗时异常方便用户反馈问题时定位。9.5 更适合新手的练习路径如果之前没有接触过 Qt SQLite 的分页优化可以从以下练习开始先用原生 SQL 在 DB Browser for SQLite 中手动执行游标分页语句确认索引和结果集正确。用 Qt 写一个没有 UI 的命令行版本验证 fetchPage 和游标推进。将命令行版本改造成 QAbstractTableModel QTableView验证滚动加载。加入 QRunnable 异步查询对比改造前后的 UI 响应性。加入索引和 EXPLAIN 验证观察查询计划的变化。最后再加增删改同步和常见异常处理。这套路径的好处是每一步都能独立验证不容易出现代码写了很多但不知道哪个环节出了问题的情况。10. 总结Qt SQLite 的千万级数据 CRUD 并不是一个需要用重型数据库解决的问题。通过游标分页代替 OFFSET 分页配合合理索引和线程分离完全可以在桌面端获得流畅的体验。核心原则是查询永远只取需要的数据耗时操作永远不阻塞 UI 线程模型更新始终通过 Qt 的模型/视图通知机制。只要这三条做到位千万级数据量下的列表浏览、翻页加载和增删改都可以保持稳定响应。