QGIS大栅格缩放卡顿：金字塔参数、重采样与排查实战

栅格数据一进 QGIS 就转圈，拖动一次地图要等十几秒，这种场面我见得太多了。前阵子帮一个做城市基础数据整理的团队看性能问题，他们手里一堆几万像素见方的正射影像，单个文件动辄十几 GB，加载进 QGIS 之后缩放像放幻灯片。排查下来，问题既不在电脑配置，也不在 QGIS 版本，而是QGIS 中的金字塔机制根本没被正确用起来——有的图层压根没建金字塔，有的建了但层数和重采样算法选错，还有的建成了外部.ovr却放在不生效的路径上。金字塔这个东西，说白了就是把一幅大图提前“复印”成好几份不同尺寸的小图，让你缩到很远的时候不必去读原始分辨率的数据。听上去简单，但真要做到“缩放丝滑、颜色不偏、文件不爆”，里头的参数选择、算法取舍、QGIS 端的配合设置，每一步都有坑。这篇就把我这些年踩过的、修过的、反复验证过的东西整理出来，从原理到参数计算再到完整实操流程，适合刚接触大栅格的新手，也适合已经在用 GDAL 做预处理、但总觉得效果差一口气的老手。

1. 金字塔到底在解决什么问题

1.1 从一次缩放卡顿说起：没有金字塔时 QGIS 在干什么

很多人以为 QGIS 显示一幅影像就是“把图片贴到屏幕上”，实际上完全不是。当你在画布上把地图缩到全国范围，而影像本身是 0.2 米分辨率的城市正射图时，画布可能只有 1500 像素宽，但 QGIS 需要算出这块画布覆盖的地理范围，然后让 GDAL 从源文件里按这个范围读取数据。如果没有金字塔，GDAL 只能从原始的 50000×40000 像素里，按一定的采样间隔去“跳着读”，读完之后再缩小到 1500 像素画出来。这个过程里，磁盘 I/O 的读取量是巨大的，因为 GeoTIFF 的像素是按行或按块顺序存放的，要跳着采样，往往意味着几乎要把整个文件扫一遍。

我做过一个粗略的对比测试，一幅 8 GB 的未压缩、无金字塔影像，在千兆网络盘上，第一次全图缩放到 1:50 万，QGIS 画布刷新耗时接近 40 秒；同一份数据用 DEFLATE 压缩加 512 块大小重写、并构建了 6 层内部金字塔之后，同样操作降到 1.2 秒左右。差距不是一点点，是两个数量级。这就是金字塔存在的全部意义：用可控的存储冗余，换掉大量不必要的磁盘随机读取和采样计算。

金字塔的本质是一组降采样的副本。第 1 层通常是原始尺寸的 1/2，第 2 层是 1/4，第 3 层是 1/8，依此类推。QGIS 在渲染时，会根据当前画布的分辨率需求，去挑一个“尺寸刚好够用、但又不至于太小”的层级来读取。缩得越远，读的层级越小，读的数据量也就越少。

1.2 QGIS 渲染链路里金字塔是怎么被选中的

理解这条链路，后面所有的参数选择才有依据。QGIS 的栅格渲染大致是这样走的：地图画布确定地理范围与输出像素尺寸 → 换算成每个像素代表的地面距离 → 向 GDAL 发起一个RasterIO请求，指定窗口范围和目标缓冲区大小 → GDAL 在这个请求里判断缩小倍数 → 在概览列表里挑一个满足条件的层级 → 从该层级读数据并重采样到缓冲区 → QGIS 拿到像素后做拉伸、配色、合成，画到画布上。

关键点在 GDAL 挑选层级的那一步。它不会无脑选最小的一层，而是找“尺寸仍然大于等于你请求的缓冲区大小”的那些层里，尺寸最小的那一层。换句话说，它宁可多读一点，也不愿意把一个太小的金字塔层硬放大，因为放大后会糊。这个逻辑很合理，但也意味着一个结论：金字塔层数如果建得不够，缩到很远时 GDAL 还是会退回去读更大的层，甚至读原始数据，性能提升就有限；反过来，层数建得过多，超出实际显示需求的部分就是纯粹的存储浪费，对性能没有任何帮助。

