mysql:mysql性能优化总结

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql:mysql性能优化总结相关的知识,希望对你有一定的参考价值。

一、Mysql引擎概述

1.MyISAM存储引擎
    MyISAM表是独立于操作系统的,这说明可以轻松地将其从Windows服务器移植到Linux服务器;每当我们建立一个MyISAM引擎的表时,就会在本地磁盘上建立三个文件,文件名就是表明。例如,我    建立了一个MyISAM引擎的tb_Demo表,那么就会生成以下三个文件:
    1.tb_demo.frm,存储表定义;
    2.tb_demo.MYD,存储数据;
    3.tb_demo.MYI,存储索引。
    MyISAM表无法处理事务,这就意味着有事务处理需求的表,不能使用MyISAM存储引擎。MyISAM存储引擎特别适合在以下几种情况下使用:
    1.选择密集型的表。MyISAM存储引擎在筛选大量数据时非常迅速,这是它最突出的优点。
    2.插入密集型的表。MyISAM的并发插入特性允许同时选择和插入数据。例如:MyISAM存储引擎很适合管理邮件或Web服务器日志数据。

    2.Innodb 存储引擎
    InnoDB是一个健壮的事务型存储引擎,这种存储引擎已经被很多互联网公司使用,为用户操作非常大的数据存储提供了一个强大的解决方案。我的电脑上安装的mysql 5.6.13版,InnoDB就是作为默     认的存储引擎。InnoDB还引入了行级锁定和外键约束,在以下场合下,使用InnoDB是最理想的选择:
    1.更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。
    2.事务。InnoDB存储引擎是支持事务的标准MySQL存储引擎。
    3.自动灾难恢复。与其它存储引擎不同,InnoDB表能够自动从灾难中恢复。
    4.外键约束。MySQL支持外键的存储引擎只有InnoDB。
    5.支持自动增加列AUTO_INCREMENT属性。
    一般来说,如果需要事务支持,并且有较高的并发读取频率,InnoDB是不错的选择。

    3.NDBCluster存储引擎
       NDB 存储引擎也叫NDB Cluster 存储引擎,主要用于MySQL Cluster 分布式集群环境,Cluster 是MySQL 从5.0 版本才开始提供的新功能。

    4.Merge存储引擎
    MERGE存储引擎是一组MyISAM表的组合,这些MyISAM表结构必须完全相同,尽管其使用不如其它引擎突出,但是在某些情况下非常有用。说白了,Merge表就是几个相同MyISAM表的聚合器;        Merge表中并没有数据,对Merge类型的表可以进行查询、更新、删除操作,这些操作实际上是对内部的MyISAM表进行操作。Merge存储引擎的使用场景。
    对于服务器日志这种信息,一般常用的存储策略是将数据分成很多表,每个名称与特定的时间端相关。例如:可以用12个相同的表来存储服务器日志数据,每个表用对应各个月份的名字来命名。当有       必要基于所有12个日志表的数据来生成报表,这意味着需要编写并更新多表查询,以反映这些表中的信息。与其编写这些可能出现错误的查询,不如将这些表合并起来使用一条查询,之后再删除Mer       ge表,而不影响原来的数据,删除Merge表只是删除Merge表的定义,对内部的表没有任何影响。

    5.Memory存储引擎
    使用MySQL Memory存储引擎的出发点是速度。为得到最快的响应时间,采用的逻辑存储介质是系统内存。虽然在内存中存储表数据确实会提供很高的性能,但当mysqld守护进程崩溃时,所有的M       emory数据都会丢失。获得速度的同时也带来了一些缺陷。它要求存储在Memory数据表里的数据使用的是长度不变的格式,这意味着不能使用BLOB和TEXT这样的长度可变的数据类型,VARCHAR        是一种长度可变的类型,但因为它在MySQL内部当做长度固定不变的CHAR类型,所以可以使用。
    一般在以下几种情况下使用Memory存储引擎:
    1.目标数据较小,而且被非常频繁地访问。在内存中存放数据,所以会造成内存的使用,可以通过参数max_heap_table_size控制Memory表的大小,设置此参数,就可以限制Memory表的最大大。
    2.如果数据是临时的,而且要求必须立即可用,那么就可以存放在内存表中。
    3.存储在Memory表中的数据如果突然丢失,不会对应用服务产生实质的负面影响。

    6.BDB存储引擎
        BDB存储引擎全称为BerkeleyDB存储引擎,和Innodb一样,也不是MySQL自己开发实现的一个存储引擎,而是由SleepycatSoftware所提供,当然,也是开源存储引擎,同样支持事务安全

    7.FEDERATED存储引擎
    FEDERATED存储引擎所实现的功能,和Oracle的DBLINK基本相似,主要用来提供对远程MySQL服务器上面的数据的访问接口。如果我们使用源码编译来安装MySQL,那么必须手工指定启用FEDERA    TED存储引擎才行,因为MySQL默认是不起用该存储引擎的。

    8.ARCHIVE存储引擎
    ARCHIVE存储引擎主要用于通过较小的存储空间来存放过期的很少访问的历史数据。ARCHIVE表不支持索引,通过一个.frm的结构定义文件,一个.ARZ的数据压缩文件还有一个.ARM的meta信息文件    。由于其所存放的数据的特殊性,ARCHIVE表不支持删除,修改操作,仅支持插入和查询操作。锁定机制为行级锁定。

    9.BLACKHOLE存储引擎
    BLACKHOLE存储引擎是一个非常有意思的存储引擎,功能恰如其名,就是一个“黑洞”。就像我们unix系统下面的“/dev/null”设备一样,不管我们写入任何信息,都是有去无回。

    10.CSV存储引擎
    CSV存储引擎实际上操作的就是一个标准的CSV文件,他不支持索引。起主要用途就是大家有些时候可能会需要通过数据库中的数据导出成一份报表文件,而CSV文件是很多软件都支持的一种较为标准    的格式,所以我们可以通过先在数据库中建立一张CVS表,然后将生成的报表信息插入到该表,即可得到一份CSV报表文件了。

 

