同乐学堂优点：
1、大大减少对服务器扫描的数据量
2、避免排序和临时表
3、可以将随机IO,变为顺序IO
缺点：会消耗磁盘空间，让插入，更新、删除，变慢。
适用于：中大型表。
补充：在特大表的情况下，如索引优化已达到瓶颈，且前端应用程序无法进行调优SQL,以及没有使用分库分表的技术考量量下，可以使用数据库的分区技术，来减少对MySQL表的大范围扫描。来补充索引的不足！
《数据库索引设计优化》
多年来，不合适的索引是性能低下最常见的原因。最普遍的问题似乎是没有足够多的索引列来支持WHERE字句中的所有谓词（备注：条件语句中的字段叫谓词）。
普遍的情况是表上没有足够多的索引。一些Select语句可能没有有效的索引，有时索引上包含了正确的列，但列的顺序却不对，
在关系型数据库中改进索引是相对容易的，因为不需要进行任何程序上的修改、然而，对生产系统的改动总会带来一些风险，此外当一个索引正在被创建的时候。更新程序可能会经历长时间等待。
例如：无法更新为了创建索引而正在被扫描的表。再加上为了让新应用从投产第一天开就就达到可接受的性能，所以在投产之前索引就应该处于相当良好的状态。索引应当在系统投产后不就就被固定下来，而不再需要大量的实验。
建议不要给表的索引数量设置上限，保证所有sql语句都能够流畅运行是设计的底线。（MySQL单表索引数量上限是16个）
系统化的索引设计
预测每个字段读取和更新的频率，以及包含这些字段的记录的插入、删除频率。
未来：采集生产环境的工作负载样本，然后在该工作负载下为Select语句生成一组候选索引。
随后，用一些简单的评估公式或一个基于成本的优化器来决定哪些索引是最有价值的。
首先找到运行非常慢的查询、然后设计索引让缓慢的查询变得足够快，并且不导致其他SQL调用明显变慢。
两个观点：
1、找到由于索引不合适而导致运行太慢的查询语句
2、设计索引，让所有查询语句都运行的足够快。（表的维护（插入、更新、删除）也必须足够快）。
很多调优人员认为，如果一个sql语句使用了索引，那这个sql就是被很好的优化过了，但是使用一个不合适的索引有可能会导致比全表扫描更差的性能。
什么是不合适的索引。
首先我们将这里跟索引的优劣分为三个等级，叫1星，2星，3星。
1星：如果一个查询相关的索引行是相邻的，或者至少相距足够靠近的话，那么这个索引就可以被标记上第一颗星。（最小化了必须扫描索引片的宽度）
2星：如果索引行的顺序与查询语句的需求一致，则索引可以被标记上第二颗星。（这排除了排序操作）
3星：如果索引行包含查询语句中的所有列，那么可以被标记上第三颗星。（这颗星是最重要的 ，将一个列排除在外可能会导致速度较慢的磁盘随机读）
包含三颗星的索引，也叫宽索引。该索引包含了SELECT 语句所涉及的所有列，因此能够使得查询只需访问索引而无须访问表。
为了满足三颗星，
索引优化套路1：
1、取出所有等值相邻的谓词列*（就是带等于号的条件语句，），把这些列作为索引最开头的列。
2、用Order by 列加入到索引中，保证查询语句与索引列顺序一致。（ order by 只能排序索引列，要不然会发生全表扫描）
3、将查询语句剩余的列，添加到索引当中，列在索引当中添加的顺序对查询性能没有影响，将易变的列放在最后能降低更新的成本。
索引优化套路2：
1、在查询的所有列上设计索引。
2、如果业务必须要把模糊和范围查询，类似于between这种放在where的首个条件语句，在设计多列索引的时候，一定要把查询范围较窄的字段放在最前面，范围查询最大字段放到最后，index（查询范围最窄的放到最前面,范围查询的列放在最后面）
顶上都是单表的，现在我们设计多表连接查询的索引
为连接查询设计合适的索引比为单表查询设计索引，更加困难，因为表的连接接方式及表的访问顺序对索引影响很大。单表的索引设计以及优化套路，同样适用多表的，只是多表需要进行一些额外的考量。
连接查询中有两类谓词，为本地谓词，和连接谓词。只用于访问一张表的谓词成为本地谓词，定义了表和表关系之间的谓词称为连接谓词。
大部分优化器是通过评估各种可行方案的本地响应时间来决定采用哪种连接方式和表访问顺序的。尽管 随着顺序读速度的提高，哈希连接和合并扫描连接变得越来越流行，但嵌套连接依旧是最常用的连接方式。
若使用连接查询的方式，则表访问的顺序是由优化器来做决定的。若使用连接查询的方式，则表的访问顺序是由优化器来做决定的 。
连接谓词大部分是基于 主键==外键 这一条件的。
连接查询，分为内层表和外层表，由外层做为查询起始点。
区分：没有本地谓词的表，叫做外层表，否则连接查询的另一张表为外层表。
参考了：MySQL高性能第三版
数据库索引设计与优化
微信扫一扫，打赏作者吧～
