MySQL使用与优化总结1

内容来自  http://my.oschina.net/u/142836/blog/169415

使用与优化

DB的优化

建立合适的索引:

尽量让所有查询都走索引,这个效果是很明显的。

表空间优化

在删除或更新比较频繁的表上,如果包含varchar,text之类的字段,需要定期地执行表空间优化,optimaize table xxx,整理磁盘碎片,回收表数据和索引数据占用的空闲空间;

配置参数优化

innodb_buffer_pool_size innodb表数据和索引数据的内存缓冲大小,很关键,可以有效减少磁盘IO。innodb_flush_log_at_trx_commit 决定事务日志怎么记录,这个对性能提升也很关键,在线下批量写数据时可以考虑设置为0.或者写操作频繁但允许故障时丢失极少量数据的情况也可以考虑。
query_cache 这个参数有些微妙,因为query cache在数据表中有任何数据修改时就会失效,对于写操作频繁的表来说,有可能还会降低性能。对于读操作为主的表来说,效果还是很明显的,但是通常场景下我们都依赖于前端缓存,所以对于这个参数的设置来说,还要看具体业务场景。
max_connections 控制并发连接数,不能太大,否则后果很严重。

拆分与扩容:

库拆分:一般是把同一实例上的数据库分到多个实例上来分担压力(这种比较简单,做一份复制,应用端改个ip就行),或者是把一个库里面的部分表单独放到另一个实例库中(这种比较麻烦,需要应用端配合修改程序)。
表拆分:也分两种,一种是把一些字段的拆出到新表里,比如按业务分,或者是像text之类的大字段拆分。另一种是表记录数太大,超出了单表承受能力,需要水平扩展到多张表。表拆分比较麻烦,都需要应用端配合修改程序。

SQL的优化

尽量用上索引,能用主键查询最好了
尽量缩小扫描范围,经典场景就是limit分页偏移量的优化,其实在实际业务场景下很有很多类似的场景,我们完全可以按id号或者时间限制来显著缩小查询扫描范围
尽量减少表连接查询,最好是单表查询(表连接可能用上临时表,对DB消耗很大;而单表查询可以快速返回,把计算操作放到前端应用去做,减少DB压力)。如果前端并发没有控制好的话,性能较差的表连接查询可能会拖死DB
尽量做等值查询,不等条件查询和逆向查询不走索引
用union替代or、in操作
不做前置模糊查询,不走索引
排序和分组操作尽量在应用端做,减少DB的CPU压力
在查询列上不作函数运算:select concat(‘foo‘,‘bar‘) as str from xxx;

应用的优化

尽量不在DB端做运算,能在应用端做的事就不依赖DB
text/blob之类的数据尽量不在DB中存储,可以采用其它key/value型的存储
大sql拆分成小sql查,不做表连接
用好连接池,减少连接开销(这里要注意连接池的空闲时间与数据库空闲时间的配置)
有冷热数据的场景,尽量均摊压力
考虑读写分离(这里要注意slave的延时,master写频繁的情况下,slave延时也是另人很头疼的,对数据一致性敏感的应用场景是有隐患的)
最后提一下,preparedstatement,最大的作用是防止SQL注入。预编译功能也可以尝试使用,但是要开启前端sql缓存才好,这个还是看具体应用场景吧,大多数互联网应用还没到靠这个功能来提升性能的情况。

简单故障排查技巧

慢查询排查

日志查看:slow.log,这个是mysql配置文件里设置的,要开启。

实时查看:select * from information_schema.processlist where time > 2;

处理方式:

慢查询日志分析工具:mysqlsla,mysqldumpslow等,对症下药进行SQL优化;

实时的慢查询如果影响了应用的响应,可以直接kill掉查询线程。执行kill [thread_id]即可。

Lock情况排查

确定数据库有锁住情况看两个地方,在processlist中可以看到state那一列有lock相关的状态,这里只能看到一个状态,最主要是通过下面这个命令来查看show innodb engine status,这里会显示详细的锁和事务发生的信息。至于怎么解决,要看应用端怎么来控制了。

Slave延时排查

在slave实例上执行show slave status查看slave的状态,主要关注以下三个:

Slave_IO_Running: Yes // 负责读取binlog的线程是否正常运行
Slave_SQL_Running: Yes // 负责在slave上执行sql的线程是否正常运行
Seconds_Behind_Master: 0 // slave比master延时多长时间,单位:秒
如果出现IO和SQL线程状态为No的情况,那说明slave同步已经停止了,可以通过Last_Error这个看到最近的错误。如果要恢复slave,一般两种操作:一是重做slave,保证数据更准确;一种是跳过出错的sql,stop slave;set global sql_slave_skip_counter=1;start slave;,这是跳过一条sql,也可跳过多条,这种方式可能导致slave数据不一致。

监控

内置命令
status
show global status
show variables
外部监控
第三方的监控工具,可以提供图形化的界面。cacti,ganglia等开源软件都提供了监控mysql的插件。

简单说说mysql高可用