二、硬件环境对系统性能的影响

1、典型OLTP应用系统

对于各种数据库系统环境中大家最常见的OLTP系统,其特点是并发量大,整体数据量比较多,但每次访问的数据比较少,且访问的数据比较离散,活跃数据占总体数据的比例不是太大。对于这类系统的数据库实际上是最难维护,最难以优化的,对主机整体性能要求也是最高的。因为不仅访问量很高,数据量也不小。

针对上面的这些特点和分析,我们可以对OLTP的得出一个大致的方向。

虽然系统总体数据量较大,但是系统活跃数据在数据总量中所占的比例不大,那么我们可以通过扩大内存容量来尽可能多的将活跃数据cache到内存中;

虽然IO访问非常频繁,但是每次访问的数据量较少且很离散,那么我们对磁盘存储的要求是IOPS表现要很好,吞吐量是次要因素;

并发量很高,CPU每秒所要处理的请求自然也就很多,所以CPU处理能力需要比较强劲;

虽然与客户端的每次交互的数据量并不是特别大,但是网络交互非常频繁,所以主机与客户端交互的网络设备对流量能力也要求不能太弱。

2、典型OLAP应用系统

用于数据分析的OLAP系统的主要特点就是数据量非常大,并发访问不多,但每次访问所需要检索的数据量都比较多,而且数据访问相对较为集中,没有太明显的活跃数据概念。

基于OLAP系统的各种特点和相应的分析,针对OLAP系统硬件优化的大致策略如下:

数据量非常大,所以磁盘存储系统的单位容量需要尽量大一些;

单次访问数据量较大,而且访问数据比较集中,那么对IO系统的性能要求是需要有尽可能大的每秒IO吞吐量,所以应该选用每秒吞吐量尽可能大的磁盘;

