一句话说清楚：别把几十万行数据一次性灌进表格。DataGridView 的 VirtualMode（虚拟模式）让你只告诉它"总行数是多少"，它要显示哪一行才通过 CellValueNeeded 事件来问你要值——配合数据库分页和内存缓存，界面上滚动百万行和滚动一百行一样流畅，内存还只占一页数据的量。
01直接绑 DataTable，时间到底耗在哪？
很多人拿到查询结果习惯一气呵成：SELECT * FROM 大表 填满 DataTable，然后 dataGridView1.DataSource = dt。数据量过了五万，界面明显发滞；二十万行，加载转圈十几秒，拖动滚动条像放幻灯片。
其实瓶颈是叠在一起的三层：
- 取数层：全量数据从数据库搬到内存，网络传输、反序列化都要时间；
- 对象层：每行每列生成 DataGridViewRow、DataGridViewCell 对象，20 万行 × 15 列就是 300 万个对象，内存几个 G；
- 布局层：绑定后表格要为所有行计算布局、应用样式，一次性完成。
你看，用户一屏只能看见三四十行，剩下 19.99 万行的对象纯粹是白建。这不是电脑不行，是思路不对。
02先别急着写代码：用户真的需要看百万行吗？
但确实有一类需求绕不过去：历史数据浏览、日志审计，用户要在大范围里自由滚动、随时定位，这时候 VirtualMode 才是对症的药。技术选型之前先辨需求，别为了炫技给简单页面套复杂机制。
03VirtualMode 是怎么工作的？
虚拟模式的核心是一句话：表格不存数据，只负责显示。数据存在你自己的地方（数据库、文件、缓存），表格需要时张嘴问你要。
| 要做的事 | 对应事件 / 属性 |
|---|---|
| 告诉表格总共有多少行 | RowCount 属性 |
| 表格要显示某个单元格的值 | CellValueNeeded 事件（最核心） |
| 允许编辑，回写用户输入 | CellValuePushed 事件 |
| 即将显示一批行，可提前加载 | CacheVirtualItems 事件 |
| 行高由内容决定 | RowHeightInfoNeeded 事件 |
开启方式就一行：VirtualMode = true，列照常预先用代码或设计器加好。之后绝对不能再设 DataSource，两条路只能走一条。
04完整实现：按需取数
// 假设列：时间 / 批次号 / 结果 / 数值 private readonly DataPager _pager = new DataPager(pageSize: 200); private void InitGrid() { dgv.VirtualMode = true; dgv.CellValueNeeded += Dgv_CellValueNeeded; int total = _pager.GetTotalCount(); // SELECT COUNT(*) dgv.RowCount = total; // 只给数字，不给数据 } private void Dgv_CellValueNeeded(object sender, DataGridViewCellValueEventArgs e) { // e.RowIndex 就是表格当前要的行号，从0开始 Record r = _pager.GetRow(e.RowIndex); switch (e.ColumnIndex) { case 0: e.Value = r.Time; break; case 1: e.Value = r.BatchNo; break; case 2: e.Value = r.Result; break; case 3: e.Value = r.Value; break; } }
关键点：GetRow 必须快。如果每次都去查数据库，快速滚动时事件每秒触发上千次，照样卡——所以中间必须有缓存层。
05分页缓存：GetRow 背后干什么？
把数据按页（如每页 200 行）从数据库取回，内存里只留最近用过的几页：
public Record GetRow(int rowIndex) { int pageNo = rowIndex / _pageSize; if (!_cache.TryGetValue(pageNo, out var page)) { page = LoadPageFromDb(pageNo); // 分页SQL，见下 _cache.Add(pageNo, page); _cache.EvictIfTooMany(10); // 只留10页≈2000行 } return page[rowIndex % _pageSize]; } // SQL Server 分页（2012+） SELECT 时间,批次号,结果,数值 FROM 历史表 ORDER BY 时间 OFFSET @skip ROWS FETCH NEXT 200 ROWS ONLY
还可以订阅 CacheVirtualItems：事件会告诉你"马上要显示第 x 到第 y 行"，在里面提前异步把下一页加载好，用户快速拖滚动条时也感觉不到等待。注意预取要在后台线程做，别在事件里同步阻塞 UI。
SELECT COUNT(*)。SQL Server 大表 COUNT 可能扫好几秒，建议：过滤条件固定的列表用索引视图或维护计数表；SQLite 有索引时 COUNT 很快。别让用户为一个数字等三秒。06排序、滚动条和新增行的坑
- 排序要自己实现：虚拟模式下点列头不会自动排序。处理 ColumnHeaderMouseClick，把排序字段带进分页 SQL 重新查，再刷新 RowCount——本质是换了个取数顺序；
- 滚动条位置是准的：因为 RowCount 是真实总行数，拖动滑块能精确定位，这是虚拟模式相对"纯分页表格"最大的体验优势；
- 新增行需谨慎：AllowUserToAddRows 在虚拟模式行为复杂，建议加数据走自己的"新增"按钮，写完后 RowCount++ 并刷新缓存；
- 样式别按行个性化：CellFormatting 里大量条件判断会吃掉性能，整表统一样式、只在必要列着色。
07实测能快多少？
| 方式（20万行 × 4列） | 首次加载 | 内存占用 | 滚动 |
|---|---|---|---|
| 绑定 DataTable | 9~14 秒 | 约 450 MB | 明显掉帧 |
| VirtualMode + 分页缓存 | 0.2~0.4 秒 | < 20 MB | 满帧流畅 |
这组数字是我在一台普通 i5 工控机、SQL Server 本地库上实测的，不同环境数值有差异，但量级不会骗人——加载快的本质是"几乎没加载"。
08怎么验证？怎么落地？
- 造数据：灌 50 万行测试数据，别只拿 500 行验证，虚拟模式的问题只在大行数下暴露；
- 拖到底：快速把滚动条从顶甩到底，确认 CellValueNeeded 不抛异常、最后一行能显示；
- 盯内存：来回滚动十分钟，内存应平稳——持续上涨说明缓存淘汰没生效；
- 断网测试：数据库不可用时 GetRow 要有兜底值（如显示"加载失败"），不能让事件里的异常崩掉整个界面。
今天就可以动手：把你手上一个全量绑定的页面改成虚拟模式，先做只读浏览——开启 VirtualMode、实现 CellValueNeeded、把取数封成带缓存的 GetRow。说实话，做完这一个页面，你会重新理解"数据和显示分离"这句话，以后写任何表格第一反应都是：用户一屏能看几行，我就准备几行。