还有一个容易被忽略的点：QGIS 里图层的“可见比例范围”设置会直接影响金字塔的利用率。如果你把一个图层的最小可见比例设成 1:5000，那用户缩到 1:50 万时这个图层根本不渲染，金字塔建再多也没用；反过来，如果你让一个 0.2 米分辨率的影像一直可见到 1:100 万，那它对金字塔最深层的依赖就会非常强，层数必须建够。所以我在做性能调优时，第一步永远是问清楚：这个图层在业务上到底要被缩放到多小。

提示：不要拿“金字塔层数越多越好”当经验法则。层数应该由最小可见比例倒推，而不是照着某个模板一路建到 2 的 20 次方。

2. 金字塔参数怎么算：层数、因子与分块

2.1 层数不是拍脑袋：从最小显示比例倒推

层数的计算其实很简单，但要算对，得先明确两个量：源影像的最大边长W（像素），以及你最远要缩到多大范围时还需要看清它。假设某幅影像宽 60000 像素，业务上最远需要在一个约 1600 像素宽的地图窗口里完整显示它，那么需要的缩小倍数就是 60000 ÷ 1600 ≈ 37.5 倍。金字塔的层级因子是 2 的幂，所以层数n满足2^n ≥ 37.5，取n = 6（2 的 6 次方是 64）。也就是建 2、4、8、16、32、64 这六层，最深层是 60000/64 ≈ 938 像素宽，比 1600 略小，但因为 GDAL 会选“尺寸仍大于请求缓冲区”的层，实际上会用到第 5 层（32 倍，1875 像素），刚好覆盖。

如果不想每次都手算，有个更省事的经验公式：n ≈ ceil(log2(最大边长 / 256))，也就是一直建到某一层的最长边接近 256 像素为止。对 60000 像素的影像，这个结果是log2(234) ≈ 7.9，取 8 层。这个做法偏保守，层数会多一点，好处是无论用户缩到多小都不会掉回原始分辨率去读，代价是多占一点空间（最深层的数据量只有原始的一千多分之一，几乎可以忽略）。我个人的习惯是：面向交互式浏览的影像用 256 公式建满，面向自动化出图、显示范围可控的影像用最小比例倒推。

还有一个细节值得说：gdaladdo在不指定层级时，会自己算出一套默认层级，通常是 2、4、8、16……直到某个较小的尺寸。这套默认值在多数场景够用，但如果你对性能有明确要求，还是自己传参更稳，因为不同 GDAL 版本的默认策略略有差异，跨版本复现时容易出意外。

2.2 块大小、压缩与 BigTIFF 的取舍

金字塔的参数不只是层数，还有几个和存储结构强相关的选项，选错了照样卡。

块大小（Tile Size），也就是 GeoTIFF 内部的分块尺寸。传统 GeoTIFF 可以按行存储（strip），但按块存储（tile）对大范围随机读取友好得多。QGIS 缩放时读取的往往是地图窗口覆盖的那一小片区域，如果数据按行存，读一小片也得拉整行；按块存就只读命中的块。块大小常见取值是 256 和 512。256 的块更细，适合局部查看、块数量多但单块小；512 的块读取次数少，适合大范围概览浏览。我一般对中等规模数据用 256，对超大影像用 512，实测下来 512 在缩放时的 I/O 次数更少，网络盘上优势更明显。

压缩方式。不是所有压缩都适合栅格。JPEG 压缩率高但对分类数据、含 NoData 边缘的数据会造成明显伪影，而且它是有损的，做后续分析会引入误差。DEFLATE 和 LZW 是无损的，压缩率中等，适合绝大多数场景。ZSTD 在较新的 GDAL 里支持良好，压缩和解压速度都比 DEFLATE 快，如果环境里 GDAL 版本够新，我会优先选它。PREDICTOR 参数对有连续值特征的影像（比如高程、遥感反射率）很有帮助，设成 2 或 3 通常能让 DEFLATE 的压缩率再提升一截。

BigTIFF。经典 TIFF 格式的单个文件大小上限是 4 GB，超过就必须用 BigTIFF。这个坑很隐蔽：文件写到 4 GB 时构建过程突然失败，报的错还未必直白。所以只要预估输出可能超过 4 GB，就老老实实加上 BigTIFF 选项。

这三者的关系和金字塔是叠加的：金字塔层本身也遵循同样的分块和压缩设置（构建时可以通过配置项指定概览的压缩方式），所以预处理阶段的基底文件如果分块和压缩没做对，后面金字塔建得再好也是白搭。

3. 重采样算法的选择：连续数据和分类数据是两条路

