（1）分组介绍：
    假如SQL语句 select count(*) from table group by xx ，似乎必须把所有的数据都放到一个临时磁盘文件里还需加上部分内存，做一个分组，按照指定字段的值分成一组，接着对 每一组都执行聚合函数，这个性能极差，涉及大量的磁盘操作。
    因为我们的索引树里默认都是按照指定的一些字段排好序的，字段值相同的数据都是在一起的，假如走索引执行分组后在聚合，性能一定比在临时磁盘文件里执行好多了。

    （2）分组排序：
    通常而言，对于group by后的字段，最好也是按照联合索引里的最左侧的字段开始，按顺序排列，这样的话，就可以运用上索引直接提取一组组的数据，然后针对每一组的数据执行聚合函数 就好了，其实group by和order by用上索引的原理和条件都差不多，本质上都是group by 和 order by之后的字段顺序和联合索引中的从最左侧开始的字段顺序一致，就可以充分利用索引树里已经 完成排序的特性，快速根据排好序的数据执行后续操作。

    1. 这样就不需要针对杂乱的数据利用临时磁盘文件加上部分内存数据结构进行现场排序和分组了，所以设计表里的索引时必须充分考虑到后续的SQL语句怎么写，然后考虑好之后，就可以为表

    设计两三个常用的索引，覆盖常见的where筛选，order by排序和group by 排序分组的需求。保证常见的SQL语句都可以用上索引，真正系统跑起来的时候，起码不会有太大的查询性能问题。如果还是 有查询问题，那就要深度理解查询的执行计划和执行原理，然后基于执行计划来进行深度SQL调优。

    （3）对于更新语句：
    最核心三大问题：一是索引不要太多，索引太多，更新的时候维护很多索引树肯定是不行的，
    二是可能会涉及到一些锁等待和死锁的问题，
    三是可能涉及到MySQL连接池，写redo log文件 之类的问题。

    后续课程：
    （A） 查询这块的一些普通场景，回表问题，覆盖索引，基于电商的实际场景的一些实例如何保证设计的索引性能不会太差。
    （B）查询语句的执行计划，深度SQL调优原理及一些实战案例，再就是更新时候遇到的一些问题包括索引，锁问题，写磁盘等等问题及对应的实战案例，这些都搞定后数据库日常的索引设计，查询 和更新的优化基本也都没问题了。
    （C） 接着就是数据库高阶场景，包括数据库的备份和恢复，主从架构和读写分离，高可用架构，分库分表架构。