1、mysql数据准确性
常见电商系统中，如订单服务、现金券服务、活动类服务等，这类服务中经常会出现一些并发更新数据的情况，如何保证数据准确性。虽然有些操作可通过"状态"字段做了类似乐观锁的处理。但理论上还是会出现ABA的问题，而且规则不够统一，不同业务可能情况不太一样。可以考虑通过加入在数据库中加入"版本号"统一处理，通过注解的形式，把这部分代码抽象出来。
2、性能优化--缓存的使用
- 大量数据直接查询数据库性能较差，可以考虑将更多数据放入redis，提升查询性能
- 使用redis做重要业务时，注意避免mysql与redis数据不一致影响
- redis是单线程的，这是它的一大优点，但有时候也会成为问题来源，如一些耗时较长的操作会造成redis阻塞，对整个系统的稳定性造成影响
3、性能优化--分库分表
对于一些数据量很大的表,sql层面再怎么优化，依然解决不了查询慢的问题。这是因为随着数据量的增加，索引树的深度会增加。加之有些查询数据的区分度不高。在sql层面去优化是解决不了这类问题的。这时可以考虑引入分库分表的方案了。mysql一般5kw左右就可以考虑分表了。核心思路就是根据业务特点把数据分不同的表存储，以此提升数据查询性能。常见的方案有按时间维度（年、月）分表，按用户id维度分表
4、性能优化--冷热数据
常用的数据存储中，有些表虽然数据量比较大，但业务上真正常用的就是近一年，或者半年的数据。这些常用的数据称为热数据，不常用的为冷数据。根据分而冶之的思想，将冷热数据分开存储。这样在热数据查询上可以获得更好的性能，同时冷数据可以选用便宜的存储设备，降低成本。例如elasticsearch中仅保存近一年的数据，其它数据换作mysql存储。这样elasticsearch中的数据量将减少，查询时速度更快，同时减小数据容量，降低成本。
5、不停服切换数据源
如上如果采用冷热数据分离的方式存储elasticsearch中的数据，或者引入分表的方案，那将涉及到数据迁移。如何做到不停服切换数据源，且出现较大问题后能马上切换到原有方案，将是整个方案的重点之一。
总结：数据存储没有完美、通用的解决方案，大多是根据不同的业务场景，有不同的处理方式，总结起来有如下方向
空间换时间：多保存数据副本，分担数据查询压力
常用案例：
主从复制（mysql主从、redis主从）
异构数据(elasticsearch + cannal数据同步 ，elasticsearch + 消息队列数据同步)
分而冶之：根据数据特点，按一定的逻辑将数据分开存储，从而获得性能上的提升
垂直拆分：微服务，按业务领域分库。。。
水平拆分：多租户分库、按时间维度分表、按用户维度分表。。。
非关系型数据库： Elasticsearch 、Redis。。。
