mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：
1 分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法
2 读写分离。尤其是写入，放在新表中，定期进行同步。如果其中记录不断有update，最好将写的数据放在 redis中，定期同步
3 表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库
4 优化架构，或优化SQL查询，避免联表查询，尽量不要用count(*)， in，递归等消耗性能的语句
5 用内存缓存，或在前端读的时候，增加缓存数据库。重复读取时，直接从缓存中读取。
上面是低成本的管理方法，基本几台服务器即可搞定，但是管理起来麻烦一些。
当然，如果整体数据量特别大的话，也不在乎投入费用的话，用集群吧，用TIDB吧
mysql数据以什么格式储存数据？
frm 数据表结构描述MYI 索引文件MYD 数据文件默认数据文件目录在安装目录下的data文件夹下。例如创建数据库mysqldb，则会在data目录下创建一个mysqldb的目录，数据文件就在其下。
Java前提下，MySQL数据库，一次性存储大量数据导致内存溢出？
内存溢出导致程序崩溃，也分是java层崩了，还是mysql崩了。如果是java层崩了，注意不要一次性加载太多的数据到内存，并且不在使用的数据要彻底放弃引用关系。java虽然是自动回收，回收的原则就是一个对象不再被持有，即引用计数为零。如果数据太大，可考虑临时文件。如果是mysql崩了，首先增加配置缓存。一般来说mysql是不容易崩的，特别是插入操作的时候。查询的时候如果查询结果记录集特别大，会导致一个查询需要使用很大的内存空间，这种是有问题的。而插入操作都是一条一条的执行，不会导致大内存的使用。如果仅仅是数据移植，也尽量不要用ORM框架，比如hibernate，mybatis这些东西，因为他们都有自己的缓存，直接使用JDBC比较好。
