码迷,mamicode.com
首页 > 数据库 > 详细

mysql性能优化

时间:2014-08-01 04:39:41      阅读:364      评论:0      收藏:0      [点我收藏+]

标签:blog   http   使用   os   strong   io   数据   for   

http://blog.csdn.net/uestc_huan/article/category/536350  博主首页

http://blog.csdn.net/uestc_huan/article/details/6071081 博文地址

本文不从DBA的角度去讲解mysql Server的参数如何设置,而是从程序员和架构师的角度,去说明在写程序和设计系统的时候,需要注意的mysql的一些优化点。因此,没有在本文中详细论述服务器参数的设置含义和调优。

 

 

    关于索引

1. mysql使用的B+tree的深度的计算:

B+树每块数值的大小 = 每个block的大小 / 索引值的大小

比如mysql每个block为4K,索引值设为4个字节的int,那么每个索引块的大小为4k/4 = 1k。

那么存储一亿行的数据,需要的B+树的高度为

h = log1000(一亿) =3 (以1000为底,一亿的对数)。可见B+树的高度不会很高,一般深度都不会超过5.

 

 

2. 为了避免随机IO操作,可以建立联合index来避免随机IO操作。即用“索引-值”对来建立一个联合index。这样,就可以直接从索引中读取数据,而不需要根据索引再去磁盘读取实际的数据。

比如 : select age from user_info where name=lisi;

那么,建立name-age的联合索引,那么从索引就可以直接读取数据。如果仅仅建立name的索引,那么它需要根据name=lisi定位到这行数据的位置,再从这个位置读取出age。

 

 

3. 如果仅仅是点查询,而不需要范围查询,那么使用hash索引会比B+tree索引更快。就是仅仅需要 where aaa=bbb这样的查询条件,而不需要where aaa> bbb这样的查询条件。

 

 4. 使用logloader或者dump的操作速度,会比简单的sql语句快5倍以上。

 

 5.log 放在单独的磁盘上,可缓解io瓶颈。

 

 6.慢查询是影响mysql性能的主要因素。慢查询主要通过分析慢查询日志来处理。很多现有的工具可以分析。诸如 mysqldumpslow,  mysql_slow_log_filter,  mysql_slow_log_parser, mysqlsal等。

 

 

关于事务的理解

1. 事务应该具有ACID属性,(atomicity, consistency, isolation, durability),一致性和持久性比较好理解。原子性和隔离性需要做一些说明。

事务的原子性仅仅指同一个事务本身的原子性。一个事务未执行或者执行一半时,另外的事务(另外一个连接中)是可以并发执行的。这涉及到事务隔离度的概念(isolation)。可以做一个测试,用两个客户端去连接数据库,分别开始事务,分别执行两个进程。只有在事务中执行了upate,insert,delete的语句,并且affect的行数大于0的时候,才会阻塞另外一个事务。而且这个跟数据库的隔离度等级也有关系。

下面是关于隔离度的解释。

(1).查看当前会话隔离级别

select @@tx_isolation;

 

(2).查看系统当前隔离级别

select @@global.tx_isolation;

 

(3).设置当前会话隔离级别

set session transaction isolatin level repeatable read;

 

(4).设置系统当前隔离级别

set global transaction isolation level repeatable read;

 

(5).命令行,开始事务时

set autocommit=off 或者 start transaction

 

关于隔离级别的理解

(1)read uncommitted

可以看到未提交的数据(脏读),举个例子:别人说的话你都相信了,但是可能他只是说说,并不实际做。

 

(2)read committed

读取提交的数据。但是,可能多次读取的数据结果不一致(不可重复读,幻读)。用读写的观点就是:读取的行数据,可以写。

 

(3)repeatable read(MySQL默认隔离级别)

在MySQL中,其他事务新增的数据,看不到,不会产生幻读。采用多版本并发控制(MVCC)机制解决幻读问题。

 

(4)serializable

可读,不可写。写数据必须等待另一个事务结束。

 

 

7. 两个事务是可能发生死锁的,

举个例子:

Transaction1

     Start transaction;

     Update stockprice set close=45.5 where stock_id =4;

     Update stockprice set close=47.7 where stock_id=3;

     Commit;

Transaction2

    Start transaction;

     Update stockprice set close=45.5 where stock_id =3;

     Update stockprice set close=47.7 where stock_id=4;

     Commit;

当两个事务都执行了第一条而未执行第二条时,就发生了死锁。

 

 

关于数据类型

