Hybris中将属性修饰符从unique改为非unique可能出现哪些问题？

• 数据库约束不生效风险：Hybris执行system update时默认不会主动删除数据库层面已创建的唯一索引，仅修改items.xml配置不会生效，需要手动清理对应表的唯一索引。手动删除索引后，若存在未覆盖到的隐式业务逻辑依赖该属性唯一性，会出现查询返回多条结果、数据更新错乱的问题。
• Impex导入异常：存量Impex脚本如果将该属性配置为导入唯一键（Header中声明[unique=true]），修改后导入会命中多条数据，轻则抛出AmbiguousIdentifierException导入失败，重则误更新不符合预期的业务数据。依赖该属性做去重的批量导入逻辑也会直接失效，产生大量重复数据。
• 现有功能异常：即便你已完成自有Java代码适配，Hybris原生组件、其他扩展模块如果调用了flexibleSearchService.getUniqueResult()、getModelByExample()这类方法，且以该属性为核心查询条件，会直接抛出NonUniqueResultException导致功能崩溃。若该属性为Solr索引的分组字段/唯一标识，还会出现索引覆盖、搜索结果缺失的问题。
• 跨系统集成冲突：如果有对外API、第三方系统集成以该属性作为唯一交互标识，修改后会出现同步数据冲突、第三方系统接口校验报错、数据匹配错误等问题。
• 后续运维成本上升：如果后续业务有需求需要重新将该属性设置为唯一，需要全表扫描清理所有重复的属性值，数据量大时清理成本极高，还可能伴随业务停机风险。

内容的提问来源于stack exchange，提问作者Farrukh Chishti