mysql 高性能日记之索引（持续更新）

本文仅限于本身读写的笔记，须要具备必定 mysql（inodb,myisam 引擎）基础的高端玩家，不感兴趣的玩家们就不用在乎了

Inodb 引擎

1，每一个新建索引，都须要考虑清楚看是不是必须的，不少新建的索引不只不会提升 sql 语句的效率，反而会增长维护索引的成本

     对于 Inodb 的 B-Tree，若是是非聚簇索引，每次检索都须要进行两次（自己+主键，此处不过多解释），因此当存在索引 (B)，A是主键，就没有必要再创建索引（B, A），除非须要 order by a 才须要用到组合索引。

MyISAM 引擎

1，默认开启索引前缀压缩，对于 CPU 密集型业务须要手动关闭该功能，MyISAM 为了下降 IO 的压力，将索引块进行前缀压缩，好比 "aaaa"-"aaaabbb" 两个索引块在内存中为 "aaaa"-"4.bbb"，解压时会消耗必定的 CPU 算力。

公共问题

1，扩展索引时，也须要考虑是否会影响到旧索引的性能

     本来存在索引(A，qps 超高)，为了整合索引，将 B(VCHAR1024) 加入原索引构成新索引（A, B）,因为加入新的列（新列超长，会极大影响到旧查询效率）。

2，对于两个表 A {primary_key: app_id，column:xxx}；B {primary_key: account_id，app_id}，其中 A 表的 app_id 和 B 表的 app_id 是同一个属性，若是业务给定一个 account_id，须要返回这个用户下的全部 app 信息，相信很多同窗会这样写

      a. select * from A where app_id in (select app_id from B where account_id = %d)

      b. select * from A join (select app_id from B where account_id = %d) as C using (app_id)

      上述两种写法应该是大部分开发者都会优先考虑的 sql 语句（正向思惟），但 Mysql 优化器并不会优化上面两种 sql 语句，而是会按从左到右的顺序，现对 A 表进行全表遍历，而后与 B 表查出的数据进行 using 比较返回有效数据。因此须要你们反向去写 sql 语句。

      c. select * from B where account_id = %d join (select * from A) as C using (app_id)

      固然，若是在两个表中都没有可供 where 使用的有效索引，那就老老实实全表遍历吧。