MySQL,合理的使用索引结构和查询( 二 ) _MySQL

错位符：防止订单号被分析，会随机一段错位符号；

如此一段分析下来，实际订单号是非常长的，所以需要引入前缀索引机制，前缀索引期望使用的索引长度可以筛选整个列的基数，例如上面的订单号：

大部分业务基于时间节点筛选足够，即索引长度14位；
如果是并发业务，很多时间节点相同，则索引长度是时间点+标识位；

注意：如果业务允许的情况下，一般要求前缀索引的长度有唯一性，例如上面的时间和标示位。
4、其他索引例如全文索引等，这些用到的场景不多，如果数据庞大，又需要检索等，通常会选择强大的搜索中间件来处理。显式唯一索引，这种也会在程序上做规避，避免不友好的异常被抛出。
三、索引查询如何创建最优的索引，是一件不容易的事情，同样在查询的时候，是否使用索引也是一件难度极大的事情，经验之谈：多数是性能问题暴露的时候，才会回头审视查询的SQL语句，针对性能问题，做相应的查询优化。
1、单列查询这里直接查询主键索引，MySQL的主键一般选择自增，所以速度非常快。

EXPLAIN SELECT * FROM ds_order WHERE id=2;EXPLAIN SELECT * FROM ds_order WHERE id=1+1;EXPLAIN SELECT * FROM ds_order WHERE id+1=1;

这里，id=2,id=1+1，MySQL都可以自动解析，但是id+1是在索引列上执行运算，直接导致主键索引失效。这里有一个基本策略，如果非要在单列索引上做操作，可以将该逻辑放在程序中，到MySQL层面，SQL语句越干净利落越好。
2、前缀索引查询前缀索引的查询，可以基于Like对特定长度筛选，或者全订单号查询。

EXPLAIN SELECT * FROM ds_order WHERE order_no LIKE '202008011314158723628732871625%';EXPLAIN SELECT * FROM ds_order WHERE order_no='20200801131415872362873287162572367';

3、组合索引查询查询最麻烦的就是组合索引，或者说查询条件组合起来，都使用了索引：
EXPLAIN SELECT * FROM ds_order WHERE create_time>'2020-08-01 00:00:00' AND order_state='1';上述基于组合索引中列的顺序，使用了组合索引：state_create_time_index 。
EXPLAIN SELECT * FROM ds_order WHERE create_time>'2020-08-01 00:00:00';上述只使用create_time列，也同样使用了索引结构。
EXPLAIN SELECT * FROM ds_order WHERE order_state='1';上述如果只使用order_state条件，则结果显示全表扫描。
EXPLAIN SELECT * FROM ds_order WHERE create_time>'2020-08-01 00:00:00' AND order_no LIKE '20200801%';上述则基于组合索引的create_time列和单列索引order_no保证查询条件都使用了索引。
通过上面几个查询案例，索引组合索引使用的注意事项如下：

组合索引必须按索引最左列开始查询；
不能跳过组合字段查询,这样无法使用索引；

四、索引其他说明1、索引的优点

基于注解或唯一索引保证数据库表中数据的唯一性；
索引通过减少扫描表的行数提高查询的效率；

2、索引的缺点

创建索引和维护索引，会耗费空间和实际；
查询以外的操作增删改等，都需要动态维护索引；

3、索引使用总结索引机制在MySQL中真的非常复杂，非专业的DBA(就是指开发人员)，基本要熟练常见的索引结构，待过两年所谓的大厂，每个版本开发涉及的核心表SQL都是有专业DBA验收，复杂的查询都是提交需求，DBA直接输出查询SQL，当然在一般公司是没有DBA，需要开发在开发的过程中不断的思考，逐步优化，这需要对业务数据有一定的敏感度，对核心接口有执行监控，当发现稍微出现耗时情况，就可以不断优化，这个积累是个枯燥和进步的过程。

【MySQL,合理的使用索引结构和查询】