视图应显式指定所需字段而非使用SELECT *，避免BLOB/TEXT字段拖垮查询；需配合覆盖索引、垂直拆表及ORM字段限定才能彻底规避大字段加载风险。
视图里塞 BLOB 或 TEXT 字段，不是“查得慢”，而是“一查就拖垮整个查询链”——因为视图展开后，SELECT * 或未显式排除这些字段时，MySQL 会强制加载整行（含大字段）到内存，哪怕你最终只取 id 和 name。
视图定义中直接排除大字段
最简单也最有效的做法：别在视图 SELECT 列表里写 *，手动列出业务真正需要的字段，把 content、avatar、raw_data 这类大字段彻底剔除。
- 错误写法：
CREATE VIEW user_list AS SELECT * FROM users—— 后续任何基于该视图的查询都可能触发大字段读取 - 正确写法：
CREATE VIEW user_list AS SELECT id, name, status, created_at FROM users - 如果业务上存在“偶尔需要大字段”的场景，可另建一个专用视图，如
user_detail，仅在详情页调用
用覆盖索引让视图查询不回表
即使视图只选小字段，若底层表没对应索引，MySQL 仍会回聚簇索引捞整行（含被排除的大字段），导致 IO 暴增。
- 检查执行计划：
EXPLAIN SELECT id, name FROM user_list WHERE status = 'active'，看Extra是否出现Using index - 若没有，需在基表上建联合索引，例如：
CREATE INDEX idx_status_id_name ON users(status, id, name) - 注意顺序：
status是过滤条件，放最左；id和name是查询字段，补在右侧构成覆盖
大字段垂直拆到关联表再 LEFT JOIN
当视图要兼顾“列表轻量”和“详情可用”，硬塞所有字段或反复改视图都不现实。更可持续的做法是把大字段剥离出去，视图通过 LEFT JOIN 按需加载。
- 拆表结构：
users表保留id、name等高频字段；user_contents表存user_id+avatar+bio（TEXT） - 视图定义：
CREATE VIEW user_list AS SELECT u.id, u.name, u.status, c.avatar FROM users u LEFT JOIN user_contents c ON u.id = c.user_id - 关键点：列表页查询时，
c.avatar为NULL不影响主表数据加载；只有显式需要头像时才实际读取user_contents行
ORM 中调用视图时务必指定字段
很多框架（如 Django ORM、Laravel Eloquent）对视图默认走 SELECT *，哪怕视图本身已精简，也会因 ORM 生成 SQL 的方式重新引入风险。
- Django 示例：
UserListView.objects.values('id', 'name', 'status')比.all()安全得多 - Laravel 示例：
UserView::select('id', 'name', 'status')->get()，绝不要用::all() - 检查生成的 SQL：开启查询日志，确认最终语句不含大字段名，尤其注意 ORM 自动添加的
created_at、updated_at是否意外触发了包含大字段的索引回表
最容易被忽略的是：视图本身不存储数据，但它的“使用方式”决定了底层是否加载大字段。只要有一次 SELECT * 或隐式回表，就等于给所有调用者埋了雷。控制权不在视图定义里，而在每一次 SELECT 的字段列表中。
