navicat for sqlite不支持图形化执行计划，仅显示文本格式的explain query plan表格，因sqlite引擎本身不生成xml或图形化计划；其detail字段内容（如scan table、search table using index）是分析索引使用与否的关键依据。
navicat for sqlite 不支持图形化执行计划，只能看到文本格式的 explain 输出，且不渲染运算符图标、成本百分比或行数统计 —— 这是 sqlite 引擎本身的限制，不是 navicat 的功能缺陷。
为什么点“解释”只显示表格，没有图？
SQLite 从不生成 XML 或图形化执行计划。它的 EXPLAIN 和 EXPLAIN QUERY PLAN 都返回纯文本行（每行一个操作），Navicat 只是把结果按列展示成表格。你不会看到箭头、粗细线、红色警告框或“缺少索引建议”悬浮提示——这些在 SQL Server 或 MySQL 版本里才有。
-
EXPLAIN显示虚拟机指令（如OpenRead、Seek、Next），偏底层，适合调试查询编译逻辑 -
EXPLAIN QUERY PLAN更实用，输出人类可读的执行策略，比如SCAN TABLE users或SEARCH TABLE orders USING INDEX idx_order_status - Navicat 默认调用的是
EXPLAIN QUERY PLAN，但不会自动加EXPLAIN前缀；你得自己写好再点“解释”
如何正确读取 SQLite 的 EXPLAIN QUERY PLAN 表格
Navicat 展示的列名（id、parent、detail）直接来自 SQLite 的 EXPLAIN QUERY PLAN 输出。关键不在数字，而在 detail 字段的字符串内容：
- 看到
SCAN TABLE xxx：全表扫描，没走索引，检查 WHERE 条件是否对索引字段用了函数或类型转换 - 看到
SEARCH TABLE xxx USING INDEX yyy：走了索引，但要确认yyy是你期望的那个索引 - 出现
USE TEMP B-TREE FOR ORDER BY或USE TEMP B-TREE FOR GROUP BY：说明排序/分组没走索引，触发了内存临时表 -
CO-ROUTINE或嵌套多层id/parent：子查询被物化（materialized），可能拖慢性能，尤其数据量大时
哪些写法会让 SQLite 索引失效，但 Navicat 不会提醒？
Navicat for SQLite 没有“索引查看器”选项卡（那是 MySQL/SQL Server 版的功能），也不会像 SQL Server 那样悬停提示“创建索引”。你得靠手动比对：
-
WHERE UPPER(name) = 'ALICE'→ 函数包裹，索引失效；应改用name = 'ALICE' COLLATE NOCASE -
WHERE created_at > strftime('%Y-%m-%d', 'now')→ 表达式右侧含函数，无法用索引；应改为created_at > '2026-06-04' -
WHERE status IN ('active', 'pending') AND user_id = 123，但索引是(user_id)单列 →possible_keys类概念不存在，Navicat 不显示“可用但未选”，你得自己查PRAGMA index_list('table_name')和PRAGMA index_info('index_name') - 联合索引顺序错：建了
(a, b)，却查WHERE b = ?→ 不会走索引；SQLite 不支持跳过前导列
真正有用的辅助命令，得手动敲
Navicat 的查询编辑器支持直接运行 PRAGMA 命令，这是分析 SQLite 执行计划绕不开的环节：
- 查表有哪些索引：
PRAGMA index_list('users') - 查某个索引包含哪些列及顺序：
PRAGMA index_info('idx_users_email') - 确认统计信息是否更新（影响优化器决策）：
ANALYZE users（执行后重试EXPLAIN QUERY PLAN） - 强制使用某索引（调试用）：
SELECT * FROM users INDEXED BY idx_users_email WHERE email = 'a@b.com'
这些命令不会被 Navicat 自动补全或高亮，也无图形引导，但它们才是定位 SQLite 性能瓶颈的核心手段。
