mysql性能优化

1.影响数据库的因素

1.)sq查询速度

2.)服务器硬件

3.)网卡流量

4.)磁盘IO


2.超高的QPS和TPs

QPS:每秒钟处理的査询量









3.还有什么会影响数据库性能

1.)大表给我们带来的问题

1.1)如何处理数据库中的大表

分库分表把一张大表分成多个小表

难点:1.分表主键的选择    2.分表后跨分区数据的查询和统计


2.)大事务给我们带来的影响(https://www.cnblogs.com/AndyAo/p/8177872.html)

定义:运行时间比较长,操作的数据比较多的事务

风险:锁定太多的数据,造成大量的阻塞和锁超时回滚时所需时间比较长执行时间长,容易造成主从延迟

1.)事务的原子性( ATOMICITY

定义:个事务必须被视为一个不可分割的最小工作单元,整个事务中的所有操作要么全部提交成功,要么全部失败,对于一个事务来说,不可能只执行其中的一部分操作

2.)事务的一致性( CONSISTENCY)

定义:致性是指事务将数据库从一种一致性状态转换到另外—种一致性状态,在事务开始之前和事务结束后数据库中数据的完整性没有被破坏

3.)事务的隔离性( ISOLATION)

定义:隔离性要求一个事务对数据库中数据的修改,在未提交完成前对于其它事务是不可见的

第1级别:Read Uncommitted(读取未提交内容)

(1)所有事务都可以看到其他未提交事务的执行结果

(2)本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少

(3)该级别引发的问题是——脏读(Dirty Read):读取到了未提交的数据

#首先,修改隔离级别

set tx_isolation='READ-UNCOMMITTED';

select @@tx_isolation;


第2级别:Read Committed(读取提交内容)

(1)这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)

(2)它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变

(3)这种隔离级别出现的问题是——不可重复读(Nonrepeatable Read):不可重复读意味着我们在同一个事务中执行完全相同的select语句时可能看到不一样的结果。

|——>导致这种情况的原因可能有:(1)有一个交叉的事务有新的commit,导致了数据的改变;(2)一个数据库被多个实例操作时,同一事务的其他实例在该实例处理其间可能会有新的commit

#首先修改隔离级别

set tx_isolation='read-committed';

select @@tx_isolation;


第3级别:Repeatable Read(可重读)

(1)这是MySQL的默认事务隔离级别

(2)它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行

(3)此级别可能出现的问题——幻读(Phantom Read):当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影” 行

(4)InnoDB和Falcon存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control)机制解决了该问题


第4级别:Serializable(可串行化)

(1)这是最高的隔离级别

(2)它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。

(3)在这个级别,可能导致大量的超时现象和锁竞争




 4.)事务的持久性( DURABILITY)

定义:一旦事务提交,则其所做的修改就会永久保存到数据库中。此时即使系统崩溃,已经提交的修改数据也不会丢失


4.MySql存储引擎

1.)MyISAM



2.) Innodb










5.系统参数优化

1.)内核相关参数(etc/sysctl.conf)

net.core.somaxconn=65535

net.core.netdev_max_ backlog=65535

net.ipv4.tcp_maxsyn_backlog=65535

net.ipv4.tcp_fin_timeout 10

net.ipv4.tcp_tw_reuse =1

net.ipv4.tcp_tw_recycle =1

net.core.wmem max =16777216

net.core.rmem_default =87380

net.core.rmem_max =16777216

net.ipv4.tcp_keepalive_time= 120

net.ipv4.tcp_keepalive_intl 30

net.ipv4.tcp_keepalive_probes =3


kernel.shmmax= 4294967295

注意:1这个参数应该设置的足够大,以便能在一个共享内存段下容纳下整个的 Innodb缓冲池的大小。一般去大于Innodb内存即可



wappiness=0的时候表示最大限度使用物理内存,然后才是 swap空间,swappiness=100的时候表示积极的使用swap分区,并且把内存上的数据及时的搬运到swap空间里面


注意:需要重启系统才能生效


6.磁盘调度策略优化

磁盘I/O,Linux提供了cfq, deadline和noop三种调度策略

MySQL数据库环境调整磁盘IO调度算法

最后期限算法(Deadline)除了维护了一个拥有合并和排序功能的请求队列外,额外维护了两个队列,分别是读请求队列和写请求队列,他们都是带有超时的请求队列,当新来一个IO请求时,会被同时插入普通队列和读写队列,然后I/O调度器正常处理普通队列中的请求。当调度器发现读写请求队列中的请求超时的时候,会优先处理这些请求,保证尽可能不产生饥饿请求。对于MYSQL来说,建议设置为Deadline,对MYSQL来说是很好的调度算法。

查看当前系统支持的磁盘IO调度算法

[root@localhost~]#dmesg | grep -i scheduler

io scheduler noop registered

io scheduler anticipatory registered

io scheduler deadline registered

io scheduler cfq registered (default)  

default代表当前设备使用的缺省的IO调度算法


也可以用以下命令查看:

[root@localhost ~]# more/sys/block/sda/queue/scheduler

noop anticipatory deadline [cfq]

备注:括号里括起来的即为当前调度算法值


修改当前块设备使用的io调度算法为deadline:

 [root@localhost ~]# echo"deadline" > /sys/block/sda/queue/scheduler

  备注:修改立即生效

如果已经部署了MySQL数据库环境,需要重新启动MySQL。








7.Mysql体系


存储引擎针对的是表

1.1)MyISAM存储

1.1.1)表级锁

表损坏和修复

check table tablename

repair table tablename



使用场景:1.非事务类型   2.只读


1.2)Innodb

Innodb使用表空间进行数据存储

innodb_file_per_table

ON独立表空间:tablename.ibd

OFF:系统表空间:ibdataX


show variables like 'innodb_file_per_table';




Innodb 检查状态

show engine innodb status


1.3 Archive存储引擎

1.文件压缩zlib,多IO消耗较小

2.只支持insert和select

3.只允许在自增ID上添加索引

4.使用场景:日志和数据采集类型

1.4) Memory存储类型

1.所有数据保存在内存中 

2.支持HASH和Brtree索引

3.所有固定长度varchar(10) = char(10)







8.修改参数






9.内存配置

内存配置相关参数

1.确定可以使用的内存的上限

2.确定 MySQL的每个连接使用的内存

sort_buffer_size 

join_buffer_size

read_buffer_size 

read_rnd_buffer_size

3.如何为缓存池分配内存

Innodb_buffer_pool_size

总内存-(每个线程所需要的内存*连接数)-系统保留内存

key_buffer_size

select sum(index_length) from information_schema.tables where engine='myisam';













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