a：通过SQL查询信息： select * from sp_tunnel_user where cust_third_acct like'0200%'; 以下就是满足查询条件的部分信息
b：分析Like'%xxxx%'的查询性能： select * from sp_tunnel_user where cust_third_acct like'%0200%'; 通过Explain性能分析命令可以知道：在这种查询条件下并没有执行索引，type=all表明该语句执行的时候进行的是全表扫描；虽然我们在 cust_third_acct 这个字段建立了索引，但是 possible_keys=null 则说明了 用 like'%0200%' 这种形式的条件是一定无法使用到 cust_third_acct_index 这个索引。(其他字段的解析请参照《MySQL优化之Explain命令解读》这篇文章，这里不做过多的分析)。
c：分析Like'xxxx%'的查询性能： select * from sp_tunnel_user where cust_third_acct like'0200%'; 与b查询语句相比这个查询的 possible_keys=cust_third_acct_index ，这说明这个语句可能会用到 cust_third_acct_index 这个索引，但是key=null表明在实际的执行过程中并没有用到 cust_third_acct_index 索引；刚才我们也说了这种条件查询只是可能会走索引但是不一定发生，这个跟MySQL的存储引擎相关，但是我们使用的时候尽量以这种方式去查询。
4. 使用索引遵循最佳左前缀特性，建立联合索引的时候将常用的属性放在左边。比如：我们需在在一张表的 cust_id 和 cust_tp 建立一个联合索引 cust_id_type,设定cust_id（不是唯一） 是比较常用的那么我们就将cust_id放在左边。
建立联合索引：
-- 为cust_id与cust_tp建立一个联合索引
alter table
cust_info
add index cust_id_type(cust_id,cust_tp);
5.使用符合索引的时候需要注意：使用联合索引需要从左往右不间断，索引才会生效，也就是说联合索引使用的时候必须要连续但不要求全部使用。如：以上4我们建立了一个 cust_id_type 索引,当我们在使用的时候如果where条件中只使用了 cust_id,那么也会走索引；如果where条件中只使用了 cust_tp，那么这条语句不会走索引，以下就是一个实例：
a：select * from sp_tunnel_user where cust_id='8888888888' and cust_tp='04'； 当查询条件用到cust_id与cust_tp两个字段并且cust_id在前面的时候，就会用到联合索引；通过 key=cust_id_type可以看到实际执行过程中是用到索引了的。
b：select * from sp_tunnel_user where cust_id='8888888888' ; 当查询条件只用到cust_id一个字段时，也用到了联合索引；通过 key=cust_id_type可以看到实际执行过程中是用到索引了的，这就是左前缀原则。
c：select * from sp_tunnel_user where cust_tp='04' ; 当查询条件只用到cust_tp一个字段时，但却没有用到索引；通过 key=null 可以看到实际执行过程并没有用到索引，这也是左前缀原则。
优化之三 - 读写分离与分库分表