记录一次mongodb写入报错

报错日志关键字：insert: key too large to index
大概意思就是做索引的字段内容太长，用它建索引的时候，创建失败并报错了。直接的结果就是写入失败！这个不能忍！！网上搜索了一下，大概有三个解决思路：
    1、调整这个长度限制：官网翻了个底朝天，没有提到可以修改这个参数的方法。
    2、更改索引的数据类型为hashed或者text。
    3、通过调整启动参数，让错误不报。
方案1就不说了，行不通。下面主要记录一下方案2和3的处理过程：
方案2：
    首先尝试使用hasded索引，但是经过尝试，得知，联合索引不可以使用hashed索引，这个路径走不通。
    然后尝试使用text类型索引，嗯~不错可以不报错，正确写入表中，也可以查询出来。但是还有些放心不下，于是，做了个性能对比测试。直接说结果吧：
    text索引在百万记录的查询场景下，和没建索引没有明显区别，性能比联合索引查很多。于是这个也是等待被pass。PS:查询条件的一个字段使用了正则，而且不是头匹配（
    正则只有头匹配的时候可能命中索引）
    出于好奇，如果只对查询条件的一个字段做索引，会不会在不影响性能的前提下解决报错呢，于是实事求是的测试了一番。结论：排除了超长字段报错的影响，
    性能比无索引的情况要快，但是比联合索引慢，这个地方始终没想通，不是说正则且不是头匹配的情况不会命中索引吗！？
方案3：
    这个比较简单，修改一下启动命令，加上--setParameter failIndexKeyTooLong=false ，果然，也是不报错了。查看了一下也能写入，但是使用组合条件查询的时候，
    没有查到结果，超长的数据都没有结果（不超长的还是可以查到的），这个不能接受，数据写进去了，浪费了存储还查不着，果断放弃这种方案。
总结：
    目前看，是没有完美的解决方法，最终怎么做，要看。如果数据重要，那就牺牲一下性能，换掉联合索引；如果性能重要，那就有两种选择，存储不是事儿就该启动参数，动代码发方便就，在持久化的时候过滤掉这部分数据。
    PS:这个超长的限制是1024KB。
欢迎大家来讨论！