虽然IO性能要求也比较高,但是并发请求较少,所以CPU处理能力较难成为性能瓶颈,所以CPU处理能力没有太苛刻的要求;

虽然每次请求的访问量很大,但是执行过程中的数据大都不会返回给客户端,最终返回给客户端的数据量都较小,所以和客户端交互的网络设备要求并不是太高;

此外,由于OLAP系统由于其每次运算过程较长,可以很好的并行化,所以一般的OLAP系统都是由多台主机构成的一个集群,而集群中主机与主机之间的数据交互量一般来说都是非常大的,所以在集群中主机之间的网络设备要求很高。

3、除了以上两个典型应用之外,还有一类比较特殊的应用系统,他们的数据量不是特别大,但是访问请求及其频繁,而且大部分是读请求。可能每秒需要提供上万甚至几万次请求,每次请求都非常简单,可能大部分都只有一条或者几条比较小的记录返回,就比如基于数据库的DNS服务就是这样类型的服务。

虽然数据量小,但是访问极其频繁,所以可以通过较大的内存来cache住大部分的数据,这能够保证非常高的命中率,磁盘IO量比较小,所以磁盘也不需要特别高性能的;

并发请求非常频繁,比需要较强的CPU处理能力才能处理;

虽然应用与数据库交互量非常大,但是每次交互数据较少,总体流量虽然也会较大,但是一般来说普通的千兆网卡已经足够了。

 

 

三、查询优化

  一、 查询优化有几个很好的工作可以帮助我们去理解sql的性能。

     1、Explain

  技术分享

     
  2、SHOW TABLE STATUS LIKE ‘tb_test1‘

    技术分享

1、Name:表名
2、Engine:表的储存引擎
3、Row_mormat:行的格式
4、Rows:表中的行数
5、Avg_row_lenght:平均每行包含的字节数
6、Data_length:表数据的大小
7、Max_data_length:表数据的最大容量
8、Index_length:索引的大小
9、Data_free:没有被用到的空间
10、Auto_incerement:下一个AUTO_INCREMENT的值
11、Create_time:创建时间
12、Chent_time:使用check table命令或者myisamchk工具最后一次检查表的时间
13、Collation:表的默认字符集和字符列排序规则
14、checksum:如果启用,保存的是整个表的实时校验和
15、Create_opions:创建表的时候指定的其他选项
16、Comment:额外信息

 

  3、show profile、 show profile for query num;

 

  二、sql优化

1.如果一个sql占用总sql的时间不足5%,不用考虑优化,即使在优化,能得到多少的回报
2. 永远用小结果集驱动大的结果集;
3. 尽可能在索引中完成排序;
4. 只取出自己需要的Columns;
5. 仅仅使用最有效的过滤条件;
6.尽可能避免复杂的Join和子查询;
7. 当只要一行数据时使用 LIMIT 1
8. 避免 SELECT *
9. 如果数据有大的备份,比如每个月清除表不用信息,不要一次去delete,一次delete会让数据库产生巨量的事物,瞬间对数据库的产生很大的压力,可以循环每次删一点。
10、优化union查询,如果不是系统强制要求去重复,不要用union,用union all

 

四、索引优化

  

1、如果不是按照索引的最左列开始查找,则无法使用索引
2、不能跳过索引中的列
3、如果索引中有某个列的查询范围,则其右边的索引都失效
4.索性不能使表达式的一部分,也不能是函数的参数
5.不能跳过索引中的列
6.如果索引中有个列的范围查询,则其右边所有列都无法使用索引优化查询
7.如果索引不是按照最左列开始查找,则无法使用索引
8.适合做索性的列最好是不重复的
9.适合做索性的列的长度最好不要太长
10.对于长字符列不能做全列索引,要做前缀索性
11.尽量不要使用多列联合索引   

 

 

、合适的数据类型

  

一.数值类型

