判断问题SQL判断SQL是否有问题，可以从两个表象来判断：1.系统层面表现CPU消耗严重IO等待严重页面如果响应时间过长，应用日志出现超时错误，可以使用sar命令和top命令查看当前系统状态。也可以通过Prometheus、Grafana等监控工具观察系统状态。2、SQL语句出现时间过长，执行时间过长。执行计划中的rows和cost都很大，冗长的SQL很容易看懂。如果一条SQL太长，可读性肯定会差，出问题的频率肯定会增加。高的。进一步判断SQL问题，还得从执行计划入手，如下图：执行计划告诉我们，这个查询进行了全表扫描Type=ALL，而且行数很大（9950400），可以基本上可以判断为“有味道”的SQL。获取问题不同的SQL数据库有不同的获取方式，以下是目前主流数据库的慢查询SQL获取工具MySQL慢查询日志测试工具loadrunnerPercona的ptquery等工具OracleAWR报表测试工具loadrunner等相关内部视图如v$,$GRIDCONTROL监控工具如session_wait大梦数据库AWR报表测试工具loadrunner等大梦性能监控工具(dem)相关内部视图如v$,$session_wait等SQL编写技巧SQL编写有以下通用技巧：Rational使用索引越少查询越慢；索引多了占用空间大，而且在增删改查语句时需要动态维护索引，影响性能。选择率高（重复值少），被where频繁引用，需要建立B树索引；通常，连接列需要被索引；复杂文档类型查询使用全文索引效率更高；索引的建立要在查询和DML性能之间取得平衡；创建复合索引时，要注意基于非前导列查询的情况。使用UNIONALL代替UNIONUNIONALL比UNION效率高，UNION需要对数据进行排序；UNION需要对数据进行排序，避免执行SQL时select*的写法，优化器需要将*转换成特定的列；每次查询都要返回表，不能使用覆盖索引。建议为JOIN字段创建索引。一般JOIN字段会提前建立索引，避免复杂的SQL语句，提高可读性；避免慢查询的概率；可以转化成多个短查询，使用业务端处理，避免where1=1的写法，orderbyrand()类似于RAND()，导致数据列被多次扫描。SQL优化的执行计划。要完成SQL优化，必须先读取执行计划。执行计划会告诉你哪里效率低，哪里需要优化。下面以MYSQL为例，看看执行计划是怎样的。（每个数据库的执行计划都不一样，需要自己去了解）sql讲解下面我们用一个实际的优化案例来说明SQL的优化过程和优化技巧。优化case表结构，关联三张表，查询当前用户当前时间前后10小时的订单状态，按照订单创建时间升序排列。具体SQL如下查看数据量。字段类型应与表结构一致。表中的user_id是varchar(50)类型，实际SQL中使用的int类型有隐式转换，没有加索引。将b、c表的user_id字段改为int类型。因为b表和c表有关联，所以在b表和c表的user_id上建立索引。因为a表和b表有关联，所以在a表和b表的seller_name字段上建立索引。使用复合索引来消除临时表和排序。初步优化SQL优化后查看执行查看优化后的执行计划，查看警告信息继续优化altertableamodify"gmt_create"datetimeDEFAULTNULL;查看执行时间查看执行计划摘要查看执行计划说明如果有警告信息，查看警告信息showwarnings；检查SQL中涉及的表结构和索引信息根据执行计划，思考可能的优化点根据可能的优化点进行表结构更改、添加索引、SQL重写等操作检查优化后的执行时间和执行情况plan如果优化效果不明显，重复第四步
