mysql性能优化
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()
用于保证唯一性，比如订单编号
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
