-- 不推荐
SELECT * FROM user WHERE id = 123;

-- 推荐
SELECT id, name, email FROM user WHERE id = 123;

-- user表有联合索引：idx_name_email(name, email)

-- SELECT *：无法使用索引覆盖，需要回表
-- 执行流程：
-- 1. 走 idx_name_email 找到主键 id
-- 2. 根据 id 回主键索引取所有字段（name, email, phone, avatar, ...）
EXPLAIN SELECT * FROM user WHERE name = '张三';
-- Extra: Using index condition  （只用到索引条件，还需要回表）

-- 只查索引列：可以使用索引覆盖
-- 执行流程：
-- 1. 走 idx_name_email，直接返回 name 和 email
-- 2. 不需要回表
EXPLAIN SELECT name, email FROM user WHERE name = '张三';
-- Extra: Using index   （索引覆盖，无需回表）

-- user 表有 30 个字段，包括头像 URL、简介等长字段
SELECT * FROM user LIMIT 1000;
-- 传输数据量：1000 行 × 约 2KB = 2MB

SELECT id, name, email FROM user LIMIT 1000;
-- 传输数据量：1000 行 × 约 150B = 150KB

-- 一个包含 TEXT 字段的表
CREATE TABLE article (
    id INT PRIMARY KEY,
    title VARCHAR(200),
    summary VARCHAR(500),
    content TEXT,       -- 最多 64KB
    cover_url VARCHAR(500),
    created_at DATETIME
);

-- SELECT * 会将 content 也加载到内存
-- 每次查询都可能导致大页数据进入 buffer pool
-- buffer pool 中充斥着实际上用不上的 content 数据

buffer pool 大小：8 GB
每次 SELECT * 从 article 表读取：1000 行
每行包含 content（平均 10KB）
单次查询消耗 buffer pool：10MB
如果把 content 换成大图 base64，情况更糟

// 假设 OrderService.getOrderList() 使用 SELECT *
// 调用方只关心 order_no 和 amount

// 如果 DBA 要修改表结构（如删除一个废字段 address）
// SELECT * 的查询不受影响（列减少）
// 但应用程序如果引用了 address 字段...

// 重构时：
// - 不知道哪些地方依赖了 address 列
// - 无法做最小化数据返回的优化
// - 代码审查时看不出数据依赖

-- SELECT * 无法利用"只查索引"的优化
SELECT * FROM user USE INDEX(idx_email) WHERE email = 'test@example.com';
-- MySQL Server 层需要索引的所有字段，但索引只覆盖了 id+email
-- 还是得回表

// 推荐：明确字段列表
@Select("SELECT id, name, email, phone, status FROM user WHERE id = #{id}")
User findUserById(@Param("id") Long id);

// 按需创建 DTO，而不是复用 Entity
public class UserDTO {  // 只包含需要返回的字段
    private Long id;
    private String name;
    private String email;
}

-- 推荐：按需查询字段
SELECT id, order_no, amount, status, create_time
FROM order
WHERE user_id = 123;