NocoDB 性能优化实战4 步把百万行慢查询从秒级压到毫秒级【免费下载链接】nocodb A Free Self-hostable Airtable Alternative项目地址: https://gitcode.com/GitHub_Trending/no/nocodb运营周五下午拉出后台那张 80 万行的客户表导出按钮转了十几秒还没反应工单看板的筛选一改就要等半天。这多半不是机器慢而是 NocoDB 里的查询和连接配置在拖后腿。下面按先定位、再对症的思路把常见的 NocoDB 慢查询问题一次捋清。先判断卡在哪四条路径定位 NocoDB 慢查询动手之前先别急着加索引。打开监控面板看接口响应时间分布再配合慢查询日志一般能把问题归进四类连接耗尽连接池里的连接全被占着新请求只能干等、全表扫描执行计划里没有可用索引、OFFSET 分页拖慢页码越深越慢、缓存未命中元数据频繁回源数据库。判断路径大致是这四步看监控面板的响应时间分布。同一接口时快时慢、偶尔飙高多半是等待连接稳定地慢才是查询本身慢。挑一条慢查询看慢查询日志里的执行计划出现全表扫描字样就是索引没建对或没建。让操作的人复现一次翻到后面才卡页码越深响应越差基本可以锁定 OFFSET 分页。翻高峰期的超时日志如果出现等待连接的报错acquire timeout连接池就该扩容了。多数情况下四步走完瓶颈已经能归到一两类不用每样都改一遍。三个高频卡点的对症操作列表页越翻越慢怎么把 OFFSET 换成游标分页翻到第 100 页明显比第 1 页慢原因不复杂OFFSET 分页要先取出前 N 条再扔掉跳过的行数等于白干。换成游标分页后数据库只取上次最后一条之后的一页成本基本恒定-- 传统写法越深越慢 SELECT * FROM tickets ORDER BY id LIMIT 50 OFFSET 200000; -- 游标写法带上上一页最后一条的 id SELECT * FROM tickets WHERE id 200153 ORDER BY id LIMIT 50;NocoDB 的翻页逻辑最终都汇到查询构建器里改分页行为前可以先读一遍 查询构建器源码找到 limit/offset 的处理位置。列表视图里加一个加载下一页按钮配合上面这条写法翻多深都是同一个速度。多条件筛选一查就卡复合索引字段顺序怎么排筛选状态 负责人 时间范围就卡通常是缺一个复合索引或者字段顺序排反了。排布原则一句话选择性高的筛选字段放前面范围查询字段大于、小于、between放最后。前缀不匹配时整个索引会退化成只命中最左一列CREATE INDEX idx_ticket_assignee_priority_created ON tickets (assignee, priority, created_at);改完跑一次EXPLAIN确认走的是这个索引而不是全表扫描。如果加了时间范围后反而更慢先检查索引列的顺序对不对再怀疑索引本身。并发一上来就偶发超时连接池 max 该设多少高峰期隔几分钟蹦一次连接获取超时而 CPU 明明没打满说明连接池提前开好一批数据库连接反复用省掉反复建连的开销太小了。max 不是越大越好从 20 起步压测逐步加到 CPU 核心数的 2~4 倍再观察空闲超时 idleTimeout 给到 300000 毫秒左右常用连接不容易被回收拿连接等待上限 acquireTimeout 设 30000 毫秒超时报错会清晰得多{ max: 20, min: 5, idleTimeout: 300000, acquireTimeout: 30000 }改完压测一轮确认慢查询日志里等待连接的报错消失再往上加并发。一次真实调优复盘38 万行工单表某团队用 NocoDB 存客服工单38 万行时出现三个症状按状态 负责人筛选要 1.4 秒看板首屏加载 P95 到 2.8 秒高峰期偶发超时。处理过程就四步慢查询日志确认筛选走的是全表扫描补上 (assignee, priority, created_at) 复合索引列表翻页从 OFFSET 改成按上一页最后一条 id 往后取的游标分页连接池 max 从默认值调到 30idleTimeout 设为 300000压测复核慢查询日志里不再出现等待连接报错。优化后看板首屏加载 P95 从 2.8 秒降到 60 毫秒筛选耗时 1.4 秒降到 80 毫秒高峰期超时告警归零。全程没动应用代码只改了索引和查询参数。一页速查表现象、动作、关键参数问题现象首选动作关键参数/配置翻页越深越慢改游标分页上一页最后一条 id LIMIT多条件筛选卡顿建复合索引范围字段放最后EXPLAIN确认命中索引高峰偶发获取连接超时调大连接池max取 CPU 核数 2~4 倍idleTimeout300000同一查询时快时慢查元数据缓存命中率管理员后台清缓存后观察NocoDB 后续还在推列式存储和查询预编译大表聚合与报表类查询会再快一截可以先按上面的方法把现有环境调稳等特性落地后直接受益。【免费下载链接】nocodb A Free Self-hostable Airtable Alternative项目地址: https://gitcode.com/GitHub_Trending/no/nocodb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
NocoDB 性能优化实战：4 步把百万行慢查询从秒级压到毫秒级
NocoDB 性能优化实战4 步把百万行慢查询从秒级压到毫秒级【免费下载链接】nocodb A Free Self-hostable Airtable Alternative项目地址: https://gitcode.com/GitHub_Trending/no/nocodb运营周五下午拉出后台那张 80 万行的客户表导出按钮转了十几秒还没反应工单看板的筛选一改就要等半天。这多半不是机器慢而是 NocoDB 里的查询和连接配置在拖后腿。下面按先定位、再对症的思路把常见的 NocoDB 慢查询问题一次捋清。先判断卡在哪四条路径定位 NocoDB 慢查询动手之前先别急着加索引。打开监控面板看接口响应时间分布再配合慢查询日志一般能把问题归进四类连接耗尽连接池里的连接全被占着新请求只能干等、全表扫描执行计划里没有可用索引、OFFSET 分页拖慢页码越深越慢、缓存未命中元数据频繁回源数据库。判断路径大致是这四步看监控面板的响应时间分布。同一接口时快时慢、偶尔飙高多半是等待连接稳定地慢才是查询本身慢。挑一条慢查询看慢查询日志里的执行计划出现全表扫描字样就是索引没建对或没建。让操作的人复现一次翻到后面才卡页码越深响应越差基本可以锁定 OFFSET 分页。翻高峰期的超时日志如果出现等待连接的报错acquire timeout连接池就该扩容了。多数情况下四步走完瓶颈已经能归到一两类不用每样都改一遍。三个高频卡点的对症操作列表页越翻越慢怎么把 OFFSET 换成游标分页翻到第 100 页明显比第 1 页慢原因不复杂OFFSET 分页要先取出前 N 条再扔掉跳过的行数等于白干。换成游标分页后数据库只取上次最后一条之后的一页成本基本恒定-- 传统写法越深越慢 SELECT * FROM tickets ORDER BY id LIMIT 50 OFFSET 200000; -- 游标写法带上上一页最后一条的 id SELECT * FROM tickets WHERE id 200153 ORDER BY id LIMIT 50;NocoDB 的翻页逻辑最终都汇到查询构建器里改分页行为前可以先读一遍 查询构建器源码找到 limit/offset 的处理位置。列表视图里加一个加载下一页按钮配合上面这条写法翻多深都是同一个速度。多条件筛选一查就卡复合索引字段顺序怎么排筛选状态 负责人 时间范围就卡通常是缺一个复合索引或者字段顺序排反了。排布原则一句话选择性高的筛选字段放前面范围查询字段大于、小于、between放最后。前缀不匹配时整个索引会退化成只命中最左一列CREATE INDEX idx_ticket_assignee_priority_created ON tickets (assignee, priority, created_at);改完跑一次EXPLAIN确认走的是这个索引而不是全表扫描。如果加了时间范围后反而更慢先检查索引列的顺序对不对再怀疑索引本身。并发一上来就偶发超时连接池 max 该设多少高峰期隔几分钟蹦一次连接获取超时而 CPU 明明没打满说明连接池提前开好一批数据库连接反复用省掉反复建连的开销太小了。max 不是越大越好从 20 起步压测逐步加到 CPU 核心数的 2~4 倍再观察空闲超时 idleTimeout 给到 300000 毫秒左右常用连接不容易被回收拿连接等待上限 acquireTimeout 设 30000 毫秒超时报错会清晰得多{ max: 20, min: 5, idleTimeout: 300000, acquireTimeout: 30000 }改完压测一轮确认慢查询日志里等待连接的报错消失再往上加并发。一次真实调优复盘38 万行工单表某团队用 NocoDB 存客服工单38 万行时出现三个症状按状态 负责人筛选要 1.4 秒看板首屏加载 P95 到 2.8 秒高峰期偶发超时。处理过程就四步慢查询日志确认筛选走的是全表扫描补上 (assignee, priority, created_at) 复合索引列表翻页从 OFFSET 改成按上一页最后一条 id 往后取的游标分页连接池 max 从默认值调到 30idleTimeout 设为 300000压测复核慢查询日志里不再出现等待连接报错。优化后看板首屏加载 P95 从 2.8 秒降到 60 毫秒筛选耗时 1.4 秒降到 80 毫秒高峰期超时告警归零。全程没动应用代码只改了索引和查询参数。一页速查表现象、动作、关键参数问题现象首选动作关键参数/配置翻页越深越慢改游标分页上一页最后一条 id LIMIT多条件筛选卡顿建复合索引范围字段放最后EXPLAIN确认命中索引高峰偶发获取连接超时调大连接池max取 CPU 核数 2~4 倍idleTimeout300000同一查询时快时慢查元数据缓存命中率管理员后台清缓存后观察NocoDB 后续还在推列式存储和查询预编译大表聚合与报表类查询会再快一截可以先按上面的方法把现有环境调稳等特性落地后直接受益。【免费下载链接】nocodb A Free Self-hostable Airtable Alternative项目地址: https://gitcode.com/GitHub_Trending/no/nocodb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考