Mysql支持所有标准SQL中的数值类型,其中包括严格数据类型(INTEGER,SMALLINT,DECIMAL,NUMBERIC),以及近似数值数据类型(FLOAT,REAL,DOUBLE PRESISION),并在此基础上进行扩展。

扩展后增加了TINYINT,MEDIUMINT,BIGINT这3种长度不同的整形,并增加了BIT类型,用来存放位数据。


整数类型        字节       范围(有符号)      范围(无符号)          用途 

TINYINT        1字节        (-128,127)          (0,255)            小整数值 

SMALLINT       2字节     (-32 768,32 767)       (0,65 535)         大整数值 

MEDIUMINT      3字节    (-8 388 608,8 388 607) (0,16 777 215)      大整数值 

INT或INTEGER   4字节   (-2 147 483 648,2 147 483 647) (0,4 294 967 295) 大整数值 

BIGINT         8字节   (-9 233 372 036 854 775 808,9 223 372 036 854 775 807) (0,18 446 744 073 709 551 615) 极大整数值 

FLOAT          4字节   (-3.402 823 466 E+38,1.175 494 351 E-38),0,(1.175 494 351 E-38,3.402 823 466 351 E+38) 0,(1.175 494 351 E-38,3.402 823 466 E+38) 单精度浮点数值 

DOUBLE         8字节 (1.797 693 134 862 315 7 E+308,2.225 073 858 507 201 4 E-308),0,(2.225 073 858 507 201 4 E-308,1.797 693 134 862 315 7 E+308) 0,(2.225 073 858 507 201 4 E-308,1.797 693 134 862 315 7 E+308) 双精度浮点数值 

DECIMAL 对DECIMAL(M,D) ,如果M>D,为M+2否则为D+2 依赖于M和D的值 依赖于M和D的值 小数值


INT 类型:

在 MySQL 中支持的 5 个主要整数类型是 TINYINT,SMALLINT,MEDIUMINT,INT 和 BIGINT。这些类型在很大程度上是相同的,只有它们存储的值的大小是不相同的。

MySQL 以一个可选的显示宽度指示器的形式对 SQL 标准进行扩展,这样当从数据库检索一个值时,可以把这个值加长到指定的长度。例如,指定一个字段的类型为 INT(6),

就可以保证所包含数字少于 6 个的值从数据库中检索出来时能够自动地用空格填充。需要注意的是,使用一个宽度指示器不会影响字段的大小和它可以存储的值的范围。

万一我们需要对一个字段存储一个超出许可范围的数字,MySQL 会根据允许范围最接近它的一端截短后再进行存储。还有一个比较特别的地方是,

MySQL 会在不合规定的值插入表前自动修改为 0。


UNSIGNED 修饰符规定字段只保存正值。因为不需要保存数字的正、负符号,可以在储时节约一个“位”的空间。从而增大这个字段可以存储的值的范围。

ZEROFILL 修饰符规定 0(不是空格)可以用来真补输出的值。使用这个修饰符可以阻止 MySQL 数据库存储负值。


FLOAT、DOUBLE 和 DECIMAL 类型

MySQL 支持的三个浮点类型是 FLOAT、DOUBLE 和 DECIMAL 类型。FLOAT 数值类型用于表示单精度浮点数值,而 DOUBLE 数值类型用于表示双精度浮点数值。

与整数一样,这些类型也带有附加参数:一个显示宽度指示器和一个小数点指示器。比如语句 FLOAT(7,3) 规定显示的值不会超过 7 位数字,小数点后面带有 3 位数字。


对于小数点后面的位数超过允许范围的值,MySQL 会自动将它四舍五入为最接近它的值,再插入它。

DECIMAL 数据类型用于精度要求非常高的计算中,这种类型允许指定数值的精度和计数方法作为选择参数。精度在这里指为这个值保存的有效数字的总个数,

而计数方法表示小数点后数字的位数。比如语句 DECIMAL(7,3) 规定了存储的值不会超过 7 位数字,并且小数点后不超过 3 位。


