通常来说，Mysql单表的数据量达到一两千万之后，操作起来就明显感觉吃力了，那数据量累积到到上亿，估计系统就吃不消了。
Mysql数据库本身是非常灵活的，这就导致了性能上的不足，严重依赖开发人员的能力。这就意味着开发人员的技术要高，Mysql的性能要高。这也与很多数据库类型有关，所以dba的工资通常较高。
那么解决方案有哪些呢？小编提几个思路：
一、就用MySQL，不考虑迁移
分库分表其实是比较好的方案，但是已经被题主否了，就不详细说了；
表设计的优化：在设计表的时候，就要考虑性能问题了。例如字段尽量避免NULL，时间类型尽量使用TIMESTAMP，单表的字段不宜过多等等。
索引的优化：索引不是越多越好，也不是所有的字段都适合建立索引，使用多列索引的时候，要注意SQL中的条件顺序等。
SQL的优化：有的时候查询慢，可能是SQL写的烂。查询尽量用到索引，避免错误的写法导致索引失效，避免使用select *查询出来所有的列，拆分复杂的SQL语句，查询使用分页等等。
分区：分区表是独立的逻辑表，底层由多个物理表组成，这些对用户来说是透明的；如果按照分区字段查询数据的话，就会在某一张分区表内查询，速度回比较快；分区字段的选择，需要根据你们实际业务来；比如你们这张表如果可以分100个分区的话，那么每张表实际只有100万的数据；使用分区表尽量避免全表扫描；建议考虑这种优化方式。
读写分离：就是将数据库的读写操作分开，比如让主服务器读，从服务器去做写操作，或者让性能比较好的服务器去做写操作，性能不太好的服务器做读操作；具体如何去读写分离，要看我们如何去分了。
静态缓存：分为本地缓存和服务缓存，本地缓存就是将数据加载到本地，服务缓存就是比如使用Redis这样的k-v数据库进行存储热点数据。但是使用服务缓存也有缺点，最常见的问题就是，“击穿”，就是假如缓存都失效了，这时候并发请求都去访问db，此时可能造成服务器挂掉，这个时候为了避免这种情况，一般都是使用互斥量来解决这种问题。
二、抛弃MySQL，迁移数据库
如果公司有钱的话，可以直接上商业数据库，Oracle、DB2什么的，一亿的数据还是可以搞的定的，当然会也比较贵。
其他开源数据库，有可以支持千万级的产品，不过不建议使用，坑会比较多。
云数据库，可以考虑把数据迁移到云上，比如阿里云，花一些钱，少操一些；不过如果是比较敏感的数据，放到云上，多少会不太放心；私有云？这个也贵。
另外，如果不迁移Mysql的话，可以加以非关系型数据库进行辅助，例如一些数据放到Redis里面进行缓存，或者通过跑数的方式，把原始数据加工好放到Mongodb中提供查询，总之就是减少对数据库的访问。
三、总结
总的来说，随着数据的积累分库，分表是唯一出路。大家看一下京东，淘宝的订单数据就知道了，默认仅显示三个月， 有可能他们就是定义最近三个月为热数据，当前常用库，之前你的订单在历史数据库里面，这样的好处，显而易见的。你的系统查询速度最大的影响因素，就是数据量。
感谢您抽出
.
.
阅读本文
