MySQL查询优化：筛选查询与全量后过滤、关联与分查询方案对比

问题1：仅筛选需要的字段查询，是否比先查询全量行后再过滤的性能更好？ #

是，二者的性能差距会随数据量增长持续拉大，核心差异体现在三个层面：

• 数据库层：仅查询所需字段时，MySQL有更高概率命中覆盖索引，避免回表操作，同时减少了数据页扫描、内存暂存的开销，执行计划成本更低。
• 传输层：返回字段越少，数据包体积越小，网络传输耗时更短，对数据库和应用服务器的带宽占用也更低，存在大字段（text、blob等）时差距会放大到数倍甚至数十倍。
• 应用层：不需要做多余的字段过滤逻辑，减少了内存占用和序列化/反序列化的资源消耗。

问题2：两种实现方案长期优劣对比 #

方案1：单条关联查询返回80列、仅使用15列 #

• 优点：首次开发成本极低，不需要额外做数据拼接，后续新增展示字段仅需调整查询的返回字段列表，迭代成本低。
• 缺点：全量返回字段的性能损耗极高，多余字段会带来全链路的资源浪费；如果关联逻辑复杂，多表JOIN的锁冲突、执行计划劣化的概率更高；后续关联表的结构变更（增删字段、调整索引）很容易影响这条查询的稳定性。
• 可优化空间：如果选择该方案，必须把查询语句从返回全字段改为仅返回需要的15个字段，调整后绝大多数性能和稳定性问题都会得到缓解。

方案2：多次查询取15个所需字段、手动拼接数据 #

• 优点：性能更可控，单表/小范围关联查询的执行计划更稳定，锁粒度更小，不会因为某张关联表的结构变更导致整个查询失效；仅取所需字段，资源浪费最少。
• 缺点：首次开发需要额外编写数据拼接逻辑，成本更高；如果查询次数控制不当出现N+1问题，性能反而会比合理优化后的关联查询更差。
• 可优化空间：将查询次数控制在5次以内，所有查询都走主键/索引批量取数，避免循环查库，同时把拼接逻辑抽象为通用方法，后续新增字段的迭代成本不会比方案1高太多。

长期最优选择 #

优先选择优化后的方案1：将关联查询的返回字段缩减到实际需要的15个，只要关联逻辑没有笛卡尔积、所有关联条件都走索引，该方案的综合成本最低，性能完全可以满足大多数场景需求。
只有当关联查询复杂度高到执行计划频繁劣化、或者多表JOIN的锁冲突已经影响线上业务稳定性时，再切换到优化后的方案2。

内容的提问来源于stack exchange，提问作者user9802118