直接对视图执行EXPLAIN会失效，因多数数据库仅展开定义而不重写优化路径，需手动展开视图DDL、替换参数后对底层查询单独执行EXPLAIN ANALYZE等分析。
直接对视图执行 EXPLAIN 会失效
navicat 的「解释」按钮对 select * from my_view 这类语句调用的是数据库原生 explain，但多数数据库（尤其是 mysql）在面对视图时仅展开定义、不重写优化器路径，导致返回的执行计划仍是“视图包装层”的估算，而非底层表的真实访问路径。你看到的 type=all 或 rows=10000 很可能只是视图元数据的占位值，和实际执行完全脱节。
- MySQL 5.7+ 中，视图默认以
TEMPTABLE算法物化，EXPLAIN根本不展示物化过程开销 - PostgreSQL 中视图是纯文本替换，
EXPLAIN ANALYZE能看到真实计划，但若视图含 CTE 或递归查询，id和select_type会混乱，难以定位哪一层慢 - SQL Server 视图若含计算列或未绑定 schema，
SET STATISTICS XML ON可能报错Msg 3604或返回空计划
必须手动展开视图定义再分析
真正的性能瓶颈永远藏在视图背后的 SELECT 语句里。不要依赖 Navicat 自动解析，而是打开视图 DDL，复制其 AS 后面的完整查询，在 Navicat 查询编辑器中单独执行 EXPLAIN FORMAT=JSON SELECT ...（MySQL）或 EXPLAIN ANALYZE SELECT ...（PostgreSQL）。
- 用 Navicat 右键视图 →「对象信息」→ 切换到「DDL」标签页，复制内容
- 注意替换掉视图中可能存在的参数占位符（如
WHERE status = ?），填入真实值，否则key_len和possible_keys会失真 - 如果视图嵌套了其他视图，需逐层展开——直到所有
FROM都指向基础表为止 - 对展开后的语句，重点检查每张基础表的
type、key、rows和Extra，特别是Using temporary是否出现在 JOIN 条件之外的子层级
视图字段过多或含函数时的典型陷阱
视图定义里看似无害的写法，在执行计划里常引发索引失效或隐式转换，而 Navicat 的「解释」结果完全不提示这类问题。
-
SELECT UPPER(name), YEAR(created_at) FROM orders：即使created_at有索引，YEAR()也会让该列无法走索引，key显示为NULL，但你得自己比对 WHERE 条件是否用了同字段的函数 -
SELECT *, COUNT(*) OVER (PARTITION BY category)：窗口函数本身不阻塞索引，但若外层再加ORDER BY且没覆盖索引，Extra必出Using filesort - 视图含
UNION ALL多分支：Navicat 只显示第一个分支的EXPLAIN结果，其余分支是否走索引、是否扫描全表，完全不可见
真正卡点往往在统计信息过期或权限限制
即使你展开了视图、改写了 EXPLAIN ANALYZE，结果仍可能和线上慢查询对不上——这时候不是 Navicat 的问题，而是数据库状态没同步。
- MySQL 批量导入后没运行
ANALYZE TABLE，rows严重低估，你以为只扫 100 行，实际扫了 10 万行 - PostgreSQL 视图引用的表被
VACUUM过但没ANALYZE，EXPLAIN ANALYZE里的actual rows是对的，但plan rows仍不准，误导你判断优化方向 - Navicat 连接用户缺少
SHOWPLAN（SQL Server）或pg_statistic（PostgreSQL）权限，EXPLAIN返回空或报错，但界面不提示具体缺哪个权限
复杂视图的性能分析，本质是把“黑盒”拆成白盒的过程。Navicat 提供的只是入口和格式化外壳，真正要动手的，永远是你自己展开、填充、验证、再比对的那几步。