忽略 DECIMAL 数据类型的精度和计数方法修饰符将会使 MySQL 数据库把所有标识为这个数据类型的字段精度设置为 10,计算方法设置为 0。

UNSIGNED 和 ZEROFILL 修饰符也可以被 FLOAT、DOUBLE 和 DECIMAL 数据类型使用。并且效果与 INT 数据类型相同。


二.字符串类型

MySQL 提供了8个基本的字符串类型,分别:CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM 各SET等多种字符串类型。

可以存储的范围从简单的一个字符到巨大的文本块或二进制字符串数据。


  字符串类型     字节大小         描述及存储需求

    CHAR         0-255字节          定长字符串 

    VARCHAR      0-255字节          变长字符串 

    TINYBLOB     0-255字节        不超过 255 个字符的二进制字符串 

    TINYTEXT     0-255字节        短文本字符串 

    BLOB         0-65535字节      二进制形式的长文本数据 

    TEXT         0-65535字节      长文本数据 

    MEDIUMBLOB   0-16 777 215字节 二进制形式的中等长度文本数据 

    MEDIUMTEXT   0-16 777 215字节 中等长度文本数据 

    LOGNGBLOB    0-4 294 967 295字节 二进制形式的极大文本数据 

    LONGTEXT     0-4 294 967 295字节 极大文本数据

    VARBINARY(M)                   允许长度0-M个字节的定长字节符串,值的长度+1个字节

    BINARY(M)    M                 允许长度0-M个字节的定长字节符串


CHAR 和 VARCHAR 类型

CHAR 类型用于定长字符串,并且必须在圆括号内用一个大小修饰符来定义。这个大小修饰符的范围从 0-255。比指定长度大的值将被截短,而比指定长度小的值将会用空格作填补。

CHAR 类型可以使用 BINARY 修饰符。当用于比较运算时,这个修饰符使 CHAR 以二进制方式参于运算,而不是以传统的区分大小写的方式。

   CHAR 类型的一个变体是 VARCHAR 类型。它是一种可变长度的字符串类型,并且也必须带有一个范围在 0-255 之间的指示器。CHAR 和 VARCHGAR 不同之处在于 MYSQL 数据库处理

这个指示器的方式:CHAR 把这个大小视为值的大小,不长度不足的情况下就用空格补足。而 VARCHAR 类型把它视为最大值并且只使用存储字符串实际需要的长度

(增加一个额外字节来存储字符串本身的长度)来存储值。所以短于指示器长度的 VARCHAR 类型不会被空格填补,但长于指示器的值仍然会被截短。

因为 VARCHAR 类型可以根据实际内容动态改变存储值的长度,所以在不能确定字段需要多少字符时使用 VARCHAR 类型可以大大地节约磁盘空间、提高存储效率。

VARCHAR 类型在使用 BINARY 修饰符时与 CHAR 类型完全相同。


TEXT 和 BLOB 类型

对于字段长度要求超过 255 个的情况下,MySQL 提供了 TEXT 和 BLOB 两种类型。根据存储数据的大小,它们都有不同的子类型。这些大型的数据用于存储文本块或图像、

声音文件等二进制数据类型。

TEXT 和 BLOB 类型在分类和比较上存在区别。BLOB 类型区分大小写,而 TEXT 不区分大小写。大小修饰符不用于各种 BLOB 和 TEXT 子类型。

比指定类型支持的最大范围大的值将被自动截短。


三.日期和时间类型

在处理日期和时间类型的值时,MySQL 带有 5 个不同的数据类型可供选择。它们可以被分成简单的日期、时间类型,和混合日期、时间类型。

