mysql表数据量太大,除了分库分表之外还有没有其它方法

mysql在常规配置下,一般只能承受2000万的数据量(同时读写,且表中有大文本字段,单台服务器)。
现在超过1亿,并不断增加的情况下,建议如下处理:1 分表。
可以按时间,或按一定的规则拆分,做到查询某一条数据库,尽量在一个子表中即可。
这是最有效的方法2 读写分离。
尤其是写入,放在新表中,定期进行同步。
如果其中记录不断有update,最好将写的数据放在 redis中,定期同步3 表的大文本字段分离出来,成为独立的新表。
大文本字段,可以使用NOSQL数据库4 优化架构,或优化SQL查询,避免联表查询,尽量不要用count(*), in,递归等消耗性能的语句5 用内存缓存,或在前端读的时候,增加缓存数据库。
重复读取时,直接从缓存中读取。
上面是低成本的管理方法,基本几台服务器即可搞定,但是管理起来麻烦一些。
当然,如果整体数据量特别大的话,也不在乎投入费用的话,用集群吧,用TIDB吧
参考:
通常来说,Mysql表的数据量达到一两千万之后,操作起来开始有些吃力了,如果数据量达到上亿,估计系统是吃不消的。
那么解决方案有哪些呢?
我提几个思路:就用Mysql,不考虑迁移分库分表其实是比较好的方案,但是已经被否了,就不详细说了;
表设计的优化:在设计表的时候,就要考虑性能问题了。
例如字段尽量避免NULL,时间类型尽量使用TIMESTAMP,单表的字段不宜过多等等。
索引的优化:索引不是越多越好,也不是所有的字段都适合建立索引,使用多列索引的时候,要注意SQL中的条件顺序等。
SQL的优化:有的时候查询慢,可能是SQL写的烂。
查询尽量用到索引,避免错误的写法导致索引失效,避免使用select *查询出来所有的列,拆分复杂的SQL语句,查询使用分页等等。
分区:分区表是独立的逻辑表,底层由多个物理表组成,这些对用户来说是透明的;
如果按照分区字段查询数据的话,就会在某一张分区表内查询,速度回比较快;
分区字段的选择,需要根据你们实际业务来;
比如你们这张表如果可以分100个分区的话,那么每张表实际只有100万的数据;
使用分区表尽量避免全表扫描;
建议考虑这种优化方式。
抛弃Mysql,迁移数据库如果公司有钱的话,可以直接上商业数据库,Oracle、DB2什么的,一亿的数据还是可以搞的定的,当然会也比较贵。
其他开源数据库,有可以支持千万级的产品,不过不建议使用,坑会比较多。
云数据库,可以考虑把数据迁移到云上,比如阿里云,花一些钱,少操一些;
不过如果是比较敏感的数据,放到云上,多少会不太放心;
私有云?
这个也贵。
另外,如果不迁移Mysql的话,可以加以非关系型数据库进行辅助,例如一些数据放到Redis里面进行缓存,或者通过跑数的方式,把原始数据加工好放到Mongodb中提供查询,总之就是减少对数据库的访问。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的

参考:
你不想分,就堆硬件堆带宽呗。
单表数据上亿可以采用以下方法首先分表是必须的,然后分库。
分表可以采用按时间分,根据实际情况一个月或一个季度的分。
网站前端列表采用只查询最新表另外是按分类分,如果数据还是大则在分类基础上再时间拆分。
然后配合缓存,再不需要及时更新的页面所有查询都只从缓存中查询。
这时候还慢的话,就再分库分库最简单的就是读者分离,两台数据库服务器。
如果读者分离还慢,就考虑再加多台读服务器。
程序上不想改动就采用负载均衡分摊压力。
但是这样还有个问题就是,每台服务器都要保存一样的数据,及时同步,数据量大维护挺麻烦。
所以就得再业务层分库了最简单的就是按地区分库,访问量高的地区都单独使用服务器,只保存当前地区的数据,同时该地区数据也可以再分表,分库。
业务层要做的就是在访问入口判断用户所在地区,然后访问当前地区数据库。
像58同城这种带地区分站的网站都是这种策略。
一般大网站都是数据库分布式,缓存分布式,模块单独部署,负载均衡,多节点,多种技术结合在一起的。
不过一亿数据,分表和读者分离,缓存就解决了。
负载均衡缓存
参考:
在做垂直拆分或者水平扩展的时候,要大概清楚2亿条数据库是都经常性进行大规模的查询还是更新?
这决定了你扩展的思路,如果是范范的进行扩展,有时候会起到适得其反的效果。
1.首先要检查哪些经常查询的SQL是否可以有优化的地方,检查数据库的索引建立的是否合理,索引是否有效,可以尝试建立分区表等,这一步主要是单个数据库的优化。
2.在mysql的扩展上包括垂直拆分,即分库分表的,这种需求需要在代码层实现,需要开发人员在代码层进行一些配置。
这个可以起到写的负载均衡。
而水平扩展说白一点就是增加服务器的个数,由原来的一台变成几台,再通过mysql的中间件,比如proxysql或者mycat进行一些配置(推荐proxysql),把写请求放在那些性能好的服务器上,把读分散到不同的服务器上,这样就起到了读的负载均衡。
3.如果上面垂直拆分或者水平扩展还是不能解决问题,可以考虑使用nosql,在前端增加一个缓存,memory cache或者redis来增加缓存,应用层在首先会读取redis里的数据,如果没有才会往MySQL里去读,当然你的查询不能是太过复杂的查询。
个人推荐redis,毕竟它可以磁盘落地化。
综上所述,应该可以解决问题。
当然这里只是提供思路,没有一种方案是完美的,都需要根据需求去定制。

