1.回表： 回到主键索引树搜索的过程，我们称为回表，就是对非主键数据进行查询，内部执行是对这个内容的ID再去查询一边其他信息。 2.覆盖索引： 由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的 性能优化手段。这是mysql每个结构都是除ID，其他列上是对内容为键，ID为值，覆盖索引就是对他内容的值直接输出，不需要再进行回表操作。 3.在建立联合索引的时候，如何安排 索引内的字段顺序：

• 第一原则是，如果通过调 整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的
• 第二原则，考虑的原则就是空间了，比如：name 字段是比 age 字段大的 ，那我就建议你创建一个（name,age) 的联合索引和一个 (age) 的单字段索 引。

4.索引下 推： MySQL 5.6 引入的索引下推优化，可以在索引遍历过 程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。比如：我们有一个聚合索引（name,age）我们查询 name为 张三 ，age 为20 mysql5.6之后会对name和age都会到聚合索引查出符合条件的再进行回表查出所有数据。 5.索引理解：     1.索引的作用：提高数据查询效率     2.常见索引模型：哈希表、有序数组、搜索树     理解： 每一张表其实就是多个B+树，树结点的key值就是某一行的主 键，value是该行的其他数据。新建索引就是新增一个B+树，查询不走索引就是遍历主 B+树。 6.mysql优化器 而优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。在数 据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的 次数越少，消耗的 CPU 资源越少。 索引基数差别与实际比较大，会影响预计扫描行数导致性能不行，我们可以通过 analyze table t 命令对索引 重新统计索引信息，再执行sql 所扫描的行数就会发生变化。 7.mysql执行选错索引影响性能 如： explain select * from t where (a between 1 and 1000) and (b between 50000 and 100000） 上面执行计划会使用b索引扫描更多的行影响性能。 1.我们可以采用 force index 强行选择一个索引 select * from t force index(a)  where  (a between 1 and 1000) and (b between 50000 and 100000） 但是force index 对数据迁移或者修改索引有影响。 2.我们可以考虑修 改语句，引导 MySQL 使用我们期望的索引 （符合业务） 3.我们可以在有些场景下，我们可以新建一个更合适的索引，来提供给优化器做选择， 或删掉误用的索引。（ 符合业务） 8.使用前缀索引还是使用普通索引的利弊 1.使用前缀索引是对索引字段进行取设置范围的前缀的值，当我们查询这个索引的值时，前缀满足条件我们还有回表判断全文内容是否和我们提交是否一致，不一致再循环以上操作得出索引集。扫描次数会有所提高性能就会慢一些而且不能使用覆盖索引了，应为前缀索取必须要回表进行判断是否满足条件。优点就是可以节省空间。 2.普通索引因为是全文字段的数据，所以扫描次数是固定的，并且不需要再回表判断是否满足条件，也可以配合覆盖索引使用。 9.对于身份证等区分度不高的字段上的索引优化 第一种就是使用倒序存储身份证号码，应为身份证前几位区分度不够高。 第二种方式是使用 hash 字段，建立一个字段 crc32() 整数的索引，但是crc32容易发生碰撞所以你查询时再把你之前的值也加上来避免查出数据出问题。如 SELECT * FROM urls WHERE crc_url = 907060870 AND url = 'hello' 二种方式的异同点： 1. 从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。当然，倒序存储方式使用 4 个字节的前缀长度应该是 不够的，如果再长一点，这个消耗跟额外这个 hash 字段也差不多抵消了。 2. 在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。如果只从这两个函数的计算复杂度来 看的话，reverse 函数额外消耗的 CPU 资源会更小些。 3. 从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来 的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。 而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。 实践中你不要忘记使用 count(distinct) 方法去做个区分度验证。 10.Mysql为什么drop数据内存不会减少 应为 表数据既可以存在共享表空间里，也可以是单独的文件。 可以通过 参数 innodb_file_per_table参数来控制

•  这个参数设置为 OFF 表示的是，表的数据放在系统共享表空间，也就是跟数据字典放在 一起； 而如果是放在共享表空间中，即使表删掉了，空间也是不会回收的
• 这个参数设置为 ON 表示的是，每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件 中。

将 innodb_file_per_table 设置为 ON，是推荐做法。 11.应为mysql使用inodb引擎大量增删改产生了大量的空洞占用资源。 可以使用 alter table A engine=InnoDB 命令来重建表 MySQL 5.5 及之前的版本，这个命令是会阻塞 DML 的，这个你需要特别小心。 12.mysql 中sql排序 全字段排序 VS rowid 排序

• 如果 MySQL 实在是担心排序内存太小，会影响排序效率，才会采用 rowid 排序算法，这 样排序过程中一次可以排序更多行，但是需要再回到原表去取数据。
• 如果 MySQL 认为内存足够大，会优先选择全字段排序，把需要的字段（包含查询字段）都放到 sort_buffer 中，这样排序后就会直接从内存里面返回查询结果了，不用再回到原表去取数据。

还有一种思路就是判断字段和排序字段组成联合索引，因为索引本身就是有序的，只要把数据取出来就好了，不需要再回表了，如果你的查询字段有这二个之外的字段还是要进行回表然后查出查询需要的字段。 ---未完待更新