通过执行计划判断SQL是否得到优化，主要可以从以下几个方面入手：
1. **执行成本（Cost）**：
- 查看执行计划中总的成本（Cost）估计，一般来说，成本越低，表示优化程度越高。成本主要包括CPU成本、IO成本等，理想情况下，优化过的SQL执行计划应该显著降低总体成本。
2. **访问路径（Access Path）**：
- 是否有效利用了索引。理想的执行计划应优先使用索引扫描，比如索引范围扫描（Index Range Scan）、索引快速全扫描（Index Fast Full Scan）等，而不是全表扫描（Full Table Scan），除非全表扫描的成本更低或数据量极小。
- 根据查询条件和数据分布，判断是否选择了最合适的索引或连接顺序。
3. **Join操作**：
- 关联查询（JOIN）的顺序和类型（Nested Loops、Hash Join、Sort Merge Join等），以及是否合理利用了连接条件和索引。
- 注意是否存在 cartesian join（笛卡尔积连接），这种情况往往会导致性能问题。
4. **排序（Sorting）**：
- 观察是否存在不必要的排序操作（Sorts），尤其是磁盘排序（Sorts (disk)），这可能表明需要优化排序策略或增加合适索引来避免排序。
- 如果排序在内存中完成（Sorts (memory)），则关注内存排序的数量和大小，过大的内存排序可能导致性能瓶颈。
5. **基数估算（Cardinality Estimation）**：
- 数据库优化器对每一阶段输出行数的估算（Cardinality）是否准确。不准确的基数估算可能导致选择次优执行计划。
6. **资源消耗**：
- 监视物理读（Physical Reads）、逻辑读（Consistent Gets）、磁盘排序、网络传输等指标，低效的SQL往往伴随着较高的资源消耗。
7. **执行时间（Elapsed Time / Execution Time）**：
- 实际执行时间也是衡量SQL性能的重要标准，优化过的SQL应当在同等条件下执行更快。
综合以上因素，并结合SQL语句本身的业务需求，可以判断SQL执行计划是否经过了有效的优化。如果执行计划中存在大量全表扫描、磁盘排序、高基数误判等情况，通常意味着还有优化的空间。通过调整SQL语句、增加或更改索引、收集统计信息等方式可以尝试进一步优化SQL执行计划。同时，可以对比优化前后执行计划的变化和性能测试结果来验证优化效果。