参考:
软件设计表数据量太大这个是架构设计里,常遇到的问题。
先考虑优化,读写分离、合理索引、缓存数据、高频读取写进redis等产品,也可以买非常多的实例来做负载,不过这些操作撑不了多久。
分库分表几乎是唯一的,也是最好的办法。
当然分库分表大家不愿意操作,主要还是因为要改动业务代码,还有一种傻瓜式操作,不需要你改业务代码,那就是分区,例如你把数据一个月分一个区,数据库 mysql 单表数据量达到千万、亿级,可以通过分表与表分区提升服务性能。
不过你说不想分库分表,那就拿钱抗啊,上商业数据库,Oracle、DB2、PGSQL等,即使上这些数据库,你迟早还是得根据业务分库分表,这个你可以问下,淘宝,知乎这些大量数据的工程师,长期下去分库,分表是唯一出入。
你看京东,淘宝你的订单数据就知道了,默认显示三个月, 有可能他们就是定义最近三个月为热数据,当前常用库,之前你的订单在历史数据库里面。
这样的好处,显而易见的,你的系统查询速度最大的影响因素,就是数据量。
这就像一个箱子里面装了100人,只能从上面往下面看找人, 如果你有1000人,做成10层的箱子, 要去箱子里面找出5个穿红色衣服的人很慢。
如果分成10个箱子,即使查找10次,也比在一个箱子里面快。
架构里面虽然没有什么唯一的解决办法,遇到大数据,思路基本都是统一的,减少源站数据库访问,分库分表。

