mysql创建索引的原则是对于那些区别度高字段建立索引，区别度越高的索引，在数据量大的情况下，索引效果越好。
因为mysql建立b+树时是这样，每创建一行就新建立索引字段，如果需要对枚举类型的字段进行搜索的时候比如该字段是布尔型只有两种值，对这种值进行搜索即使建立了索引效果仍然不好，如果一张表有千万数据，其中有
五百万数据是该值为true，需要搜索表中为true的数据，即使扫描索引，也要扫描500万次。
而es则不同，es建立的倒排索引是索引值后面跟了一个倒排列表，也就是只需要最多扫描两次便能找到数据。
当搜索的条件足够复杂后，比如10多个条件字段的搜索，由于b+树的特性，不可能同时对这10多个字段建立联合索引，此时用上es就很合适。es可以将10多个条件字段求出各自的bitmap，然后求交集。
es针对海量数据的存储与搜索的好处在于，其水平扩容的便捷性。
mysql在数据量大了以后，涉及到分库分表，而分库分表带来的问题的是什么？其一是分库分表时，数据的迁移，需要考虑迁移过程中业务是否受到影响。其二在于 分库分表后业务系统的改动，比如翻页逻辑，可能需要去到每个库或表中查出前n条数据，然后进行翻页。
而es将扩容部分的这些都做了，es存数据是天然的分片存储，在海量数据查询时，可以通过增加副本的机制分担读压力。
当然不是，来说说选用es的问题。
es比较吃系统资源。
来看一组数据，虽然环境有差异，可能不太准确，但能说明一定问题。
一台4c8g的 linux 云数据库，能支持大约上万qps，内存占用大概6g。
而我用一台mac m1 的8c 16g机器去做查询压测，当qps达到3700时，cpu就已经去到480% 超过了4核。
所以在产品并发量不高的情况下，只从数据存储而言，选用mysql会更节约成本。
但是单机的性能的确有限，如果产品对数据库的qps需要去到好几万，即使选用最高配的机器也是无法支撑的，这时选用多台便宜的机器来做将数据做分布式存储将更有优势。
所以我认为，当查询量越来越大以后，选用es来做海量数据存储，将不会担心数据查询问题，随着查询压力的上涨，可以通过增加副本来解决，虽然mysql可以通过分库分表解决，但是正如前面而言，分库分表的成本是比较大且风险是高于es扩容的，es增加副本带来的分片数据迁移工作，是由es集群自身完成，这样对于整个架构的扩展性来说是最高效便捷的。
感叹一句，架构就是这样，有得必有失，带来了架构的便捷性，但是可能对于mysql分库分表方案会更贵一点。