推论难题SQL
推论SQL与否有难题时能透过三个虚无展开推论：
1、控制系统等级虚无
CPU耗用轻微IO等候轻微网页响应时间太长应用领域的笔记再次出现延时等严重错误能采用sar指示，top指示查阅现阶段控制系统状况。
也能通过Prometheus、Grafana等监视辅助工具检视控制系统状况。
2、SQL句子虚无
乏味的SQL都好认知，几段SQL太长写作性的确Sitapur，所以再次出现难题的振幅的确会更高。再进一步棋推论SQL难题就得从继续执行方案侧发力，如下表所示右图：
继续执行方案说他们此次查阅走了全表扫描器Type=ALL，rows非常大(9950400)基本上能推论这是几段”有香味”的SQL。
MySQL
慢查阅笔记IOloadrunnerPercona子公司的ptquery等辅助工具Oracle
AWR调查报告IOloadrunner等有关外部快照如v$、$session_wait等GRID CONTROL监视辅助工具达梦资料库
AWR调查报告IOloadrunner等达梦性能监视辅助工具（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()导致数据列被多次扫描器
SQL强化
继续执行方案
完成SQL强化一定要先读继续执行方案，继续执行方案会说你哪些地方效率低，哪里能需要强化。他们以MYSQL为例，看看继续执行方案是什么。（每个资料库的继续执行方案都不一样，需要自行了解）explain sql
接下来他们用几段前述强化案例来说明SQL强化的过程及强化技巧。
强化案例
表结构
三张表关联，查阅现阶段用户在现阶段时间前后10个小时的订单情况，并根据订单创建时间升序排列，具体SQL如下表所示
查阅数据量
原继续执行时间
原继续执行方案
初步强化思路
SQL中 where条件字段类型要跟表结构一致，表中user_id 为varchar(50)类型，前述SQL用的int类型，存在隐式转换，也未添加索引。将b和c表user_id 字段改成int类型。因存在b表和c表关联，将b和c表user_id创建索引因存在a表和b表关联，将a和b表seller_name字段创建索引利用复合索引消除临时表和排序初步强化SQL
查阅强化后继续执行时间
查阅强化后继续执行方案
查阅warnings信息
继续强化alter table a modify “gmt_create” datetime DEFAULT NULL;
查阅继续执行时间
查阅继续执行方案
