当MySQL单表记录数过大时,增删改查性能都会急剧下降(文末有福利)
除非单表数据未来会一直不断上涨,否则 不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在 千万级以下,字符串为主的表在 五百万以下是没有太大问题的。
而事实上很多时候 MySQL 单表的性能依然有不少优化空间,甚至能正常支撑 千万级以上的数据量。
目前广泛使用的是 MyISAM 和 InnoDB 两种引擎:
MyISAM 引擎是 MySQL 5.1 及之前版本的默认引擎,它的特点是:
InnoDB 在 MySQL 5.5 后成为默认索引,它的特点是:
总体来讲, MyISAM 适合 SELECT 密集型的表,而 InnoDB 适合 INSERT 和 UPDATE 密集型的表
可以使用下面几个工具来做基准测试:
具体的调优参数内容较多,具体可参考官方文档,这里介绍一些比较重要的参数:
backlog:backlog 值指出在 MySQL 暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。也就是说,如果 MySql 的连接数据达到 maxconnections 时,新来的请求将会被存在堆栈中,以等待某一连接释放资源,该堆栈的数量即 backlog,如果等待连接的数量超过 back_log,将不被授予连接资源。可以从默认的 50 升至 500
wait_timeout:数据库连接闲置时间,闲置连接会占用内存资源。可以从默认的 8 小时减到半小时
maxuserconnection: 最大连接数,默认为 0 无上限,最好设一个合理上限
thread_concurrency:并发线程数,设为 CPU 核数的两倍
skipnameresolve:禁止对外部连接进行 DNS 解析,消除 DNS 解析时间,但需要所有远程主机用 IP 访问
keybuffersize:索引块的缓存大小,增加会提升索引处理速度,对 MyISAM 表性能影响最大。对于内存 4G 左右,可设为 256M 或 384M,通过查询 show status like'key_read%',保证 key_reads / key_read_requests 在 0.1% 以下最好
innodbbufferpool_size:缓存数据块和索引块,对 InnoDB 表性能影响最大。通过查询 show status like'Innodb_buffer_pool_read%',保证 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests 越高越好
innodbadditionalmempoolsize:InnoDB 存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小,当数据库对象非常多的时候,适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率,当过小的时候,MySQL 会记录 Warning 信息到数据库的错误日志中,这时就需要该调整这个参数大小
innodblogbuffer_size:InnoDB 存储引擎的事务日志所使用的缓冲区,一般来说不建议超过 32MB
querycachesize:缓存 MySQL 中的 ResultSet,也就是一条 SQL 语句执行的结果集,所以仅仅只能针对 select 语句。当某个表的数据有任何任何变化,都会导致所有引用了该表的 select 语句在 Query Cache 中的缓存数据失效。所以,当我们的数据变化非常频繁的情况下,使用 Query Cache 可能会得不偿失。根据命中率 (Qcache hits / (Qcache_hits + Qcache_inserts) * 100)) 进行调整,一般不建议太大,256MB 可能已经差不多了,大型的配置型静态数据可适当调大. 可以通过命令 show status like'Qcache%' 查看目前系统 Query Catch 使用大小
readbuffersize:MySql 读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySql 会为它分配一段内存缓冲区。如果对表的顺序扫描请求非常频繁,可以通过增加该变量值以及内存缓冲区大小提高其性能
sortbuffersize:MySql 执行排序使用的缓冲大小。如果想要增加 ORDER BY 的速度,首先看是否可以让 MySQL 使用索引而不是额外的排序阶段。如果不能,可以尝试增加 sortbuffersize 变量的大小
readrndbuffer_size:MySql 的随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySql 会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但 MySql 会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大
record_buffer:每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,可能想要增加该值
threadcachesize:保存当前没有与连接关联但是准备为后面新的连接服务的线程,可以快速响应连接的线程请求而无需创建新的
tablecache:类似于 threadcache_size,但用来缓存表文件,对 InnoDB 效果不大,主要用于 MyISAM
Scale up,这个不多说了,根据 MySQL 是 CPU 密集型还是 I/O 密集型,通过提升 CPU 和内存、使用 SSD,都能显著提升 MySQL 性能。
也是目前常用的优化,从库读主库写,一般 不要采用双主或多主引入很多复杂性,尽量采用文中的其他方案来提高性能。 同时目前很多拆分的解决方案同时也兼顾考虑了读写分离。
缓存可以发生在这些层次:
可以根据实际情况在一个层次或多个层次结合加入缓存。 这里重点介绍下服务层的缓存实现,目前主要有两种方式:
MySQL 在 5.1 版引入的分区是一种简单的水平拆分,用户需要在建表的时候加上分区参数,对应用是透明的无需修改代码
对用户来说,分区表是一个独立的逻辑表,但是底层由多个物理子表组成,实现分区的代码实际上是通过对一组底层表的对象封装,但对 SQL 层来说是一个完全封装底层的黑盒子。MySQL 实现分区的方式也意味着索引也是按照分区的子表定义,没有全局索引。
用户的 SQL 语句是需要针对分区表做优化,SQL 条件中要带上分区条件的列,从而使查询定位到少量的分区上,否则就会扫描全部分区,可以通过 EXPLAIN PARTITIONS 来查看某条 SQL 语句会落在那些分区上,从而进行 SQL 优化,如下图 5 条记录落在两个分区上:
分区适合的场景有:
最适合的场景数据的时间序列性比较强,则可以按时间来分区,如下所示:
查询时加上时间范围条件效率会非常高,同时对于不需要的历史数据能很容的批量删除。
如果数据有明显的热点,而且除了这部分数据,其他数据很少被访问到,那么可以将热点数据单独放在一个分区,让这个分区的数据能够有机会都缓存在内存中,查询时只访问一个很小的分区表,能够有效使用索引和缓存
另外 MySQL 有一种早期的简单的分区实现 - 合并表(merge table),限制较多且缺乏优化,不建议使用,应该用新的分区机制来替代
垂直分库是根据数据库里面的数据表的相关性进行拆分。 比如:一个数据库里面既存在用户数据,又存在订单数据,那么垂直拆分可以把用户数据放到用户库、把订单数据放到订单库。 垂直分表是对数据表进行垂直拆分的一种方式,常见的是把一个多字段的大表按 常用字段和 非常用字段进行拆分,每个表里面的数据记录数一般情况下是相同的,只是字段不一样,使用 主键关联
比如原始的用户表是:
垂直拆分后是:
概述
水平拆分是通过某种策略将数据分片来存储,分 库内分表和 分库两部分,每片数据会分散到不同的 MySQL 表或库,达到分布式的效果,能够支持非常大的数据量。前面的表分区本质上也是一种特殊的 库内分表
库内分表,仅仅是单纯的解决了单一表数据过大的问题,由于没有把表的数据分布到不同的机器上,因此对于减轻 MySQL 服务器的压力来说,并没有太大的作用,大家还是竞争同一个物理机上的 IO、CPU、网络,这个就要通过分库来解决
前面垂直拆分的用户表如果进行水平拆分,结果是:
实际情况中往往会是垂直拆分和水平拆分的结合,即将 Users_A_M 和 Users_N_Z 再拆成 Users 和 UserExtras,这样一共四张表
这里特别强调一下分片规则的选择问题,如果某个表的数据有明显的时间特征,比如订单、交易记录等,则他们通常比较合适用时间范围分片,因为具有时效性的数据,我们往往关注其近期的数据,查询条件中往往带有时间字段进行过滤,比较好的方案是,当前活跃的数据,采用跨度比较短的时间段进行分片,而历史性的数据,则采用比较长的跨度存储。
总体上来说,分片的选择是取决于最频繁的查询 SQL 的条件,因为不带任何 Where 语句的查询 SQL,会遍历所有的分片,性能相对最差,因此这种 SQL 越多,对系统的影响越大,所以我们要尽量避免这种 SQL 的产生。
由于水平拆分牵涉的逻辑比较复杂,当前也有了不少比较成熟的解决方案。这些方案分为两大类:
通过修改数据访问层,如 JDBC、Data Source、MyBatis,通过配置来管理多个数据源,直连数据库,并在模块内完成数据的分片整合,一般以 Jar 包的方式呈现
这是一个客户端架构的例子:
可以看到分片的实现是和应用服务器在一起的,通过修改 Spring JDBC 层来实现
通过独立的中间件来统一管理所有数据源和数据分片整合,后端数据库集群对前端应用程序透明,需要独立部署和运维代理组件
这是一个代理架构的例子:
代理组件为了分流和防止单点,一般以集群形式存在,同时可能需要 Zookeeper 之类的服务组件来管理
如此多的方案,如何进行选择?可以按以下思路来考虑:
按照上述思路,推荐以下选择:
目前也有一些开源数据库兼容 MySQL 协议,如:
但其工业品质和 MySQL 尚有差距,且需要较大的运维投入,如果想将原始的 MySQL 迁移到可水平扩展的新数据库中,可以考虑一些云数据库:
在 MySQL 上做 Sharding 是一种戴着镣铐的跳舞,事实上很多大表本身对 MySQL 这种 RDBMS 的需求并不大,并不要求 ACID,可以考虑将这些表迁移到 NoSQL,彻底解决水平扩展问题,例如:
最后小编在这分享一下小编学习用到的资料—MySQL学习结构导图,一下掌握所有MySQL所有知识点
图片可能有点不太清晰,没关系, 关注小编私信【资料】即可获取高清图片,更多资料都已备份在文档