① 复杂慢sql语句如何优化
很简单啊，优先索引，第二结构，第三算法。
索引最简单，如果是SQL server客户端或者toad可以提示有哪些需要进行优化的地方。
结构就是针对要查询的值，尽量集中到一个表，减少串表，函数查询，左链的表字段查询。
算法就是OR还是IN？串表时IN还是EXISTS ？oracle in 的限制。条件执行顺序等。
然后还有其他注意的，例如只查固定字段就不要 select * 只要注意以上步骤，千万级数据串10个秒也能1秒内显示出来。
有条件的话，当然是用归档数据进行查询，这样就不会占用业务数据IO了，最后一步就是“云计算”（解析有一百种，没有统一概念，我的意识其实就是归档过程中根据分组维度计算好，并根据日期放进相关的表，减少表粒度，只进行简单的select查询）
② 《数据库查询优化器的艺术原理解析与SQL性能优化》epub下载在线阅读，求百度网盘云资源
《数据库查询优化器的艺术》（李海翔）电子书网盘下载免费在线阅读
资源链接：
链接：
书名：数据库查询优化器的艺术
作者：李海翔
豆瓣评分：8.4
出版社：机械工业出版社
出版年份：2014-1-1
页数：532
内容简介：
《数据库技术丛书·数据库查询优化器的艺术：原理解析与SQL性能优化》是数据库查询优化领域的里程碑之作，由Oracle公司MySQL全球开发团队、资深专家撰写，作者有10余年数据库内核和查询优化器研究经验。数据库领域泰斗王珊教授亲自作序推荐，PostgreSQL中国社区和中国用户会发起人以及来自Oracle、新浪、网易、华为等企业的数位资深数据库专家联袂推荐。从原理角度深度解读和展示数据库查询优化器的技术细节和全貌；从源码实现角度全方位深入分析MySQL和PostgreSQL两大主流开源数据库查询优化器的实现原理；从工程实践的角度对比了两大数据库的查询优化器的功能异同和实现异同。它是所有数据开发工程师、内核工程师、DBA以及其他数据库相关工作人员值得反复研读的一本书。
《数据库技术丛书·数据库查询优化器的艺术：原理解析与SQL性能优化》共19章，分为四个部分：第一篇（第1～4章）对数据库查询优化技术的范围、逻辑查询优化、物理查询优化，以及查询优化器与其他模块的关系做了非常细致、深入的讲解；第二篇（第5～10章）首先从源码角度对PostgreSQL查询优化器的架构、层次、设计思想、相关数据结构和实现原理进行了深入、系统的分析，然后从功能角度对PostgreSQL的逻辑查询优化、物理查询优化、查询优化器的关键算法，以及PostgreSQL查询优化器与其他模块的关系做了深入的讲解；第三篇（第11～16章）首先从源码角度对MySQL查询优化器的架构、层次、设计思想、相关数据结构和实现原理进行了深入、系统的分析，然后从功能角度对MySQL的逻辑查询优化、物理查询优化、查询优化器的关键算法，以及MySQL查询优化器与其他模块的关系做了深入的讲解；第四篇（第17～19章）对PostgreSQL与MySQL的逻辑查询优化技术、物理查询优化技术、设计思想和编码规范等各方面进行了深度的比较。
作者简介：
李海翔，网名“那海蓝蓝”，资深数据库专家，从事数据库研发、数据库测试与技术管理等工作10余年，对数据库的内核有深入的研究，长于PostgreSQL和MySQL等开源数据库的内核与架构。现任职于Oracle公司MySQL全球开发团队，从事查询优化技术的研究和MySQL查询优化器的开发工作。曾参与了863、核高基、工信部、科技部、发改委、北京市科委等多个重大科技项目。2005年获得北京市科学技术进步奖一等奖，2006年获高级工程师（系统分析师）。
③ DBA必备的23款最佳SQL管理工具，精选
因为市场上有许多的SQL管理工具，所以要为SQL项目管理选择工具是一件有挑战性的事。为大家推荐23款SQL工具的精选列表，希望朋友们喜欢。其中几款已经在昨天的SQL查询优化工具一文中，做过推荐。
Aqua Data Studio是一个功能丰富的通用SQL集成开发环境（IDE），它使数据库开发人员，DBA和数据/业务分析人员能够从单个界面开发，管理和分析30多个平台的数据。
特征：
dbForge Studio for SQL Server是一个功能强大的IDE，用于SQL Server管理，管理，开发，数据报告，分析等等。执行复杂数据库任务的SQL开发人员和DBA可以使用GUI工具来加速几乎所有数据库体验，例如设计数据库，编写SQL代码，比较数据库，同步模式和数据，生成有意义的测试数据等等。
特征：
dbWatch是一个完整的数据库监控和管理解决方案，适用于SQL Server，Oracle，PostgreSQL，Sybase，MySQL和Azure。专为在大型内部部署，混合或云数据库环境中进行主动管理和日常维护自动化而设计。
特征：
Jet Profiler for MySQL是MySQL数据库服务器的实时查询性能和诊断工具。该工具自2009年开发，非常稳定。
特征：
Adminer是一个用于管理数据库，表，关系，索引和用户的SQL管理工具。它支持所有流行的数据库管理系统，如MySQL，PostgreSQL，SQLite，MS SQL，Oracle和MongoDB。
特征：
它是一种用于分析微软SQL Server数据库结构差异的SQL管理工具。它允许比较数据库对象，如表，列，索引，外键，模式等。
特征：
EMS SQL Manager允许用户创建和编辑SQL Server数据库对象，并创建，修改，执行和保存SQL查询。
特征：
它是一个基于JAVA的数据库管理工具。这种符合JDBC的SQL管理工具允许用户查看数据库结构并发出SQL命令。它还支持Firebird，微软Access，微软SQL Server，MySQL，Oracle，Sybase等数据库。
特征：
SQLite Database Browser是一个开源SQL工具，允许用户创建，设计和编辑SQLite数据库文件。它允许用户显示由它们和应用本身发出的所有SQL命令的日志。
特征：
DBeaver是一个面向开发人员和数据库管理员的开源数据库工具。它支持JDBC兼容的数据库，如MySQL，Oracle，IBM DB2，SQL Server，Firebird，SQLite和Sybase。
特征：
DbVisualizer Free是一个SQL管理工具。它允许用户管理各种数据库，包括Oracle，Sybase，SQL Server，MySQL，Informix，H3和SQLite。
特征：
HeidiSQL是另一种可靠的SQL管理工具。它使用流行的MySQL服务器，微软SQL数据库和PostgreSQL设计。它允许用户浏览和编辑数据，创建和编辑表，视图，触发器和预定事件。
特征：
FlySpeed SQL Query是所有数据库用户和开发人员的数据处理工具。它允许用户在不熟悉SQL语法的情况下在不同的数据库服务器上构建查询。
特征：
SQL Diagnostic Manager是Idera开发的性能监控工具。它提供诊断解决方案，帮助用户评估其SQL Server中的运行状况和性能。
特征：
ManageEngine开发的免费SQL性能监控工具。它允许用户密切关注SQL Server性能！此工具还可以帮助用户监控SQL Server的性能和可用性。它可以与MS SQL 2012和2014等所有MS SQL版本一起使用。
特征：
ApexSQL Monitor是一个基于Web的SQL管理应用程序。它为监控多个SQL Server实例提供支持。
特征：
适用于微软SQL Server的AppDynamics数据库管理产品的一种全面SQL工具。它用于监控SQL Server的2000,2005,2008,2012和2014版本。
特征：
Toad是另一个SQL Server DBMS工具。它通过广泛的自动化，直观的工作流程和内置的专业知识最大化了生产力。此SQL管理工具可解决问题，管理更改并提升最高级别的代码质量。
特征：
Zenoss提供ZenPacks来管理微软SQL Server，MySQL，Oracle数据库和PostgreSQL。每个ZenPack都具有每个平台的特定功能，并提供可用的API来确定应监控的内容。
特征：
Lepide的SQL Server Storage Manager是一个用于分析SQL Server性能的开源实用程序。它提供了对存储空间和性能的完全可视性。
特征：
SQL Server Management Studio Express是一个用于访问，管理和开发SQL所有组件的开源工具。此工具支持SQL Server的大多数管理任务。
特征：
SolarWinds Database Performance Analyzer是用于数据库管理的性能监视和分析工具。它还找出了瓶颈的原因并降低了数据库操作的总体成本。
特征：
Sequel Pro是一款快速，易用的数据库管理工具，适用于MySQL。此SQL管理工具有助于与数据库进行交互。使用此软件添加新数据库，添加新表，添加新行和任何其他类型的数据库也很容易。
特征：
④ 如何优化SQL语句
一、问题的提出
在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。
在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。
二、SQL语句编写注意问题
下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。
1.
IS
NULL
与
IS
NOT
NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。
任何在where子句中使用is
null或is
not
null的语句优化器是不允许使用索引的。
2.
联接列
对于有联接的列，即使最后的联接值为一个静态值，优化器是不会使用索引的。我们一起来看一个例子，假定有一个职工表(employee)，对于一个职工的姓和名分成两列存放(FIRST_NAME和LAST_NAME)，现在要查询一个叫比尔.克林顿(Bill
Cliton)的职工。
下面是一个采用联接查询的SQL语句，
select
*
from
employss
where
first_name||''||last_name
='Beill
Cliton';
上面这条语句完全可以查询出是否有Bill
Cliton这个员工，但是这里需要注意，系统优化器对基于last_name创建的索引没有使用。
当采用下面这种SQL语句的编写，Oracle系统就可以采用基于last_name创建的索引。
***
where
first_name
='Beill'
and
last_name
='Cliton';
.
带通配符(%)的like语句
同样以上面的例子来看这种情况。目前的需求是这样的，要求在职工表中查询名字中包含cliton的人。可以采用如下的查询SQL语句:
select
*
from
employee
where
last_name
like
'%cliton%';
这里由于通配符(%)在搜寻词首出现，所以Oracle系统不使用last_name的索引。在很多情况下可能无法避免这种情况，但是一定要心中有底，通配符如此使用会降低查询速度。然而当通配符出现在字符串其他位置时，优化器就能利用索引。在下面的查询中索引得到了使用:
select
*
from
employee
where
last_name
like
'c%';
4.
Order
by语句
ORDER
BY语句决定了Oracle如何将返回的查询结果排序。Order
by语句对要排序的列没有什么特别的限制，也可以将函数加入列中(象联接或者附加等)。任何在Order
by语句的非索引项或者有计算表达式都将降低查询速度。
仔细检查order
by语句以找出非索引项或者表达式，它们会降低性能。解决这个问题的办法就是重写order
by语句以使用索引，也可以为所使用的列建立另外一个索引，同时应绝对避免在order
by子句中使用表达式。
5.
NOT
我们在查询时经常在where子句使用一些逻辑表达式，如大于、小于、等于以及不等于等等，也可以使用and(与)、or(或)以及not(非)。NOT可用来对任何逻辑运算符号取反。下面是一个NOT子句的例子:
...
where
not
(status
='VALID')
如果要使用NOT，则应在取反的短语前面加上括号，并在短语前面加上NOT运算符。NOT运算符包含在另外一个逻辑运算符中，这就是不等于(<>)运算符。换句话说，即使不在查询where子句中显式地加入NOT词，NOT仍在运算符中，见下例:
...
where
status
<>'INVALID';
对这个查询，可以改写为不使用NOT:
select
*
from
employee
where
salary<3000
or
salary>3000;
虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。
虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。
⑤ 数据库系统优化的人工智能自动SQL优化
人工智能自动SQL优化出现在90年代末。目前在商用数据库领域，LECCO Technology Limited(灵高科研有限公司)拥有该技术，并提供使用该技术的自动优化产品LECCO SQL Expert，它支持Oracle、Sybase、MS SQL Server和IBM DB2数据库平台。该产品针对数据库应用的开发和维护阶段提供的模块有：SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。其核心模块SQL 语法优化器的工作原理为：①输入一条源SQL语句；②“人工智能反馈式搜索引擎”对输入的SQL语句，结合检测到的数据库结构和索引进行重写，产生N条等效的SQL语句输出；③产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写，直至无法产生新的输出或搜索限额满；④对输出的SQL语句进行过滤，选出具有不同执行计划的SQL语句；⑤对得到的SQL语句进行批量测试，找出性能最好的SQL语句。
⑥ SQL执行与优化
SQL优化
执行计划,表关联查询顺序,优化策略与思路
下面再向前走一些，容我根据自己的认识说一下查询执行的流程是怎样的：
1.连接
1.1客户端发起一条Query请求，监听客户端的‘连接管理模块’接收请求
1.2将请求转发到‘连接进/线程模块’
1.3调用‘用户模块’来进行授权检查
1.4通过检查后，‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求
2.处理
2.1先查询缓存，检查Query语句是否完全匹配，接着再检查是否具有权限，都成功则直接取数据返回
2.2上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生成解析树
2.3接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树
2.4再转交给对应的模块处理
2.5如果是SELECT查询还会经由‘查询优化器’做大量的优化，生成执行计划
2.6模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限
2.7有则调用‘表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件
2.8根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理
2.9上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中
3.结果
3.1Query请求完成后，将结果集返回给‘连接进/线程模块’
3.2返回的也可以是相应的状态标识，如成功或失败等
3.3‘连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接
接下来再走一步，让我们看看一条SQL语句的前世今生。
首先看一下示例语句
示例语句
执行顺序
SQL解析
1. FROM
当涉及多个表的时候，左边表的输出会作为右边表的输入，之后会生成一个虚拟表VT1。
(1-J1)笛卡尔积
计算两个相关联表的笛卡尔积(CROSS JOIN) ，生成虚拟表VT1-J1。
两次全表扫描
哈希索引,查找复杂度都是 O(1) 。
2. WHERE
对VT1过程中生成的临时表进行过滤，满足WHERE子句的列被插入到VT2表中。
注意：
此时因为分组，不能使用聚合运算；也不能使用SELECT中创建的别名；
与ON的区别：
如果有外部列，ON针对过滤的是关联表，主表（保留表）会返回所有的列；
如果没有添加外部列，两者的效果是一样的；
应用：
对主表的过滤应该放在WHERE；
对于关联表，先条件查询后连接则用ON，先连接后条件查询则用WHERE；
hash join 哈希连接 驱动表和被驱动表都只会访问0次或1次
应用场景:一个大表一个小表/表上没有索引/返回结果集比较大
3. GROUP BY
这个子句会把VT2中生成的表按照GROUP BY中的列进行分组。生成VT3表。
注意：
其后处理过程的语句，如SELECT,HAVING，所用到的列必须包含在GROUP BY中，对于没有出现的，得用聚合函数；
原因：
GROUP BY改变了对表的引用，将其转换为新的引用方式，能够对其进行下一级逻辑操作的列会减少；
原作者的理解是：
根据分组字段，将具有相同分组字段的记录归并成一条记录，因为每一个分组只能返回一条记录，除非是被过滤掉了，而不在分组字段里面的字段可能会有多个值，多个值是无法放进一条记录的，所以必须通过聚合函数将这些具有多值的列转换成单值；
GROUP BY 重新聚合查询
4. HAVING
这个子句对VT3表中的不同的组进行过滤，只作用于分组后的数据，满足HAVING条件的子句被加入到VT4表中。
7.LIMIT
LIMIT子句从上一步得到的VT6虚拟表中选出从指定位置开始的指定行数据。
注意：
offset和rows的正负带来的影响；
当偏移量很大时效率是很低的，可以这么做：
采用子查询的方式优化，在子查询里先从索引获取到最大id，然后倒序排，再取N行结果集
采用INNER JOIN优化，JOIN子句里也优先从索引获取ID列表，然后直接关联查询获得最终结果
当前未用到索引,
三次full scan , table1 AS a / table2 AS b / GROUP BY
尽量少做重复的工作
控制同一语句的多次执/减少多次的数据转换/
杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销
关于临时表和表变量的选择
临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择，一般情况下，SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用户并发环境下，容易阻塞其他进程，所以建议，在并发系统中，尽量使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。
子查询的用法
相关子查询可以用IN、NOT IN、EXISTS、NOT EXISTS引入
NOT IN、NOT EXISTS的相关子查询可以改用LEFT JOIN代替写法
如果保证子查询没有重复 ，IN、EXISTS的相关子查询可以用INNER JOIN 代替
IN``的相关子查询用EXISTS代替
不要用 COUNT (*)的子查询判断是否存在记录，最好用 LEFT` `JOIN 或者EXISTS，比如有人写这样的语句：
建立索引后，并不是每个查询都会使用索引，在使用索引的情况下，索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引，
不要对索引字段进行运算，而要想办法做变换
不要对索引字段进行格式转换
不要对索引字段使用函数
不要对索引字段进行多字段连接
join关联查询的计算是很复杂的，特别是数据量比较大的情况下，实际情况还是拆解较快的
Join拆解的核心就是利用In关键字
要么用空间换时间，要么用时间换空间
多表连接的连接条件对索引的选择有着重要的意义，所以我们在写连接条件条件的时候需要特别注意。
A、多表连接的时候，连接条件必须写全，宁可重复，不要缺漏。
B、连接条件尽量使用聚集索引
C、注意ON、WHERE和HAVING部分条件的区别
ON是最先执行， WHERE次之，HAVING最后，因为ON是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，WHERE也应该比 HAVING快点的，因为它过滤数据后才进行SUM，在两个表联接时才用ON的，所以在一个表的时候，就剩下WHERE跟HAVING比较了
考虑联接优先顺序：
(1)INNER JOIN
(2)LEFT JOIN (注：RIGHT JOIN 用 LEFT JOIN 替代)
(3)CROSS JOIN
索引并不适用于所有情况：a.少量数据；b.频繁进行改动的字段，不适合做索引；c.很少使用的字段，不需要加索引
索引会提高数据查询效率，但是会降低“增、删、改”的效率。当不使用索引的时候，我们进行数据的增删改，只需要操作源表即可，但是当我们添加索引后，不仅需要修改源表，也需要再次修改索引，很麻烦。
先执行顺序, 是否走索引, 有无类型转换
18000 字的SQL优化大全
步步深入：MySQL架构总览->查询执行流程->SQL解析顺序
MySQL索引总结（4）——btree与hash区别
⑦ SQL优化（二）
SQL优化一： sql优化（一）
上片文章已经详细介绍了explain各个字段的含义，以及什么情况应该建立索引，什么情况不需要建立索引以及sql语句性能的判断依据，接下来我介绍下如何合理的建立索引。
sql语句：select id，author_id from article where category_id = 1 and comments>1 order by views desc limit 1;
分析：首先我们根据where后面的条件建立符合索引，然后根据order by后面的字段建立索引，因此建立索引idx_article_ccv，即以（category_id，comments，views）数据列建立复合索引，但由于comments是一个范围，按照BTree索引的原理，先排序category_id,如果遇到相同的category_id则再排序comments，如果遇到相同的comments则再排序views，又因为comments字段在复合索引里处于中间位置，而comments>1是一个条件（是一个范围值），在复合索引的一个范围值的数据列后面的索引全部失效，mysql无法利用索引再对后面的views部分进行检索，也就是说views无法按照索引排序，所以explain下此sql语句，type为range，extra使用的是Using filesort，这是比较糟糕的。所以我们放弃comments这个范围字段，建立索引idx_article_cv，即以（category_id，views）数据列建立复合索引，explain 此sql，type变成了ref，extra的using filesort也变成了using index，这就变得好多了。
索引：idx_article_cv，即以（category_id，views）数据列建立复合索引
前段时间做了一个销售精细化项目，是公司crm项目的一个大模块，大致就是为销售人员制定指标，实现销售目标从区域到团到业务员到客户，实时跟踪业务员所负责客户的下单量的情况。这就存在许多关联关系，区域-团，团-业务员，业务员-客户，这使得sql常常需要关联多张表。
sql语句：SELECT
tu.fuserid,
tu.faccount,
tu.fphone,
tu.fcertificationtype,
tu.fcertificatename,
tu.fkeyarea,
tu.fkeyareatext,
DATE_FORMAT(tcr.fupdatetime,'%Y-%m-%d %H:%i:%s') as fupdatetime,
tag.forggroupid,
tag.forggroupname,
tug.forguserid,
tug.fusername,
tug.fuserphone,
tag.fcitycode
FROM t_finedt_user AS tu
LEFT JOIN t_finedt_customer_relation AS tcr
ON tu.fuserid = tcr.fuserid
LEFT JOIN t_finedt_usergroup AS tug
ON tcr.forguserid = tug.forguserid
and tcr.forggroupid = tug.forggroupid
LEFT JOIN t_finedt_areagroup AS tag
ON tug.forggroupid = tag.forggroupid
where tu.fkeyarea=? and tu.fuserid=? and tug.forggroupid = ?
分析：上面的sql是左连接，左边的表一定是全表查询，所以要建立右边表对应关联字段的索引，在表t_finedt_user上建立tu_fuserid_fkeyarea索引，即以(fuserid，fkeyarea)字段建立索引，在表t_finedt_customer_relation 上建立tcr_forguserid_forggroupid索引，即以（forguserid，forggroupid）字段建立索引，在表t_finedt_usergroup 上建立tug_forguserid_forggroupid索引，即以（forguserid,forggroupid)字段建立索引，在表t_finedt_areagroup上建立tag_forggroupid索引，即以（forggroupid)字段建立索引。建立索引后，sql查询速度明显快了很多
索引：tcr_forguserid_forggroupid，tu_fuserid_fkeyarea，tug_forguserid_forggroupid，tag_forggroupid
1、尽可能减少join语句中的NestedLoop的循环次数，永远用小结果集驱动大结果集
2、优先优化NestedLoop的内层循环
3、保证join语句总被驱动表上的join字段已经被索引
4、当无法保证被驱动表join条件字段被索引，且内存资源充足的前提下，不要太吝啬joinBuffer的设置
1、全值匹配我最爱
2、最佳左前缀原则——如果索引了多列，要遵守最左前缀原则，指的是查询从索引的最左前列开始并且不跳过索引中的列
3、并在索引列上做任何操作（计算、函数、自动or手动类型转换），这些会导致索引失效而转向全表扫描
4、存储引擎不能使用索引中范围条件右边的列，范围之后的索引全失效
5、尽量使用覆盖索引（之访问索引的查询（索引列和查询的列一致）），减少select *
6、mysql在使用不等于（！=、>、<）的时候无法使用索引会导致全表扫描。
7、is null、is not null也无法使用索引。
8、like以通配符开头（"%abc.."），mysql索引失效也会变成全表扫描的操作。
9、字符串不加单引号也会引起索引失效
10、少用or，用它来连接时会索引失效。
1、对于单值索引，尽量选择针对当前query过滤性更好的索引
2、在选择组合索引的时候，当前query中过滤性最好的字段在索引字段顺序中，位置越靠前越好
3、在选择组合索引的时候，尽量选择尽可能包含当前query中的where字句中更多字段的索引
4、尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的。
全值匹配我最爱，最左前缀要遵守
带头大哥不能死，中间兄弟不能断
索引列上少计算，范围之后全失效
like百分写最右，覆盖索引不写里
不等空值还有or，索引失效要少用
var引号不可丢，sql高级也不难