3.1 常见算法对比与适用场景

构建金字塔时，从上一层降到下一层，每个新像素是由若干个原像素“合并”出来的，怎么合并就是重采样算法。这是最容易被忽视、但对结果质量影响最大的一环。

选择逻辑其实只有一句话：分类数据必须保持“类别不新增”，所以只能用 nearest 或 mode；连续数据应该追求平滑和统计代表性，average 或 cubic 更合适。用 average 去处理土地利用分类图，结果就是原本清清楚楚的“耕地/林地/水域”边界变成一片渐变糊，颜色还会冒出一些原始分类里根本不存在的中间色，这在制图和统计上都是灾难。反过来，用 nearest 处理高程或影像，缩小时会出现明显的马赛克和噪点，视觉上很脏。

3.2 分类数据的糊边问题与 mode 的局限

我印象很深的一次，某项目组用 average 建了土地利用栅格的金字塔，结果在 1:10 万缩放下，整片区域的颜色变得灰扑扑，图例对不上，做面积统计时还冒出了几个不存在的类别。原因就是平均运算把相邻类别的值混合了，比如类别编码 1 和 5 平均出 3，而 3 恰好是另一个真实类别。这种错误在视觉上不明显，但在统计上极其致命。

换用 mode 之后问题解决，但 mode 也有局限：一是部分 GDAL 版本对 mode 的支持依赖构建选项，不是所有环境都能用；二是 mode 在窗口内各类别数量接近时结果不稳定，可能出现细碎的“椒盐”噪点。如果环境不支持 mode，退而求其次的方案是先用 nearest 建金字塔保证类别纯净，再在 QGIS 端把图层的重采样方式设为最近邻，两处配合起来效果基本可控。

还有一个更稳妥的思路：对分类数据干脆不做深层金字塔，只建 2、4 两层，深层靠 QGIS 的可见比例限制来规避。分类图的业务用途通常是查看具体地块，很少有人需要缩到全国范围还看分类细节，与其为了一个用不上的场景去冒险建深层，不如把显示范围管住。

注意：分类栅格和连续栅格的金字塔策略必须分开管理。混在同一套预处理脚本里用同一个算法，是很多团队出问题的根源。

4. 实操：从原始影像到 QGIS 里流畅缩放

4.1 第一步：把基底文件重写成适合随机读取的结构

拿到原始影像后，不要直接在上面建金字塔。原始文件的组织方式（可能是按行存储、可能没压缩、可能是老式 TIFF）会拖累整个流程。正确做法是先做一次“基底重写”，用gdal_translate输出一个分块、压缩、必要时 BigTIFF 的新文件。

gdal_translate \ -of GTiff \ -co TILED=YES \ -co BLOCKXSIZE=512 \ -co BLOCKYSIZE=512 \ -co COMPRESS=DEFLATE \ -co PREDICTOR=2 \ -co ZLEVEL=6 \ -co BIGTIFF=IF_SAFER \ -co NUM_THREADS=ALL_CPUS \ input_raw.tif base.tif

这里每个参数的意图：TILED=YES开启分块；BLOCKXSIZE/BLOCKYSIZE=512设定块尺寸；COMPRESS=DEFLATE选无损压缩；PREDICTOR=2针对连续值数据提升压缩率（如果是分类数据，用 1 或干脆不设）；ZLEVEL=6是压缩级别，1 到 9，6 是速度与压缩率的平衡点，追求极致压缩可以上 9，但构建时间会明显变长；BIGTIFF=IF_SAFER让 GDAL 在预判可能超限时自动切 BigTIFF；NUM_THREADS=ALL_CPUS开多线程压缩。

实测下来，这一步对大影像的耗时是可以接受的，而且一次性投入换来的是后续所有读取操作的提速。有个细节：如果源数据本身已经是分块压缩的 GeoTIFF，且块大小合适，这一步可以直接跳过，用gdalinfo看一眼Block=那行就知道。

顺带说一个现在很流行的替代方案：如果目标环境支持，可以直接输出为 COG（云优化 GeoTIFF）。COG driver 在写出时就能一并处理分块、压缩和金字塔，省掉后续单独的建金字塔步骤。

gdal_translate \ -of COG \ -co BLOCKSIZE=512 \ -co COMPRESS=DEFLATE \ -co OVERVIEWS=IGNORE_EXISTING \ -co OVERVIEW_RESAMPLING=AVERAGE \ -co NUM_THREADS=ALL_CPUS \ input_raw.tif output_cog.tif