根据要求的精度,子类型在每个分类型中都可以使用,并且 MySQL 带有内置功能可以把多样化的输入格式变为一个标准格式。


 类型     大小(字节)     范围               格式          用途 

 DATE       4        1000-01-01/9999-12-31 YYYY-MM-DD    日期值 

 TIME       3        ‘-838:59:59‘/‘838:59:59‘ HH:MM:SS    时间值或持续时间 

 YEAR       1         1901/2155               YYYY       年份值 

 DATETIME   8       1000-01-01 00:00:00/9999-12-31 23:59:59 YYYY-MM-DD HH:MM:SS 混合日期和时间值 

 TIMESTAMP  4       1970-01-01 00:00:00/2037 年某时 YYYYMMDD HHMMSS 混合日期和时间值,时间戳


DATE、TIME 和 TEAR 类型

MySQL 用 DATE 和 TEAR 类型存储简单的日期值,使用 TIME 类型存储时间值。这些类型可以描述为字符串或不带分隔符的整数序列。如果描述为字符串,

DATE 类型的值应该使用连字号作为分隔符分开,而 TIME 类型的值应该使用冒号作为分隔符分开。

需要注意的是,没有冒号分隔符的 TIME 类型值,将会被 MySQL 理解为持续的时间,而不是时间戳。


MySQL 还对日期的年份中的两个数字的值,或是 SQL 语句中为 TEAR 类型输入的两个数字进行最大限度的通译。因为所有 TEAR 类型的值必须用 4 个数字存储。

MySQL 试图将 2 个数字的年份转换为 4 个数字的值。把在 00-69 范围内的值转换到 2000-2069 范围内。把 70-99 范围内的值转换到 1970-1979 之内。

如果 MySQL 自动转换后的值并不符合我们的需要,请输入 4 个数字表示的年份。

DATEYIME 和 TIMESTAMP 类型

除了日期和时间数据类型,MySQL 还支持 DATEYIME 和 TIMESTAMP 这两种混合类型。它们可以把日期和时间作为单个的值进行存储。

这两种类型通常用于自动存储包含当前日期和时间的时间戳,并可在需要执行大量数据库事务和需要建立一个调试和审查用途的审计跟踪的应用程序中发挥良好作用。

如果我们对 TIMESTAMP 类型的字段没有明确赋值,或是被赋与了 null 值。MySQL 会自动使用系统当前的日期和时间来填充它。


复合类型

MySQL 还支持两种复合数据类型 ENUM 和 SET,它们扩展了 SQL 规范。虽然这些类型在技术上是字符串类型,但是可以被视为不同的数据类型。

一个 ENUM 类型只允许从一个集合中取得一个值;而 SET 类型允许从一个集合中取得任意多个值。


ENUM 类型

ENUM 类型因为只允许在集合中取得一个值,有点类似于单选项。在处理相互排拆的数据时容易让人理解,比如人类的性别。ENUM 类型字段可以从集合中取得一个值或使用 null 值,

除此之外的输入将会使 MySQL 在这个字段中插入一个空字符串。另外如果插入值的大小写与集合中值的大小写不匹配,MySQL 会自动使用插入值的大小写转换成与集合中大小写一致的值。

   ENUM 类型在系统内部可以存储为数字,并且从 1 开始用数字做索引。一个 ENUM 类型最多可以包含 65536 个元素,其中一个元素被 MySQL 保留,用来存储错误信息,

这个错误值用索引 0 或者一个空字符串表示。

MySQL 认为 ENUM 类型集合中出现的值是合法输入,除此之外其它任何输入都将失败。这说明通过搜索包含空字符串或对应数字索引为 0 的行就可以很容易地找到错误记录的位置。


SET 类型

SET 类型与 ENUM 类型相似但不相同。SET 类型可以从预定义的集合中取得任意数量的值。并且与 ENUM 类型相同的是任何试图在 SET 类型字段中插入非预定义的值都会使 

MySQL 插入一个空字符串。如果插入一个即有合法的元素又有非法的元素的记录,MySQL 将会保留合法的元素,除去非法的元素。


一个 SET 类型最多可以包含 64 项元素。在 SET 元素中值被存储为一个分离的“位”序列,这些“位”表示与它相对应的元素。“位”是创建有序元素集合的一种简单而有效的方式。

