背景
项目使用mysql数据库，某张表数据量2000W左右，比较大，在组合查询时发生超时，需要优化。
优化
查询优化常用方法就是建立索引
查询语句样例：查询在20181001-20181010时间范围内A=a且B=b的数据
select * from table where A = 'a' and B = 'b' and Date > '20181001' and Date < '20181010'
按照查询建立了一个组合索引 idx_query(A, B, Date)，查询仍然报超时。然后开始研究索引原理，最后更改索引中列的顺序为idx_query(B,A,Date)解决。
---------------------------------------------------------------------------------------------
上面只是简单的项目背景，下面从原理细细解读索引
索引原理
首先，出问题以后再建立索引，是一种不好的习惯。排查、定位、解决问题会耗费很多开发时间和精力。
当然，不充分思考就给大多数列建立单列索引，给所有查询建立联合索引，是一种更坏的习惯。毕竟删除索引风险远高于添加索引。
使用索引需要成本：
- 空间成本：索引是占空间的，大表的联合索引占用空间不可忽略
- 时间成本：使用不对的索引会浪费时间
- 更新成本：增删改操作只要跟索引有关系，就需要更新索引
索引适合在返回大表中很小一部分数据时使用，很小当然越小越好，5%以下还可以，1%以下更好，如果表的数据量非常大，千万级别，返回行数要小到0.1%以下
从很大表中用联合条件查询出很小的数据，等价于count(distinct 联合条件) 的值很大，这个值被称为Cardinality，索引适合度=Cardinality/表记录数。
索引误区
多个单列索引(如idx_A, idx_B)不等同于联合索引(idx_A_B)
两个联合索引里的列顺序不同，这两个联合索引也不等价，适用场景不同
联合索引idx_A_B能够覆盖的场景
- A = ？ and B = ？
- A = ？ and B in (?, ?, ?)
- A = ?
- A in (?,?,?)
覆盖场景可以根据索引存储结构(B+Tree)推导出。
上面罗列的几种覆盖场景，效率由上至下越来越低，因为扫描行数越来越大
联合条件中，最左侧的索引列很重要，最好使用Cardinality最大的列。
总结
项目中遇到的问题，最终根据索引原理中 最左侧索引列使用Cardinality最大列 解决。