<p>视图命名须带业务前缀，禁用模糊命名；禁用 SELECT * 和硬编码；MySQL 视图无物化能力，慎用性能优化预期；权限必须授予视图而非表；避免深层嵌套与过度 JOIN；分页需游标替代 OFFSET；非银弹，需前置厘清使用边界。</p>
视图命名必须带业务前缀，否则后期根本分不清谁在用
SQL视图本质是保存的 SELECT 语句，不存数据，但名字一旦起得模糊（比如 v_user、view1），很快就会变成团队里的“幽灵对象”——没人敢删，没人敢改，连 SELECT * FROM v_user 查出来是员工还是客户都得翻源码。
- 统一用业务域+功能+后缀，例如
v_report_sales_summary_2024、v_api_customer_active_list - 避免在视图里用
SELECT *，字段变动时下游查询会静默出错；显式写出字段名，哪怕多敲几下键盘 - 视图定义里别写硬编码值（如
WHERE status = 'active'），这类逻辑应该交给应用层或参数化视图（PostgreSQL 支持，MySQL 不支持）
MySQL 8.0+ 才支持物化视图等价能力，别被文档误导
很多开发者看到“视图能提升性能”就直接上，结果发现 CREATE VIEW v_slow AS SELECT ... JOIN ... GROUP BY ... 后，每次查视图都重跑全量关联——因为 MySQL 的视图纯属“宏展开”，没有缓存、没有物化、不走索引优化器的预判路径。
- 真正需要加速的聚合类查询，优先考虑建汇总表 + 定时任务刷新，或者用
MATERIALIZED VIEW（仅 PostgreSQL 15+ 原生支持） - MySQL 用户若真要类物化效果，可用
CREATE TABLE ... AS SELECT ...+ 触发器/事件调度器手动维护，但要注意并发更新冲突 - 视图嵌套层级别超过 2 层（A → B → C），MySQL 优化器大概率放弃推导谓词下推，查询变慢且难以调试
权限控制必须落在视图上，而不是底层表
给前端查询接口配视图，不是为了省事，而是为了切数据边界。如果只给用户 SELECT 权限到原表，那 v_customer_basic 就形同虚设——用户绕过视图直接查表，敏感字段（如 id_card、phone）照样暴露。
- 建完视图后，立刻执行：
REVOKE SELECT ON schema.table FROM 'app_user'@'%'; GRANT SELECT ON schema.v_customer_basic TO 'app_user'@'%'; - 视图里用
CASE WHEN或函数脱敏（如CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))），比靠应用层过滤更可靠 - 注意：MySQL 8.0.22+ 支持视图级别的
SQL SECURITY DEFINER，但 DEFINER 用户必须存在且有底层表权限，否则视图创建成功、查询时报ERROR 1449 (HY000): The user specified as a definer does not exist
JOIN 太多的视图千万别直接丢给前端分页查
SELECT * FROM v_order_with_user_address_product_category 看着方便，实际一查 LIMIT 20 OFFSET 10000，数据库得先拼出 10020 行再截断——视图不会帮你自动加 WHERE 过滤，也不会把分页下推到子查询里。
- 面向接口的视图，只保留最必要字段，用
WHERE 1=1占位，让调用方传参拼条件（如AND order_date >= ?） - 涉及分页场景，视图定义里别含
GROUP BY或DISTINCT，否则OFFSET效率雪崩；改用游标分页（WHERE id > ? ORDER BY id LIMIT 20） - PostgreSQL 可用
WITH CHECK OPTION防止 INSERT/UPDATE 越界，但 MySQL 不支持该语法，得靠应用层校验
视图不是银弹，它最怕的是“写的时候图省事，查的时候怪数据库慢”。真正难的从来不是怎么建，而是想清楚这一行 CREATE VIEW 之后，谁会查、查多少、字段能不能动、权限卡没卡住——这些细节漏一个，后面八成要半夜改 SQL。
