报错日志关键字：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。欢迎大家来讨论！