并且它还去除了重复的元素,所以 SET 类型中不可能包含两个相同的元素。

希望从 SET 类型字段中找出非法的记录只需查找包含空字符串或二进制值为 0 的行。



 1. 使用 ENUM 而不是 VARCHAR,

ENUM 类型是非常快和紧凑的。在实际上,其保存的是 TINYINT,但其外表上显示为字符串。这样一来,用这个字段来做一些选项列表变得相当的完美。如果你有一个字段,比如“性别”,“国家”,“民族”,“状态“

DATETIME,DATE和TIMESTAMP这三种了。从存储空间来看TIMESTAMP最少,四个字节,而其他两种数据类型都是八个字节,多了一倍。而TIMESTAMP的缺点在于他只能存储从1970年之后的时间,而另外两种时间类型可以存放最早从1001年开始的时间。如果有需要存放早于1970年之前的时间的需求,我们必须放弃TIMESTAMP类型,但是只要我们不需要使用1970年之前的时间,最好尽量使用TIMESTAMP来减少存储空间的占用。

 

可扩展性设计之分表/读写分离

  1、分表

垂直切分能更清晰化模块划分,区分治理,水平切分能解决大数据量性能瓶颈问题,因此常常就会把两者结合使用,这在大型网站里是种常见的策略
案例:
以mysql为例,简单购物系统暂设涉及如下表:
1.产品表(数据量10w,稳定)
2.订单表(数据量200w,且有增长趋势)
3.用户表 (数据量100w,且有增长趋势)
以mysql为例讲述下水平拆分和垂直拆分,mysql能容忍的数量级在百万静态数据可以到千万
垂直拆分:
解决问题:
表与表之间的io竞争
不解决问题:
单表中数据量增长出现的压力
方案:
把产品表和用户表放到一个server上
订单表单独放到一个server上
水平拆分:
解决问题:
单表中数据量增长出现的压力
不解决问题:
表与表之间的io争夺
方案:
用户表通过性别拆分为男用户表和女用户表
订单表通过已完成和完成中拆分为已完成订单和未完成订单
产品表 未完成订单放一个server上
已完成订单表盒男用户表放一个server上
女用户表放一个server上(女的爱购物)

  
  技术分享
  
  2、读写分离

    可以百度参考

 

七、可扩展性设计之CacheSearch的利用

通过引入Cache(Redis、Memcached),减少数据库的访问,增加性能。

通过引入Search(Lucene、Solr、ElasticSearch),利用搜索引擎高效的全文索引和分词算法,以及高效的数据检索实现,来解决数据库和传统的Cache软件完全无法解决的全文模糊搜索、分类统计查询等功能。

 

 

 

八、可扩展性设计之使用内存磁盘

现在基础设施的可靠性已经非常高了,比如 EC2 几乎不用担心服务器硬件当机。而且内存实在是便宜,很容易买到几十G内存的服务器,可以用内存磁盘,定期备份到磁盘。

将 MYSQL 目录迁移到 4G 的内存磁盘

mkdir -p /mnt/ramdisksudo mount -t tmpfs -o size=4000M tmpfs /mnt/ramdisk/mv /var/lib/mysql /mnt/ramdisk/mysqlln -s /tmp/ramdisk/mysql /var/lib/mysqlchown mysql:mysql mysql

 


 

参考文章:
http://www.cnblogs.com/luxiaoxun/p/4694144.html
http://www.jb51.net/article/82254.htm
http://www.jb51.net/article/55849.htm

















以上是关于mysql:mysql性能优化总结的主要内容,如果未能解决你的问题,请参考以下文章

mysql性能优化总结

MySQL高性能优化实战总结

史上更全的MySQL高性能优化实战总结!

mysql性能优化-自我总结

一份超详细的MySQL高性能优化实战总结!

mysql:mysql性能优化总结