1. 避免用DEFAULT  NULL数值,原因一方面是为了索引速度更快(尽管在高版本的mysql已经不存在这个问题),另一方面是避免应用程序产生一些不必要的困惑和bug.

 

 

2. int(1)和int(20)的区别仅仅是在显示上,对于计算和存储过程,是完全一样的。

 

 

3. DECIMAL在4.1版本及之前,仅仅是存储类型,它的效率比float和double都低。DEMICAL仅仅应该用在金融数字上,因为它可以指定所需要的计算精度。

 

4. Blob和text是最耗性能的。因为内存存储机制(memory storage engine)不支持这两个类型,因为查询这两个类型的数据都会用到磁盘临时表。尽可能避免使用这两种类型数据。如果要对这两种类型的数据排序,用order by substring(column, length)转成string类型。此时如果substring小,可以转成内存临时表,速度会快很多。额外插一句,字符匹配查找算法的最高效率,不会高于KMP算法的效率。

 

 

5.可以用enum代替string类型。Enum最多可以存65535个字符。但此时排序是按enum值排序而非string值排序。

 

6. datetime 和timestamp的比较。

Datatime:  8字节,与时区无关,缺省值是NULL

Timestamp: 4字节,与时区相关,缺省插入值是当前时间。

如果没有特别需要,建议用timestamp。别用整数型数据来存储时间,尽管可以,但不推荐,因为得不到任何好处。

 

7.一般不推荐使用bit的数据类型,用tinyint会更利于扩展。Bit set也可以通过tiny int的位运算来替代。

 

 

8. 不要滥用MySQL的类型自动转换功能

  

 

查询优化

 

1. 用跨库操作语句,可能导致master和slaver不一致现象

就是对db.table这样的语句,可能导致master和slaver不一致。

 

2.mysql用于处理连接和释放连接的效率很高。它被设计成适合简单快速的查询方式。因此,如果能将很复杂的查询分割成多个简单的查询,而在应用层将这些小查询连接起来,效率会更高。主要原因是复杂查询会导致比较大面积的锁定,影响效率。而多个小查询锁的范围就小很多。而连接的开销,在mysql中基本可以忽略。

比如:

Select * from tag

Join tag_post on tag_post.tag_id=tag.id

Join post on tag_post.post_id=post.id

Where tag.tag=’mysql’;

拆分成

Select * from tag where tag=’mysql’;

Select * from tag_post where tag_id=1234;

Select * from post where post.id in (123,2343,4545);

如果应用层能处理这些数据的拆分和组合,那么效率会更高。

这样做的好处:

(1).cache会更有效,不需要中间表临时表的生成。

(2)在应用层做组合,更有利于扩展,可以把某些表单独放在独立的server上,分开放。

(3)锁的范围更小

(4)in的执行效率比join的执行效率高。Mysql的子查询的效率很低。据说6.0会引入semijoin的计划来解决。但目前能少用Join还是少用join.

 

 

3. 几个原则

(1)优化更需要优化的query

(2) 定位优化对象的性能瓶颈,是io还是cpu还是内存

(3)明确优化目标

(4)从explain入手,可以用force index来检查走不同索引的效率。SELECT * FROM TABLE1 FORCE INDEX (FIELD1).

(5)打开profile: 用命令”set profiling”命令。用”show profile”查看概要信息。其它profile操作这里不详细叙述。

 

(6)永远用晓得结果集去驱动大的结果集

(7)尽可能在索引中完成排序

 

(8)不取多余的数据

 

(9) 使用最有效的过滤条件。

(10)尽可能避免使用复杂的join和子查询

 

  

4. 查询语句不要对表格数据进行操作

比如不要使用select * from tablename where  from_unixtime(operatetime) < xxxxx;

而使用select * from tablename where operatetime < unixtimstamp(xxxxx);

 

 

 

 

表设计优化

1. 存储的数据编码最好和表的编码一致。

 

2.根据业务特点合理利用冗余数据,减少Join查询。

 

3.合理利用数据类型,能简单不要复杂,能定长不要变长,能不用字符型就别用字符型。

 

4.索引很重要,合理设计索引。

 

5.将不常用的大字段单独拆分出去。某个字段很大,而且不常用,就不要跟常用的一些信息存储在一张表中。

 

  

一些语句

 

(1)Select for update

用于查询-更新原子操作

(2)LAST_INSERT_ID()

用于保证唯一性,比如订单编号

 

mysql性能优化,布布扣,bubuko.com

mysql性能优化

标签:blog   http   使用   os   strong   io   数据   for   

原文地址:http://www.cnblogs.com/andydao/p/3883822.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!