参考:
很高兴能够看到和回答这个问题,作为一个爱好者,我每天都在
下面我将根据自己的经验认真回答这个问题。
mysql表数据量太大,达到了1亿多条数据,除了分库分表之外,还有没有其他的解决方式?
MySQL是世界上最受欢迎的开源数据库。
凭借其经过验证的性能,可靠性和易用性,MySQL已成为基于Web的应用程序的领先数据库选择,被包括Facebook,Twitter,You Tube,Yahool等在内的知名Web财产所使用。
Oracle推动MySQL创新,提供了支持下一代Web,云服务,移动和嵌入式应用程序的新功能。
MysQL是数据库的相对控制系统。
它将数据存储在不同的表中,而不是存储空间较广,从而提高了速度和灵活性。
MySQL是最常用的访问数据库的语言。
根据双因素认证政策,MySQL软件开发分为社区版和商业版。
功率大、速度快、规模小、成本低,特别是使用开源数据库,因为整个网站都是选用MySQL。
例如,MysQL为中小企业提供了比Oracle、DB2、SQL Server、SQL Server等个人用户更多的机会。
由于MySQL是开源软件,这可能会大大降低整体成本。
Linux是操作系统,Apache或Nginx是Web服务器,MySQL是数据库,PHP/Perl/python是服务器解释器。
由于这四种软体都是免费或免费(FLOSS)的,所以应用这种方法可以不计成本地建立一个稳定的免费网络系统LAMP或LNMP。
mysql数据库本身是非常灵活的,这就导致了性能上的不足,严重依赖开发人员的能力。
这就意味着开发人员的技术要高,mysql的性能要高。
这也与很多数据库类型有关,所以dba的工资通常较高。
为了避免表字段出现空值,空值难以优化,而且占用额外的索引空间,默认值为0,而不是空值。
mysql表数据量太大,达到了1亿多条数据,我们该怎么办呢?
思路一:用INT代替BIGINT,加上UNSIGNED(这样体积会翻倍),当然可以用TINT、SmalLINT和MEDIUM.inti更好。
用列表或整数代替字符串类型使用TIMSTATIME代替DATETIME。
表上的字段不要太多,建议20岁以下。
保持IP的完整性思路二、修改索引:索引没有更好的选择,要看是否按要求创建索引。
如果是,EXPLAIN可以通过讨论中的命令和列中的命令来决定是使用索引还是完全扫描表。
不能根据子程序中NULL的值来判断,否则可能会导致引擎在完全扫描表时停止使用索引。
值分布非常罕见的字段不适合做索引。
例如,性别只有两个重要区域。
字符字段只包含前缀。
字符字段不应该是主键。
不要使用通过软件连接的外部键。
不要使用UNIQUE使用多行索引将保留搜索和条件序列,不必要的独立索引将被删除。
以上便是我的一些见解和回答,可能不能如您所愿,但我真心希望能够对您有所帮助!不清楚的地方您还可以
除此之外还有什么为了提高搜索速度设置索引一类的,不过几亿的数据设置索引效果也不会太大。
最终,建议还是不要叫一张表数据量超过1000万,会导致出现各种问题,如果超了最方便的办法就是分库分表。
以上希望能对有帮助~~~~~~
参考:
分库分表是最常规也是最常见的一种解决数据量过大的方式。
分表的话也分为垂直分和水平分。
下面我列举一下其他的方式1、读写分离。
就是将数据库的读写操作分开,比如让主服务器读,从服务器去做写操作,或者让性能比较好的服务器去做写操作,性能不太好的服务器做读操作;
具体如何去读写分离,要看我们如何去分了。
2、静态缓存。
分为本地缓存和服务缓存,本地缓存就是将数据加载到本地,服务缓存就是比如使用Redis这样的k-v数据库进行存储热点数据。
但是使用服务缓存也有缺点,最常见的问题就是,“击穿”,就是假如缓存都失效了,这时候并发请求都去访问db,此时可能造成服务器挂掉,这个时候为了避免这种情况,一般都是使用互斥量来解决这种问题。
3、系统架构。
这个就要看我们整体项目的架构设计,主要是包括SQL操作的设计
参考:
数据库的类型目前有这么几种:关系型数据库,nosql和最近出的newSql和时序数据库。
能支撑大数据量又保有大部分的关系数据库的功能,那非newSql数据库莫属了。
2012 年 Google 在 OSDI 上发表了 Spanner 的论文,2013 年在 SIGMOD 发表了 F1 的论文。
这两篇论文让业界第一次看到了关系模型和 NoSQL 的扩展性在超庞大集群规模上融合的可能性。
NewSql数据库,国外的有CockroachDB,国内的有TiDB,TiDB有pingCap公司出品,国内的大公司已经在使用,有大公司的背书,所以我们公司也在使用,省去了使用mysql手工分库分表和使用中间件的麻烦。

参考:
首先,1亿的数据量就很多了?
难道关系型数据库不能在5ms内返回数据?
单机qps达到1000了,那响应就要5m,如果是这种就应该加缓存解决,而不是加数据库!这是读多写少的情况。
当写多,可以加MQ,同步变异步写,随机写变顺序写。
之后考虑一主多从架构,或多主多从,只有当单机磁盘容量不足时才考虑分库分表,或分布式数据库。
当然如果是数仓应用的话,可能考虑列式存储,es+hbase
参考:
(1) 一般情况下,如果单机数据库容量撑不住了,应先从缓存技术着手降低对数据库的访问压力。
如果缓存使用过后,数据库访问量还是非常大,可以考虑数据库读写分离策略。
如果数据库压力依然非常大,且业务数据持续增长无法估量,最后才考虑分库分表,单表拆分数据应控制在1000万以内。
(2) 当然,随着互联网技术的不断发展,处理海量数据的选择也越来越多。
在实际进行系统设计时,最好是用MySQL数据库只用来存储关系性较强的热点数据,而对海量数据采取另外的一些分布式存储产品。
例如PostGreSQL、VoltDB甚至HBase、Hive、ES等这些大数据组件来存储。
(3) 分库分表后,对SQL语句的支持,其实是步步为艰的,稍不小心,就会造成SQL语句不支持、业务数据混乱等很多很多问题。
所以,实际使用时,我们会建议这个分库分表,能不用就尽量不要用。
如果要使用优先在OLTP场景下使用,优先解决大量数据下的查询速度问题。
而在OLAP场景中,通常涉及到非常多复杂的SQL,分库分表的限制就会更加明显。
当然,这也是ShardingSphere以后改进的一个方向。
(4)如果确定要使用分库分表,就应该在系统设计之初开始对业务数据的耦合程度和使用情况进行考量,尽量控制业务SQL语句的使用范围,将数据库往简单的增删改查的数据存储层方向进行弱化。
并首先详细规划垂直拆分的策略,使数据层架构清晰明了。
而至于水平拆分,会给后期带来非常非常多的数据问题,所以应该谨慎、谨慎再谨慎。
一般也就在日志表、操作记录表等很少的一些边缘场景才偶尔用用。