两种方式:
方式一:使用MySQL Cluster:读扩展性好,写性能会有一定下降。不是很成熟,线上慎用。
方式二:Master + Slave配合虚拟IP + LVS + keepalived实现简单的高可用,这种方案的隐患就是:虚拟ip切换间隙会有短暂不可用;slave提升到master会有失败的情况;
最后
数据库一般都存储了应用的关键数据,可以说是一个公司产品的生命,所以数据的安全也非常重要,要做好权限控制(严格控制权限,尽量防止误操作造成数据丢失),及时备份数据(异地,多机房),对于核心敏感数据还要做好保密工作。

推荐阅读:

时间: 2024-10-06 12:03:03

MySQL使用与优化总结1的相关文章

Mysql数据库性能优化(一)

参考 http://www.jb51.net/article/82254.htm 今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能.这里,我们不会讲过多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库. mysql的性能优化无法一蹴而就,必须一步一步慢慢来,从各个方面

架构设计:系统存储(8)——MySQL数据库性能优化(4)

================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的

针对MySQL大表优化方案

详解MySQL大表优化方案 (1).字段 (2).索引 (3).规范查询SQL (4).存储引擎 (5).mysql配置参数优化 (6).mysql读写分离 (7).分区和分表 单表优化: 当单表的数据不是一直在暴增,不建议使用拆分,拆分会带来逻辑,部署,运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量 (1).字段 l 尽量使用TINYINT.SMALLINT

【夯实Mysql基础】记一次mysql语句的优化过程!

1. [事件起因] 今天在做项目的时候,发现提供给客户端的接口时间很慢,达到了2秒多,我第一时间,抓了接口,看了运行的sql,发现就是 2个sql慢,分别占了1秒多. 一个sql是 链接了5个表同时使用了 2个 order by和 1个limit的分页 sql. 一个sql是上一个sql的count(*),即链接了5个表,当然没有limit了(取总数). 2. [着手优化] 1)[优化思路] 第一条是 做client调用 service层的数据缓存 第二条就是 优化sql本身. 这里着重讲一下

Mysql线程池优化笔记

Mysql线程池优化我是总结了一个站长的3篇文章了,这里我整理到一起来本文章就分为三个优化段了,下面一起来看看. Mysql线程池系列一(Thread pool FAQ) 首先介绍什么是mysql thread pool,干什么用的?使用线程池主要可以达到以下两个目的:1.在大并发的时候,性能不会因为过载而迅速下降.2.减少性能抖动 thread pool的工作原理?线程池使用分而治之的方法来限制和平衡并发性.与默认的thread_handling不同,线程池将连接和线程划分开,所以连接数量和执

mysql的配置优化

需求:mysql的参数优化对于不同的网站,极其在线量,访问量,帖子数量,网络情况,以及机器硬件配置都有关系,优化不可能一次万次,需要在工作当中不断的监控观察和调试,才能得到最佳的效果.性能优化影响最大的变量分为连接请求变量和缓冲区变量. 理论总结: 修改vim/my.cnf max_connections = 1024    设置最大连接数为1024 back_log = 100      暂存的连接数量 wait_timeout = 100 interactive_timeout = 100

Mysql监控及优化

一.Mysql连接数 1.配置Mysql连接数: vim /etc/my.cnf [mysqld]下面修改 max_connections=1000 不写默认为100. wait_timeout=60 设置超时时间 2.查看当前连接数: show status like '%Threads_connected%'; show processlist;  二.Mysql缓存 1.开启缓存: vim /etc/my.cnf mysqld下面添加或修改 query_cache_type=on #开启缓

架构设计:系统存储(9)——MySQL数据库性能优化(5)

=================================== (接上文<架构设计:系统存储(9)--MySQL数据库性能优化(5)>) 4-3-3-3.避免死锁的建议 上一篇文章我们主要介绍了MySQL数据库中锁的基本原理.工作过程和产生死锁的原因.通过上一篇文章的介绍,可以确定我们需要业务系统中尽可能避免死锁的出现.这里为各位读者介绍一些在InnoDB引擎使用过程中减少死锁的建议. 正确使用读操作语句 经过之前文章介绍,我们知道一般的快照读是不会给数据表任何锁的.那么这些快照读操作

理解MySQL——索引与优化

转自:理解MySQL——索引与优化 写在前面:索引对查询的速度有着至关重要的影响,理解索引也是进行数据库性能调优的起点.考虑如下情况,假设数据库中一个表有10^6条记录,DBMS的页面大小为4K,并存储100条记录.如果没有索引,查询将对整个表进行扫描,最坏的情况下,如果所有数据页都不在内存,需要读取10^4个页面,如果这10^4个页面在磁盘上随机分布,需要进行10^4次I/O,假设磁盘每次I/O时间为10ms(忽略数据传输时间),则总共需要100s(但实际上要好很多很多).如果对之建立B-Tr

mysql中的优化, 简单的说了一下垂直分表, 水平分表(有几种模运算),读写分离.

一.mysql中的优化 where语句的优化 1.尽量避免在 where 子句中对字段进行表达式操作select id from uinfo_jifen where jifen/60 > 10000;优化后:Select id from uinfo_jifen where jifen>600000; 2.应尽量避免在where子句中对字段进行函数操作,这将导致mysql放弃使用索引 select uid from imid where datediff(create_time,'2011-11