OVERVIEWS=IGNORE_EXISTING表示忽略输入里已有的概览重新生成，OVERVIEW_RESAMPLING指定重采样算法。COG 的好处是金字塔内嵌且结构规范，QGIS 读取时层级选择效率稳定。缺点是生成时间比分步操作略长，且对 GDAL 版本有要求。

4.2 第二步：构建金字塔，内部还是外部

这一步有个非常实际的抉择。内部金字塔写在源文件里，随文件一起走，不会丢，适合需要分发、拷贝的场景；缺点是文件体积变大，而且一旦源文件被占用（比如 QGIS 里正开着这个图层），写入就会失败。外部金字塔是一个独立的.ovr文件，与源文件同名同目录，构建时不影响源文件，源文件保持只读也没问题；缺点是容易在拷贝时被漏掉——我就见过好几次，数据拷到另一台机器后性能骤降，一查.ovr没跟着走。

内部金字塔的构建命令：

gdaladdo \ -r average \ --config COMPRESS_OVERVIEW DEFLATE \ --config GDAL_TIFF_OVR_BLOCKSIZE 512 \ --config GDAL_NUM_THREADS ALL_CPUS \ base.tif 2 4 8 16 32 64

外部金字塔只需加-ro（只读模式），GDAL 就会生成base.tif.ovr：

gdaladdo -ro -r average --config COMPRESS_OVERVIEW DEFLATE base.tif 2 4 8 16 32 64

几个配置项值得展开。COMPRESS_OVERVIEW指定概览层的压缩方式，不设的话概览可能是不压缩的，体积会膨胀得很难看；GDAL_TIFF_OVR_BLOCKSIZE控制概览的块大小，通常与基底保持一致；GDAL_NUM_THREADS让构建过程并行，对多层大影像的提速相当明显，我测过一幅 12 GB 的影像，单线程建 7 层要 40 多分钟，开满核心后降到 6 分钟左右。

如果数据量特别大，还可以考虑-minsize参数，让 GDAL 自动决定层数，建到某一层的最长边小于设定值为止。这个方式省心，但对层数的控制不如手动指定精确。

在 QGIS 界面里操作也可以。注意，QGIS 3.x 已经移除了老版本图层属性里的“金字塔”标签页，很多人照着旧教程找不到入口，以为是版本问题。现在的入口在菜单栏“栅格 → 杂项 → 构建概览（金字塔）”，或者处理工具箱里 GDAL → 栅格杂项 → 构建概览。界面里能选重采样算法、概览层数、是否内部存储、压缩方式、以及“只在缺少概览时构建”的选项。这个界面的优点是简单，缺点是参数粒度不如命令行细，比如概览块大小就没法直接调。

还有一点要提醒：QGIS 里图层正在被打开时，构建内部金字塔会失败。因为源文件处于读取占用状态，无法以更新模式打开。所以要么先移除图层，要么改用外部.ovr。这个错误提示往往很含糊，只说“无法打开文件进行更新”，新手很难联想到是图层占用导致的。

4.3 第三步：QGIS 端的三处设置，缺一不可

金字塔建好只是硬件条件具备，QGIS 端的软件设置不配合，效果照样打折。

第一处是图层的重采样设置。在图层属性 → 符号化选项卡下方，有“重采样”区域，可以分别设置“早于”和“晚于”某个缩放级别时的算法。这个设置控制的是 GDAL 把数据读进缓冲区之后的二次采样，和金字塔构建时的重采样是两回事。金字塔层选得合适的话，这里通常用默认即可；但如果发现某个缩放级别下有轻微锯齿或模糊，可以针对性调整。比如缩小时用双线性、放大时用最近邻，是个常见的组合。

第二处是可见比例范围。在图层属性的“渲染”选项卡里，可以设置最小和最大可见比例。这不是性能优化选项，但它能防止图层在不必要的时候被渲染。一个 0.2 米分辨率的影像在城市尺度下有存在的必要，缩到省域尺度时它既看不清又拖慢渲染，设个最小可见比例直接跳过，比建深层金字塔更彻底。这一招配合金字塔使用，效果往往比单纯加深层数更好。

