优化成本：硬件>系统配置>数据库表结构>SQL 及索引。
优化效果：硬件<系统配置<数据库表结构<SQL 及索引。
首先，对于MySQL层优化我一般遵从五个原则：
减少数据访问：设置合理的字段类型，启用压缩，通过索引访问等减少磁盘 IO。
返回更少的数据：只返回需要的字段和数据分页处理，减少磁盘 IO 及网络 IO。
减少交互次数：批量 DML 操作，函数存储等减少数据连接次数。
减少服务器 CPU 开销：尽量减少数据库排序操作以及全表查询，减少 CPU 内存占用。
利用更多资源：使用表分区，可以增加并行操作，更大限度利用 CPU 资源。
总结到 SQL 优化中，就如下三点：
最大化利用索引。
尽可能避免全表扫描。
减少无效数据的查询。
对程序员来说SQL的顺序
1. SELECT
2. DISTINCT <select_list>
3. FROM <left_table>
4. <join_type> JOIN <right_table>
5. ON <join_condition>
6. WHERE <where_condition>
7. GROUP BY <group_by_list>
8. HAVING <having_condition>
9. ORDER BY <order_by_condition>
10.LIMIT <limit_number>
对于mysql来说sql的执行顺序
FROM
<表名> # 选取表，将多个表数据通过笛卡尔积变成一个表。
ON
<筛选条件> # 对笛卡尔积的虚表进行筛选
JOIN <join, left join, right join...>
<join表> # 指定join，用于添加数据到on之后的虚表中，例如left join会将左表的剩余数据添加到虚表中
WHERE
<where条件> # 对上述虚表进行筛选
GROUP BY
<分组条件> # 分组
<SUM()等聚合函数> # 用于having子句进行判断，在书写上这类聚合函数是写在having判断里面的
HAVING
<分组筛选> # 对分组后的结果进行聚合筛选
SELECT
<返回数据列表> # 返回的单列必须在group by子句中，聚合函数除外
DISTINCT
# 数据除重
ORDER BY
<排序条件> # 排序
LIMIT
<行数限制>
SQL优化的具体操作(避免不走索引的场景)：
1、在表中建立索引，优先考虑where、group by使用到的字段。
2、尽量避免使用select *，返回无用的字段会降低查询效率。如下：
SELECT * FROM t
优化方式：使用具体的字段代替*，只返回使用到的字段。
3、尽量避免使用in 和not in，会导致数据库引擎放弃索引进行全表扫描。如下：
SELECT * FROM t WHERE id IN (2,3)
SELECT * FROM t1 WHERE username IN (SELECT username FROM t2)
优化方式：如果是连续数值，可以用between代替。如下：
SELECT * FROM t WHERE id BETWEEN 2 AND 3
如果是子查询，可以用exists代替。如下：
SELECT * FROM t1 WHERE EXISTS (SELECT * FROM t2 WHERE t1.username = t2.username)
4、尽量避免使用or，会导致数据库引擎放弃索引进行全表扫描。如下：
SELECT * FROM t WHERE id = 1 OR id = 3
优化方式：可以用union代替or。如下：
SELECT * FROM t WHERE id = 1
UNION
SELECT * FROM t WHERE id = 3
（PS：如果or两边的字段是同一个，如例子中这样。貌似两种方式效率差不多，即使union扫描的是索引，or扫描的是全表）
5、尽量避免在字段开头模糊查询，会导致数据库引擎放弃索引进行全表扫描。如下：
SELECT * FROM t WHERE username LIKE '%li%'
优化方式：尽量在字段后面使用模糊查询。如下：
SELECT * FROM t WHERE username LIKE 'li%'
补充：
如果需求是要在前面使用模糊查询：
使用 MySQL 内置函数 INSTR（str，substr）来匹配，作用类似于 Java 中的 indexOf()，查询字符串出现的角标位置。
使用 FullText 全文索引，用 match against 检索。
数据量较大的情况，建议引用 ElasticSearch、Solr，亿级数据量检索速度秒级。
当表数据量较少（几千条儿那种），别整花里胡哨的，直接用 like '%xx%'。
6、尽量避免进行null值的判断，会导致数据库引擎放弃索引进行全表扫描。如下：
SELECT * FROM t WHERE score IS NULL
优化方式：可以给字段添加默认值0，对0值进行判断。如下：
SELECT * FROM t WHERE score = 0
7、尽量避免在where条件中等号的左侧进行表达式、函数操作，会导致数据库引擎放弃索引进行全表扫描。如下：
SELECT * FROM t2 WHERE score/10 = 9
SELECT * FROM t2 WHERE SUBSTR(username,1,2) = 'li'
优化方式：可以将表达式、函数操作移动到等号右侧。如下：
SELECT * FROM t2 WHERE score = 10*9
SELECT * FROM t2 WHERE username LIKE 'li%'
8、当数据量大时，避免使用where 1=1的条件。通常为了方便拼装查询条件，我们会默认使用该条件，数据库引擎会放弃索引进行全表扫描。如下：
SELECT * FROM t WHERE 1=1
优化方式：用代码拼装sql时进行判断，没where加where，有where加and。
9.查询条件不能用 <> 或者 !=
使用索引列作为条件进行查询时，需要避免使用<>或者!=等判断条件。
如确实业务需要，使用到不等于符号，需要在重新评估索引建立，避免在此字段上建立索引，改由查询条件中其他索引字段代替。
10.where 条件仅包含复合索引非前置列
如下：复合（联合）索引包含 key_part1，key_part2，key_part3 三列，但 SQL 语句没有包含索引前置列"key_part1"，按照 MySQL 联合索引的最左匹配原则，不会走联合索引。
select col1 from table where key_part2=1 and key_part3=2
11.隐式类型转换造成不使用索引
如下 SQL 语句由于索引对列类型为 varchar，但给定的值为数值，涉及隐式类型转换，造成不能正确走索引。
select col1 from table where col_varchar=123;
12.order by 条件要与 where 中条件一致，否则 order by 不会利用索引进行排序
-- 不走age索引
SELECT * FROM t order by age;
-- 走age索引
SELECT * FROM t where age > 0 order by age;
对于上面的语句，数据库的处理顺序是：
第一步：根据 where 条件和统计信息生成执行计划，得到数据。
第二步：将得到的数据排序。当执行处理数据（order by）时，数据库会先查看第一步的执行计划，看 order by 的字段是否在执行计划中利用了索引。如果是，则可以利用索引顺序而直接取得已经排好序的数据。如果不是，则重新进行排序操作。
第三步：返回排序后的数据。
当 order by 中的字段出现在 where 条件中时，才会利用索引而不再二次排序，更准确的说，order by 中的字段在执行计划中利用了索引时，不用排序操作。
这个结论不仅对 order by 有效，对其他需要排序的操作也有效。比如 group by 、union 、distinct 等。
13.正确使用 hint 优化语句
MySQL 中可以使用 hint 指定优化器在执行时选择或忽略特定的索引。
一般而言，处于版本变更带来的表结构索引变化，更建议避免使用 hint，而是通过 Analyze table 多收集统计信息。
但在特定场合下，指定 hint 可以排除其他索引干扰而指定更优的执行计划：
USE INDEX 在你查询语句中表名的后面，添加 USE INDEX 来提供希望 MySQL 去参考的索引列表，就可以让 MySQL 不再考虑其他可用的索引。
例子: SELECT col1 FROM table USE INDEX (mod_time, name)...
IGNORE INDEX 如果只是单纯的想让 MySQL 忽略一个或者多个索引，可以使用 IGNORE INDEX 作为 Hint。
例子: SELECT col1 FROM table IGNORE INDEX (priority) ...
FORCE INDEX 为强制 MySQL 使用一个特定的索引，可在查询中使用FORCE INDEX 作为 Hint。
例子: SELECT col1 FROM table FORCE INDEX (mod_time) ...
在查询的时候，数据库系统会自动分析查询语句，并选择一个最合适的索引。但是很多时候，数据库系统的查询优化器并不一定总是能使用最优索引。
如果我们知道如何选择索引，可以使用 FORCE INDEX 强制查询使用指定的索引。
例如：
SELECT * FROM students FORCE INDEX (idx_class_id) WHERE class_id = 1 ORDER BY id DESC;
14.SELECT 语句其他优化
**避免出现 select ***
首先，select * 操作在任何类型数据库中都不是一个好的 SQL 编写习惯。
使用 select * 取出全部列，**会让优化器无法完成索引覆盖扫描这类优化**，会影响优化器对执行计划的选择，也会增加网络带宽消耗，更会带来额外的 I/O，内存和 CPU 消耗。
建议提出业务实际需要的列数，将指定列名以取代 select *。
增加查询分析器解析成本。
增减字段容易与 resultMap 配置不一致。
无用字段增加网络 消耗，尤其是 text 类型的字段。
②避免出现不确定结果的函数
特定针对主从复制这类业务场景。由于原理上从库复制的是主库执行的语句，使用如 now()、rand()、sysdate()、current_user() 等不确定结果的函数很容易导致主库与从库相应的数据不一致。
另外不确定值的函数，产生的 SQL 语句无法利用 query cache。
③多表关联查询时，小表在前，大表在后
在 MySQL 中，执行 from 后的表关联查询是从左往右执行的（Oracle 相反），第一张表会涉及到全表扫描。
所以将小表放在前面，先扫小表，扫描快效率较高，在扫描后面的大表，或许只扫描大表的前 100 行就符合返回条件并 return 了。
例如：表 1 有 50 条数据，表 2 有 30 亿条数据；如果全表扫描表 2，你品，那就先去吃个饭再说吧是吧。
④使用表的别名
当在 SQL 语句中连接多个表时，请使用表的别名并把别名前缀于每个列名上。这样就可以减少解析的时间并减少哪些有列名歧义引起的语法错误。
⑤用 where 字句替换 HAVING 字句
避免使用 HAVING 字句，因为 HAVING 只会在检索出所有记录之后才对结果集进行过滤，而 where 则是在聚合前刷选记录，如果能通过 where 字句限制记录的数目，那就能减少这方面的开销。
HAVING 中的条件一般用于聚合函数的过滤，**除此之外**，应该将条件写在 where 字句中。
where 和 having 的区别：where 后面不能使用组函数（聚合函数）。
⑥调整 Where 字句中的连接顺序
MySQL 采用从左往右，自上而下的顺序解析 where 子句。根据这个原理，应将过滤数据多的条件往前放，最快速度缩小结果集。
15.联合索引的优势
联合索引的优势有如下三个：
①减少开销
建一个联合索引（a，b，c），实际相当于建了（a）、（a，b）、（a，b，c）三个索引。
每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大的减少开销！
②覆盖索引
对联合索引（a，b，c），如果有如下 SQL 的：
SELECT a,b,c from table where a='xx' and b = 'xx';
那么 MySQL 可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机 IO 操作。
减少 IO 操作，特别是随机 IO 其实是 DBA 主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。
③效率高
索引列多，通过联合索引筛选出的数据越少。比如有 1000W 条数据的表，有如下 SQL：
select col1,col2,col3 from table where col1=1 and col2=2 and col3=3;
假设：假设每个条件可以筛选出 10% 的数据。
A：如果只有单列索引，那么通过该索引能筛选出 1000W10%=100w 条数据，然后再回表从 100W 条数据中找到符合 col2=2 and col3= 3 的数据，然后再排序，再分页，以此类推（递归）。
B：如果是（col1，col2，col3）联合索引，通过三列索引筛选出 1000W10% 10% *10%=1W，效率提升可想而知！
16.索引是建的越多越好吗？答案自然是否定的：
数据量小的表不需要建立索引，建立会增加额外的索引开销。
不经常引用的列不要建立索引，因为不常用，即使建立了索引也没有多大意义。
经常频繁更新的列不要建立索引，因为肯定会影响插入或更新的效率。
数据重复且分布平均的字段，因此他建立索引就没有太大的效果（例如性别字段，只有男女，不适合建立索引）。
数据变更需要维护索引，意味着索引越多维护成本越高。
更多的索引也需要更多的存储空间。