判断 SQL 是否有问题时可以通过两个表象进行判断：

系统级别表象
CPU 消耗严重
IO 等待严重
页面响应时间过长
应用的日志出现超时等错误
可以使用 sar 命令，top 命令查看当前系统状态。

也可以通过 Prometheus、Grafana 等监控工具观察系统状态。
SQL 语句表象
冗长
执行时间过长
从全表扫描获取数据
执行计划中的 rows、cost 很大
冗长的 SQL 都好理解，一段 SQL 太长阅读性肯定会差，而且出现问题的频率肯定会更高。更进一步判断 SQL 问题就得从执行计划入手，如下所示：

执行计划告诉我们本次查询走了全表扫描 Type=ALL，rows 很大 (9950400) 基本可以判断这是一段 "有味道" 的 SQL。

获取问题 SQL
不同数据库有不同的获取方法，以下为目前主流数据库的慢查询 SQL 获取工具

MySQL

慢查询日志
测试工具 loadrunner
Percona 公司的 ptquery 等工具
Oracle

AWR 报告
测试工具 loadrunner 等
相关内部视图如 v$、$session_wait 等
GRID CONTROL 监控工具
达梦数据库

AWR 报告
测试工具 loadrunner 等
达梦性能监控工具（dem）
相关内部视图如 v$、$session_wait 等
SQL 编写技巧
SQL 编写有以下几个通用的技巧：

• 合理使用索引

索引少了查询慢；索引多了占用空间大，执行增删改语句的时候需要动态维护索引，影响性能 选择率高（重复值少）且被 where 频繁引用需要建立 B 树索引；

一般 join 列需要建立索引；复杂文档类型查询采用全文索引效率更好；索引的建立要在查询和 DML 性能之间取得平衡；复合索引创建时要注意基于非前导列查询的情况

使用 UNION ALL 替代 UNION
UNION ALL 的执行效率比 UNION 高，UNION 执行时需要排重；UNION 需要对数据进行排序
 避免 select * 写法
执行 SQL 时优化器需要将 * 转成具体的列；每次查询都要回表，不能走覆盖索引。
JOIN 字段建议建立索引
一般 JOIN 字段都提前加上索引
避免复杂 SQL 语句
提升可阅读性；避免慢查询的概率；可以转换成多个短查询，用业务端处理
 避免 where 1=1 写法

• 避免 order by rand() 类似写法
RAND() 导致数据列被多次扫描