在 MySQL 中，对一个包含 1000 万行数据的表执行 SELECT *，会导致内存急剧上升吗？
考察说明
考查对 MySQL 查询执行过程中内存使用机制的理解，包括存储引擎、结果集缓存和客户端接收方式等。
回答思路
- 【回答框架 1】MySQL 服务器端，SELECT * 的开销主要在执行阶段，存储引擎（如 InnoDB）通过缓冲池缓存数据页，但查询本身不强制将所有数据加载到内存，而是按需读取。内存是否飙升取决于查询是否使用临时表、排序或分组等操作，简单全表扫描通常不会一次性载入全部数据。
- 【回答框架 2】客户端方面，如果使用默认方式一次性获取所有结果，那么客户端内存可能飙升，因为需要存储整个结果集。但多数编程语言驱动支持流式查询或游标，可以逐行读取，从而控制客户端内存占用。
- 【回答框架 3】服务器端和客户端之间存在网络传输和缓冲区，MySQL 结果集是边发送边丢弃的，但查询缓存和排序等可能增加内存使用。此外，如果 SELECT * 涉及大字段（如 TEXT/BLOB），会增大网络传输和临时内存开销。
- 【回答框架 4】优化手段包括只选择必要列、分页查询、使用索引覆盖、调整 fetch size 等。对千万行数据，全表扫描本身可能引起 I/O 和 CPU 压力，但内存增长通常是可控的，除非触发排序或临时表。
- 【关键点 1】SELECT * 全表扫描时，MySQL 服务器端通常不会一次性将所有行加载到内存，而是边扫描边返回。
- 【关键点 2】内存飙升主要出现在客户端一次性获取全部结果，或查询包含排序、分组、去重等需要临时表的操作。
- 【关键点 3】使用游标或流式查询可以避免客户端内存占用过高。
- 【易错点 1】错误地认为 MySQL 会一次性将所有数据加载到内存导致 OOM，实际上服务器端内存主要受 buffer pool 和临时表限制。
- 【易错点 2】忽略大字段（如 BLOB）可能带来的额外内存和网络开销。
- 【易错点 3】将内存飙升归因于查询本身，而忽视客户端 fetch 方式的影响。