如果这么写，就算在orders表里面去创建的company_name的索引，比如这里就已经创建好了，上面的SQL实在也不会走索引，由于它不符合最左前缀原则，即是这边是%号。
怎么优化？一样平常先只管即便的去看能不能利用索引条件下推。什么意思？比如再看表里面实在还有一个字段，还有一个created_at的字段，就表示订单的创建韶光。如果现在再来创建一个索引，大家可以看一下下边的索引，它是针对created_at和company name去创建的联合索引，以是把稳company name在后面。
现在假设还是来找订单，但是比如就查本日的订单，其实在后面再跟上公司名字再来试一下，就能够走到刚刚所创建的联合。把稳后面extra这里就有一个using index condition，这就表示它利用了索引条件。索引条件什么意思？是这个意思。
知道联合索引实在对应的便是一棵B+树，当实行sql的时候，它会先按照create at的条件，比如是本日，就会根据B+树去找，找到B+树的符合当前日期的所有的叶子节点。拿到叶子节点之后，再见根据company_name这里给的条件去进行筛选，从叶子节点里面再筛选出来一部分，再把这一部分的主键ID拿出来。去主键索引上面再去回表。
以是全体过程company_name实在还是起到了一定的浸染的。由于这样子相称于如果加上这个条件或者里面包含的字段，其他回表的时候是能够回表的次数能够减少的，从而能够提高效率。
以是在支持查询功能的时候可以考虑一下，就算这里是旁边两边都是模糊查询，实在也不是一定不能把它放到索引里面去，实在放进去可能还是会有一些些好处的。
当然在实际事情中，假设根本没办法再针对company_name那样去建联合索引，这种就没有什么办法，由于没办法去做索引。当然如果还是可以利用一些其他的，比如覆盖索引，实在还是能够利用的。但是这种说白了效率也没有那么高。
由于一样平常肯定会除开company_name字段之外，还会去查一些其他的字段的，这样子也没有办法利用索引扫描。以是实在弗成可以先试一下mysql里面的全文索引，全文索引紧张便是用来支持模糊查询的。如果创造全文索引不太好，再去考虑ES之类的。
喜好就点个关注吧。