第三处是渲染缓存。在设置 → 选项 → 渲染里，确认栅格渲染缓存是启用状态，并给一个合理的缓存大小。QGIS 会把渲染过的瓦片缓存起来，来回拖动、缩放时能直接复用。这个机制和金字塔是互补的：金字塔减少的是磁盘读取，缓存减少的是重复渲染。我一般会把缓存设到 512 MB 到 2 GB 之间，视机器内存而定，太小了缓存命中率低，太大了挤占其他内存。

提示：调优之后一定要做一次“冷启动测试”——重启 QGIS，清空缓存，再打开图层缩放一遍。很多所谓“优化生效”其实是缓存带来的假象。

5. 常见问题与排查实录

5.1 金字塔建了，缩放还是慢

这是我被问得最多的一类问题。先按下面的顺序排查，八成能定位。

第一步，确认金字塔真的存在且被读取。用gdalinfo base.tif看输出里有没有Overviews:那一段，列出了层数和尺寸就说明在。如果只有外部.ovr，gdalinfo会显示Overviews但会标注来源。如果这里什么都没有，那就是构建没成功，回去看构建日志。

第二步，确认 QGIS 读到了金字塔。有一个很实用的办法：在 QGIS 启动前设置环境变量CPL_DEBUG=ON，然后从命令行启动 QGIS，操作缩放，终端里会打印 GDAL 的读取日志，能看到它请求了什么尺寸、用了哪一层概览。这个办法有点土，但极其有效，比猜快得多。

第三步，检查是不是别的东西在拖后腿。比如图层是“多波段彩色”渲染且三个波段都参与，渲染开销本身就大；比如符号化里用了山体阴影、等高线之类的复杂效果；比如数据放在网络盘上，即便读的是金字塔层，网络延迟也扛不住频繁的小块读取。这种情况下把数据先复制到本地盘试一次，性能对比立刻就出来了。

第四步，检查是不是金字塔层数不够。缩到最远时如果 GDAL 仍然在读原始尺寸，说明最深层还是太大。看日志里请求的尺寸和实际读取的尺寸，差得远就是层数问题。

5.2 文件膨胀、颜色偏移与更新失效

文件体积暴涨。常见原因有两个：概览没设压缩（COMPRESS_OVERVIEW忘了加），或者 PREDICTOR 参数和数据类型不匹配（比如对分类数据用了 PREDICTOR=2）。一般来说，合理的内部金字塔会让文件增大约 30% 到 50%，超过这个范围就值得检查。另外一个原因是层数建得过多，尤其是建到十几层那种，虽然每层很小，但累加起来也不容忽视。

颜色偏移。分两种情况。一种是分类数据用了 average 或 cubic，前面讲过，换算法即可。另一种是连续数据在深层概览上出现色带或色块，往往是统计值（最小/最大值、直方图）与显示拉伸不匹配导致的。QGIS 的拉伸如果基于“估算”的统计值，而这个估算又是在概览层上算的，结果就会和原始数据有出入。解决办法是在图层属性里手动设定最小/最大值，或者用gdalinfo -stats基于原始数据算一次精确统计并写入.aux.xml。

源数据更新后金字塔失效。金字塔不会自动更新，这是设计使然。源数据一旦修改，必须重建。外部.ovr还有个更隐蔽的问题：它的时间戳比源文件新时 GDAL 才会用，如果拷贝过程中时间戳被改乱，可能出现读旧概览的情况。所以我在做数据分发时，习惯让.ovr和源文件一起打包，并提醒对方校验一致性。

只读目录下构建失败。外部.ovr需要在源文件同目录写入，如果目录是只读的（比如挂载的只读共享），构建就会失败。解决办法要么换成可写目录，要么提前在可写环境里构建好再整体拷过去。

5.3 问题速查表

我在实际项目里还遇到过一个更偏门的情况：某批影像的金字塔建得好好的，QGIS 里却始终读不到，最后发现是文件名里带了特殊字符，外部.ovr的命名在跨平台拷贝时被转义，导致 GDAL 找不到对应文件。改成纯英文数字命名后立刻正常。这类问题没有通用解法，只能靠“二分法”——把文件名改简单、把路径改短、把数据移到本地，一步步缩小范围。

最后分享一个我常用的自检流程：新数据进库之前，先随机抽三个缩放级别（近景、中景、远景）各做一次冷启动加载并计时，记下耗时；金字塔构建后再测一遍。如果三处都有明显下降，说明配置到位；如果只有近景快、远景没变化，基本可以断定是层数不够。这个流程简单，但比凭感觉判断靠谱得多。