(6)MySQL大表优化方案、

摘要:

1.限定数据的范围:查询订单历史,控制一个月范围。;

2.读/写分离: 主库写,从库读;

缓存: 使用MySQL的缓存,另外对重量级、更新少的数据可以考虑使用应用级别的缓存;

1)垂直分区(表列拆分):

根据数据表拆分。 用户表中:登录信息、用户基本信息,拆成两个单独表,分库。

优点:行数据变小,查询时减少读取Block数,I/O次数,简化表结构,易维护。

缺点:管理冗余列,引起Join操作,事务变复杂;

2)水平分区:

行数超过200万行时,变慢。表结构不变,存储数据,分散到不同表或库中,

优点:支持大数据量。注意:表数据在同一台机器,没提升MySQL并发能力,所以最好分库

缺点:跨界点Join性能较差,逻辑复杂。带来逻辑、部署、运维的各种复杂度,数据千万以下没问题。尽量客户端分片架构,减少一次和中间件网络I/O。

常见方案:

(1)客户端代理:分片逻辑在应用端,封装在jar包中,修改或封装JDBC层实现。当当网Sharding-JDBC、阿里TDDL

(2)中间件代理:应用和数据中间加代理层。分片逻辑统一维护在中间件服务中。Mycat、360的Atlas、网易的DDB等等

一、单表优化

整型值表千万级以下字符串为主的表在五百万以下没有问题。单表支撑千万级以上数据量:

1.1字段

1、尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT,如非负加上UNSIGNED

2、VARCHAR长度只分配真正需要的空间

3、枚举或整数代替字符串

4、用TIMESTAMP非DATETIME

5、20以内字段

6、避免NULL字段,难查询优化占用额外索引空间

7、整型来存IP

1.2索引

1.不是越多越好,根据查询针对性创建,考虑在WHERE和ORDER BY命令上涉及的列建立索引,EXPLAIN用索引还是全表扫描

2.避免WHERE子句中对字段进行NULL值判断,导致引擎不用索引而进行全表扫描

3.值分布稀少字段不适合建索引,如"性别"只有三个值

4.字符字段只建前缀索引

5.字符字段最好不要做主键

6.不用外键,由程序保证约束

7尽量不用UNIQUE,由程序保证约束

8使用多列索引时主意顺序和查询条件保持一致,同时删除不必要的单列索引

1.3查询SQL

1.开启慢查询日志来找慢SQL

2.不做列运算:SELECT id WHERE age + 1 = 10,任何对列的操作都将导致表扫描,它包括数据库教程函数、计算表达式等等,查询时要尽可能将操作移至等号右边

3.sql简单:一条sql只在一个cpu运算;大语句拆小语句减少锁时间;一条大sql可以堵死整个库

4.用SELECT *

5.OR改写成IN:OR的效率是n级别,IN的效率是log(n)级别,in的个数建议控制在200以内

6.不用函数和触发器,应用程序实现

7.避免%xxx式查询

8.少用JOIN

9.同类型进行比较,比如用'123'和'123'比,123和123比

10.避免WHERE子句中用!=或<>操作符,否则引擎放弃使用索引而进行全表扫描

11.连续数值,用BETWEEN不用IN:SELECT id FROM t WHERE num BETWEEN 1 AND 5

12.用LIMIT来分页,每页数量不要太大

二、系统调优参数   

基准测试工具

sysbench:一个模块化,跨平台以及多线程的性能测试工具

iibench-mysql:基于 Java 的 MySQL/Percona/MariaDB 索引进行插入性能测试工具

tpcc-mysql:Percona开发的TPC-C测试工具

重要调优参数:

back_log:指出MySQL暂时停止回答新请求之前的短时间内,堆栈中可多少个请求。连接数据达到max_connections时,新请被存堆栈中,等待某一连接释放资源,堆栈数量即back_log,等待连接数量超过back_log,不被授予连接资源。默认50升至500

wait_timeout:数据库连接闲置时间,占用内存资源。默认8小时减到半小时

max_user_connection: 最大连接数,默认为0无上限,最好设一个合理上限

thread_concurrency:并发线程数,设为CPU核数的两倍

skip_name_resolve:禁止对外部连接进行DNS解析,消除DNS解析时间,但需要所有远程主机用IP访问

key_buffer_size:索引块的缓存大小,增加会提升索引处理速度,对MyISAM表性能影响最大。对于内存4G左右,可设为256M或384M,通过查询show status like 'key_read%',保证key_reads / key_read_requests在0.1%以下最好

innodb_buffer_pool_size:缓存数据块和索引块,对InnoDB表性能影响最大。通过查询show status like 'Innodb_buffer_pool_read%',保证 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests越高越好

innodb_additional_mem_pool_size:InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小,当数据库对象非常多的时候,适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率,当过小的时候,MySQL会记录Warning信息到数据库的错误日志中,这时就需要该调整这个参数大小

innodb_log_buffer_size:InnoDB存储引擎的事务日志所使用的缓冲区,一般来说不建议超过32MB

query_cache_size:缓存MySQL中的ResultSet,也就是一条SQL语句执行的结果集,所以仅仅只能针对select语句。当某个表的数据有任何任何变化,都会导致所有引用了该表的select语句在Query Cache中的缓存数据失效。所以,当我们的数据变化非常频繁的情况下,使用Query Cache可能会得不偿失。根据命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整,一般不建议太大,256MB可能已经差不多了,大型的配置型静态数据可适当调大.

