应明确指定查询字段而非使用SELECT *，以提升性能、可维护性与安全性；需按业务场景裁剪字段、避免敏感字段泄露、JOIN时加表别名、利用覆盖索引及精简API响应。
查询时只取真正需要的字段，不盲目使用 *，是提升数据库性能和代码可维护性的基本要求。
避免 SELECT *
全字段查询会带来额外开销：数据库需读取并传输所有列数据，即使前端只用其中一两个；若表结构后续增加大字段（如 TEXT、BLOB），性能可能骤降；同时也不利于明确接口契约和调试定位。
- 明确列出所需字段，例如
SELECT id, name, status FROM users - 视图或临时表中若必须用
*，需加注释说明原因并定期复查 - ORM 查询也应显式指定字段，如 Laravel 的
select('id', 'name')
按业务场景裁剪字段
同一张表在不同接口中需要的字段往往不同。登录接口只需验证字段，列表页可能要展示摘要，详情页才加载全部信息。
- 用户列表页：仅查
id, nickname, avatar, created_at - 用户导出功能：补充
email, phone, last_login_at等统计字段 - 敏感字段（如密码哈希、身份证号）默认不查，除非当前逻辑明确需要且已授权
警惕隐式字段膨胀
JOIN 多表时容易因别名缺失或未限定导致字段重复、歧义，甚至意外拉取大量冗余数据。
立即学习“PHP免费学习笔记（深入）”；
- 多表 JOIN 必须为每个字段加上表别名，如
u.id, p.title - 避免
SELECT * FROM users u JOIN profiles p ON ...这类写法 - 使用数据库解释执行计划（EXPLAIN）检查实际读取的列数与行数是否合理
配合缓存与索引优化
精简字段不仅减少传输量，还影响索引效率和缓存命中率。覆盖索引（Covering Index）要求查询字段全部被索引包含，此时字段越少越容易命中。
- 高频查询字段尽量建联合索引，并把
WHERE条件字段放前面，SELECT字段放后面 - Redis 缓存结果时，字段越少序列化/反序列化越快，内存占用也更低
- API 返回数组中剔除空值或 null 字段，进一步减小响应体积（非数据库层但属整体精简环节）
