视图不提升单次查询性能，仅降低维护成本；它不预计算，每次调用才执行子查询，避免SQL重复编写、口径不一致、可读性差及修改遗漏等问题，但需规避ORDER BY、变量、LIMIT等语法坑并规范命名。
视图本身不执行子查询预计算，它只是把子查询逻辑“存起来”，每次查视图时才真正执行——所以它不提升单次查询性能，但能显著降低重复编写、调试和维护复杂子查询的成本。
为什么不能直接在应用里写子查询，而要封装成视图
当多个地方需要同一段逻辑（比如「近30天活跃且订单总额超5000的客户」），硬编码会导致：
- SQL散落在不同服务、脚本或报表中，改一个地方漏改另一个，数据口径不一致
- 子查询嵌套三层以上时，可读性断崖式下降，
SELECT ... FROM (SELECT ... FROM (SELECT ...)) AS t连括号都数不清 - 底层表加了字段或重命名列，所有含该子查询的地方都要手动 grep + 修改，容易遗漏
CREATE VIEW 时必须避开的三个语法坑
视图定义语句看似就是 SELECT，但实际限制比想象中多：
- MySQL 8.0+ 才支持视图中含
ORDER BY，旧版本会静默忽略，导致你以为排序已生效，实际查出来是乱序 - 不能在视图定义里用变量（如
@last_date）或用户自定义函数（UDF），否则创建失败报错ERROR 1351 (HY000): View's SELECT contains a variable or parameter - 若子查询含
LIMIT，某些数据库（如 PostgreSQL）允许，但 MySQL 要求必须配合ORDER BY，否则报错ERROR 1393 (HY000): Can not modify more than one base table through a join view（虽然这里没改表，但语法校验会误判）
视图名怎么起才不容易和真实表混淆
命名不是小事，尤其当 DBA 和开发共用一套库时：
- 避免用
v_或view_前缀——很多老系统已有这类表，反而更难分辨；推荐后缀式，比如customer_summary_v、order_metrics_v - 禁止用复数形式（如
customers_v），因为视图返回的是结果集，不是“多个客户”，而是“客户汇总视图” - 如果视图只供某业务线用，加业务标识：比如
finance_revenue_daily_v，比revenue_daily_v更易追溯责任方
最常被忽略的一点：视图不解决性能问题，它只是把慢查询“藏得更优雅”。如果原始子查询没走索引、JOIN 顺序不合理，视图一查照样卡。上线前务必对视图执行 EXPLAIN，而不是只测 SELECT * FROM view_name LIMIT 10。