通过命令show status like 'Qcache_%'查看目前系统Query catch使用大小

read_buffer_size:MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySql会为它分配一段内存缓冲区。如果对表的顺序扫描请求非常频繁,可以通过增加该变量值以及内存缓冲区大小提高其性能

sort_buffer_size:MySql执行排序使用的缓冲大小。如果想要增加ORDER BY的速度,首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能,可以尝试增加sort_buffer_size变量的大小

read_rnd_buffer_size:MySql的随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySql会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySql会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。

record_buffer:每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,可能想要增加该值

thread_cache_size:保存当前没有与连接关联但是准备为后面新的连接服务的线程,可以快速响应连接的线程请求而无需创建新的

table_cache:类似于thread_cache_size,但用来缓存表文件,对InnoDB效果不大,主要用于MyISAM

三、升级硬件

Scale up,不多说,根据MySQL是CPU密集型还是I/O密集型,提升CPU和内存、使用SSD,都能显著提升MySQL性能

四、读写分离

从库读主库写不要采用双主多主引入很多复杂性

五、缓存

缓存发生层次

MySQL内部系统调优参数介绍了相关设置

数据访问层:如MyBatisSQL做缓存,Hibernate可精确到单个记录,缓存对象主要是持久化对象Persistence Object

应用服务层:通过编程手段对缓存精准控制和更多实现策略,缓存对象是数据传输对象Data Transfer Object

Web层:web页面做缓存

浏览器客户端:用户端缓存

根据实际情况在一个层次或多个层次结合加缓存服务层缓存实现两种方式

1.直写式(Write Through):

数据写入数据库后,同时更新缓存,维持数据库与缓存一致性。大多数应用缓存Spring Cache工作方式。实现简单,同步好,效率一般

2.回写式(Write Back)

写入数据库时,只更新缓存异步批量缓存数据同步到数据库上。实现复杂,可能会产生数据库与缓存的不同步,效率非常高

五、表分区

MySQL5.1引入简单水平拆分建表加上分区参数,对应用是透明的无需修改代码

分区表独立的逻辑表,但底层由多个物理子表组成,实现分区代码实际上通过对一组底层表对象封装,但对SQL层来说是完全封装底层的黑盒子。MySQL实现分区的方式也意味着索引也是按照分区子表定义没有全局索引

用户的SQL语句要针对分区表优化,SQL条件中要带上分区条件的列,查询定位到少量分区上,否则扫描全部分区,EXPLAIN PARTITIONS看SQL落在那些分区上,优化

5.1分区的好处是:

1.单表存储更多的数据

2.分区表易维护,清楚整个分区批量删除大量数据,增加新分区来支持插入。对独立分区优化、检查、修复等

3.查询速度快

4.分布不同物理设备上高效利用多个硬件设备

5.避免特殊瓶颈,如InnoDB单个索引的互斥访问ext3文件系统的inode锁竞争

6.可备份和恢复单个分区

5.2分区的限制和缺点:

1.一个表最多只能有1024个分区

2.分区字段中有主键或者唯一索引的列主键列唯一索引列都必须包含进来

3.分区表无法使用外键约束

4.NULL值使分区过滤无效

5.用相同的存储引擎

5.3分区的类型:

RANGE分区:给定连续区间的列值,多行分配给分区

LIST分区:类似RANGE分区,区别LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择

HASH分区:基于用户定义表达式返回值选择分区,该表达式使用插入的行列值计算。包含MySQL中有效、产生非负整数值

KEY分区:类似HASH分区,区别在于KEY分区只计算一列或多,MySQL提供自身哈希函数。必须有列包含整数值

5.4分区适合的场景有:

1.时间序列性较强,按时间分区:

2.如有热点,可以热点单独分区缓存内存中

合并表(merge table),限制较多且缺乏优化,不建议使用,用新分区替代

六、兼容MySQL且可水平扩展的数据库

开源兼容MySQL协议,如:TiDBCubrid

将原始MySQL迁移到可水平扩展新库中,云数据库:

阿里云PetaData阿里云OceanBase腾讯云DCDB

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,142评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,298评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,068评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,081评论 1 291
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,099评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,071评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,990评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,832评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,274评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,488评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,649评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,378评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,979评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,625评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,643评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,545评论 2 352

推荐阅读更多精彩内容

  • 当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化:单表优化除非单表数据未来会一直不断...
    扎Zn了老Fe阅读 881评论 0 6
  • 原文版权 当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据...
    若与阅读 6,438评论 9 354
  • 当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化。 单表优化 除非单表数据未来会一直...
    带娃儿先走阅读 304评论 0 3
  • 说真的,我有点儿“微信焦虑症”。 微信长期保持在线的时候,杂乱的各项消息塞满了我的微信号,压根儿看不过来,于是有可...
    米思吳阅读 475评论 1 1
  • 我的第一篇小短文想要说的事,就是从现在开始简书就是我的电子日记本 毕竟能插入图片的日记本,岂不是美滋滋  ̄~ ̄ 还...
    葱厨大大阅读 185评论 0 0