mysql性能调优与架构设计笔记

 

一、mysql基本介绍mysql

    mysql支持多线程高并发的关系型数据库;web

    数据库存储引擎InnoDB、MyISAM;sql

    mysql快速崛起的缘由就是他是开源的;数据库

    性能一直是mysql自豪的一大特色;后端

 

二、mysql架构组成缓存

    麻雀虽小五脏俱全,mysql虽然简单但其内部结构并不简单;安全

    mysql物理文件组成之日志文件:性能优化

    错误日志error log这里记录mysql运行时严重的警告和错误,以及mysql启动和关闭的日志信息服务器

    二进制日志 binary log 记录mysql运行时全部的query和query执行的时间保存为二进制信息网络

    查询日志 query log 记录全部query 包括select语句 体积较大开启后对性能有所影响

    慢查询日志 slow query log 记录慢查询的日志信息

 

    mysql物理文件组成之数据文件:

    每个数据库都会在定义好的数据目录下存在一个以数据库名字命名的文件夹,用来存放某个数据库各个表的数据信息;

    不一样的数据存储引擎有着不一样的数据文件;

    .frm拓展名的文件:不管是存储引擎,每一个表都会有一个以表名.frm的文件,存放的是表结构的定义

    .MYD拓展名的文件:MyISAM存储引擎专用,存放表数据,每个表都会存在一个以表名.MYD的文件

    .MYI拓展名的文件:MyISAM存储引擎专用,存放表索引数据,每一个表都会存在一个以表名.MYI的文件

    .ibd、.ibdata文件:InnoDB存储引擎专用,存放表数据和表索引,区别在于.ibd是独立存储每一个表信息,每一个表都有一个表名.idb文件这点和MyISAM同样,而ibdata文件是共享表空间存储数据信息;

 

    mysql server系统架构之逻辑模块组成:

    mysql能够当作是二层架构,第一层是sql layer,在mysql数据库系统处理底层数据以前的全部工做都在这一层完成,包括权限判断、sql解析、执行计划优化、query cache等工做,第二层是存储引擎层也就是数据存储实现的部份,有多种存储引擎组成;

    虽然只有两个层可是每一个层都有不少模块组成,也是至关的复杂;

    sql layer层包含:(optimizer 优化程序)

    初始化、核心Api、网络交互、client & server交互协议、用户模块、访问控制模块、

    链接管理链接线程管理、query解析和转化、query cache、query优化器、表变动管理、

    表维护、系统状态管理、表管理、日志记录、复制、存储引擎接口管理

 

    mysql自带工具使用介绍:

    mysql提供大量的客户端工具程序mysql、mysqladmin、mysqldump...

 

三、mysql存储引擎

    mysql存储引擎概述:

    MyISAM储存引擎是mysql默认的存储引擎;

    Innodb存储引擎是第三方插件式存储引擎,是innobase公司开发,其最大特色是提供事务控制等功能;

 

    MyISMA储存引擎简介:

    MyISMA存储引擎的表在数据库中每个表都被存放到三个以表名命名的物理文件中,分别是存放表结构定义的表名.frm文件、表数据表名.MYD文件、表索引表名.MYI文件;

    MyISAM索引类型有三种:B-Tree、R-Tree、full-text,经常使用B-Tree类型索引;

    MyISAM存储引擎有静态固定长度存储FIXED、动态可变长度存储DYNAMIC、压缩存储COMPRESS;

    MyISAM储存引擎中某个表数据文件出错后不会影响到其余表或其余数据信息;

 

    Innodb存储引擎简介:

    mysql中除了MyISAM存储引擎以外适用做普遍就是Innodb存储引擎,他和MyISAM同样遵循开源license协议;

    Innodb的优势就是提供了事务控制功能;

    Innodb提高了MyISAM锁的机制,实现了行锁功能;

    Innodb的数据存储和MyISAM也不同,虽然也有表结构定义信息表名.frm文件,表数据和表索引是在一个文件里面存储.ibd单独的存储、.ibdata共享存储;

 

    Innodb的物理结构能够分红两大类:

    数据文件(存放表数据和表索引数据).ibd单独的存储、.ibdata共享存储两种类型;

    日志文件:请不要所有删除Innodb的日志文件这样会让数据库crash(崩溃),或提示数据丢失;

 

    Memory存储引擎:

    Memory存储引擎就是把数据存储在内存里面的一种引擎;

    Memory存储引擎不会把数据存储在磁盘,存入磁盘的只是表名.frm结构,所以若是数据库crash或者宕机都会致使数据丢失;

 

    小结:多存储引擎是mysql有别于其余数据库的一大特性;后续对经常使用的存储引擎会进行详情介绍;

 

四、mysql安全管理

    对企业来讲数据库保存的数据的安全性是很是重要的;

    数据失去了安全性就等于失去了一切;

    

    数据库系统安全相关因素:

    外围网络安全:mysql是基于网路环境的,而网络自己就存在一种入侵的威胁;要从最外层预防;

                尽可能让mysql存在有保护的局域网环境中;

 

    主机防护:外围网络预防获得了保护,那么仍是会存在入侵的可能,那就是局域网入侵;

        主要是阻止没有受权的设备链接mysql;

        入侵数据库危害盗取数据、删除数据、制造漏洞;

 

    数据库防护:经过第二道防线咱们能够预防一部分威胁,但是容许使用主机登陆的设备是否

                彻底拥有权限呢?是不是可信任的对象呢?

                数据库防线是mysql自身系统的访问控制受权模块,这道防线是mysql入侵的最后一道防线了;

                设置登陆用户名和密码和端口号并并设置权限;

 

    代码防护:sql语句相关安全因素、sql注入攻击、程序代码相关安全因素

 

    DDL、DML、DCL

    数据库定义语言(CREATE ALTER DROP TRUNCATE)

    数据库操做语言(SELECT INSERT UPDATE DELETE EXPLAN)

    数据库控制语言(COMMIT ROLLBACK)

 

    mysql访问控制实现原理:

    mysql访问控制其实有2部分组成:一是用户模块管理、一是访问控制模块管理(权限);

        用户模块决定是否能进入,访问控制模块(权限)决定能有哪些操做;

        例如:客户端请求(提供host,用户名,密码)-->用户模块验证(经过mysql.user表验证)-->

        客户端请求query(DML、DDL)-->解析query执行权限-->权限匹配查找(grant tables中查找)

        -->发日后端继续执行

 

    mysql访问受权策略:

    不是每一个用户的权限都同样无限大;

    每一个用户的权限作到越小越好,知足使用就好;

    首先了解来访主机、了解用户需求、最后为工做分类,这样确保绝对必要拥有者拥有grant(准许)权限;

 

    备注:安全无小事,数据是一个企业的财富;

 

五、mysql数据的备份与恢复

    数据库备份使用的场景:

    数据丢失应用场景:人为误操做、软件bug、硬件故障、安全漏洞

    非数据丢失场景:特殊场景下数据恢复、开发测试数据库搭建、数据库或数据迁移

    备注:数据库数据备份解决问题不是万能的;

 

六、影响mysql server性能的相关因素

    大多都认为数据库应用系统的性能瓶颈是数据库管理软件和数据库主机自身形成的,其实否则;

    下面以mysql数据库web场景为例来分析影响性能的瓶颈;

    商业需求对性能的影响:

        不是全部功能都能实现,有些不合理的功能反而最后成了累赘,消耗资源;

        不合理的需求形成资源投入产出比太低;

        无用功能堆积使系统过分复杂影响总体性能;(无用的功能大多不会下线,由于考虑风险,因此系统愈来愈庞大复杂,不只维护困难,系统性能也愈来愈差)

 

    系统架构及实现对性能的影响:

        一个web应用天然离不开应用程序(web application)和web应用程序服务器(web server),web server咱们控制调优的很少都是很成熟的产品,web application咱们能够优化不少方面;

        如下几类数据不适合存放到数据库中:

            二进制多媒体数据(消耗内存、消耗cpu);

            流水队列数据(不断的进行insert update delete由于每次操做都会写入日志文件影响性能);

            超大文本数据(占用空间浪费资源)

 

        是否合理利用应用层cache机制:mysql memory存储引擎

            经过cache机制成功的案例不少不少,但是失败的案例也不少;

            下面整理哪些可使用cache机制:

                系统各类配置和规则的数据;

                活跃用户的基本信息(缓存用户的基本信息能够大大提高性能);

                时间段的统计数据;

                访问平凡更新较少的数据;

 

        过分依赖数据库sql语句的功能形成数据库操做效率低下:

            尽可能不要在循环中屡次执行sql,有时可使用2个sql,这样不占用IO和解析资源;

            若是一条sql查询的列不是所有使用时请拆分红2个sql,减小不适用列的查询;

            避免重复执行相同的sql浪费资源(这里可能和上面两条像违背,分不一样逻辑考虑取舍)

 

        架构设计不当带来性能问题和资源浪费问题:

            cache命中率低,增长数据库的访问压力,浪费cache资源利用率;

            过分依赖面向对象,对可拓展性的过分追求;

            对数据库的过分依赖,一些不符合存入数据库的应该存入文件系统中;

            过分的在意用户体验,好比不用实时更新的数据实时更新了浪费资源;

 

        query语句对性能的影响:

            当mysql的链接线程接收到client请求的sql时,会通过解析和分析,而后经过执行计划调用存储过程接口,最后把数据返回给client显示;

            执行sql主要是IO消耗和cpu消耗(这里能够经过explain进行测试);

            备注:有时间测试下两个表先链接查询和先查询一个表信息在和另外一个表链接分析哪一个好?

 

        schema(方案)的设计对系统性能的影响:

            数据库设计对性能的提高;

            适当的使用好范式是对设计最大的调优;

 

        硬件环境对性能的影响:

            考虑并发访问比较频繁的时候要考虑服务器IO和CPU处理能力;

 

七、mysql数据库锁定机制

    为了保证数据的完整性任何一种数据库都有锁定的机制;

    一个数据库锁定技术的优劣直接影响数据库高并发处理和性能;

    mysql经常使用存储引擎Innodb、MyISAM

 

    mysql锁定机制简介:

        行级锁定:

            行级锁定最大的特色就是对象的颗粒度很小,是最经常使用的一种形式;

            因为锁定颗粒下取锁和锁定处理的事情比较多,耗内存,也最容易发生死锁;

 

        表级锁定:

            表级锁定与行级锁定的特色正好相反,是锁定mysql存储引擎中最大的颗粒;

            表锁定逻辑简单、处理快、耗能小、不容易死锁;

 

        页级锁定:

            页级锁定是mysql一个比较独特的锁定机制,锁定介于行锁和表锁之间;

            页级锁定和行级锁定同样,很容易被死锁;

 

        备注:行级锁定不是mysql本身的锁定机制,而是第三方Innodb存储引擎的锁定机制;

            Innodb若是产生死锁时会经过检测死锁机制来判断要回滚那个事务sql,这里会根据影响数据的大小来判断,让影响数据大的事务sql执行成功,回滚影响小的事务sql;或者经过死锁机制过时时间来回滚事务sql;

 

        Innodb行级锁的优势:

            在不少线程请求不一样记录时减小冲突;

            事务回滚时减小改变的数据;

            使长时间对单独的一行记录加锁成为可能;

        Innodb行锁的缺点:

            比表级别锁和页级别锁消耗更多的内存;

 

    合理的利用锁机制优化mysql:

        MyISAM的表锁优化建议:

            MyISAM的表锁比行锁和页锁减少了资源,可是必定程度上影响了并发的性能,

            所以优化表锁的建议就是如何提升并发的性能;

            

            缩短锁定时间;

                惟一的办法让sql执行时间尽量的短;

                庞大复杂的sql建议分红多个小sql分布式执行;

                尽量的创建高效的索引和字段类型限制;

 

            分离能并行的操做;

 

            合理利用读写优先级;

 

        Innodb行锁的优化建议:

            Innodb的行锁机制虽然比MyISAM的表锁机制消耗很大的资源可是高并发却远远超于后者;

            Innodb的行锁也有瓶颈的一面:

                查询尽可能使用索引提升查询速度;

                合理的设计索引;

                查询的范围不该过大;

 

        系统锁定状况查询:

            表锁定状况查询:

                SHOW STATUS LIKE '%table%';

                Table_locks_immediate 表锁定的次数

 

                Table_locks_waited    表锁定等待的次数

                Table_locks_waited若是数值变大了说明表争用比较严重,须要优化;

 

            Innodb行锁的状况查询:

                SHOW STATUS LIKE '%innodb_row_lock%';

                Innodb_row_lock_current_waits   //当前正在等待锁定的数量

                Innodb_row_lock_time    //从系统启动到如今锁定总时间长度

                Innodb_row_lock_time_avg    //每次等待所花费的平均时间

                Innodb_row_lock_time_max    //某次等待最长的时间

                Innodb_row_lock_waits   //从系统启动到如今请求的次数

                上述分析:重要的是1 3 5这几个值

 

    Innodb存储引擎的总体性能要高于MyISAM存储引擎

 

八、mysql数据库中query的优化

    mysql query optimizer:

        mysql query optimizer 是query查询优化器模块,提供最优的执行计划;

 

    query语句优化的思路和原则:

        优化更须要优化的query;

        定位优化对象的性能瓶颈;//是IO仍是CPU仍是内存

        明确的优化目标;

        多使用show profiles;

        从explain sql入手; //由于它能够展现执行计划详细信息

        最可能的在索引中排序;

        只取出本身须要的columns;

        使用最有效的过滤条件;

        尽量避免复杂的join和子查询;

 

    优化更须要优化的query:

        两个query每小时执行的IO数是同样的,一个是每小时执行10000次每次消耗20个IO,

        一个是每小时执行10次每次消耗20000个IO那么试问该优化哪一个query呢?

        解答:第一个query把IO从20降到18就减小了2个,那么就2*10000 = 20000个IO

            第二个query若是能减小20000个IO那么20000/10 = 2000个IO那么每次需减小2000个IO

            所以咱们以为那个更好优化呢,哪一个能减小更少的IO呢,第一个query;

 

        执行高并发的query比执行低并发的危险性要高的多,高并发的query很容易让系统crash掉,

        等咱们从新启动后系统负荷就会直线飙升接近crash,让咱们都不能查询问题出如今哪里,

        而低并发的query虽然也产生负荷至少还在可控范围内;

 

    join时的原则就是‘小结果集驱动大结果集的’:

    A表1000数据,B表10万条数据 SELECT A.*, B.name FROM A LEFT JOIN B ON A.id=B.a_id

    //这里就是以A表做为驱动表循环链接B表信息;减小了循环次数;B表示被驱动表;

 

 

    explain sql语句详细分析:

        注意key_len的值,越小越好;

        //也就是说每每一个where条件能够查询到的就不要再用第二个没有意义的条件了哦,由于消耗内存;

 

    mysql中索引的限制:

        MyISAM存储引擎的索引键值长度总和不能超过1000字节;

        mysql目前不支持函数索引;

        mysql查询条件!= 、<>的时候不能使用索引;

        使用like查询 like'%abc'这样没法使用索引;

 

    join的原理和优化思路:

        SELECT A.*

        FROM USER_GROUP A LEFT JOIN GROUP_MESSAGE B ON A.group_id = B.group_id

        LEFT JOIN GROUP_MESSAGE_CONTENT C ON B.id = C.message_id

        WHERE A.user_id = 1;

        //这里是把USER_GROUP表做为驱动表, 先A表经过索引查询出group_id集合做为驱动表,

        //对GROUP_MESSAGE表进行循环查询出id,最后在经过索引message_id查询出最终结果集合;

        

 

        尽量的减小join语句的循环次数;

        链接的字段必须建索引;

        GROUP BY/ ORDER BY尽可能使用索引;

 

九、mysql数据库schema(图标)的设计和调优 

    高效的模型设计:

        首先考虑符合第一第二第三范式;

        适当沉余让query尽可能减小join;

            举例:user表,message表中能够添加个author_name字段;

        大字段垂直分隔;

            blog表中有个content字段text类型能够分隔成blog_detail表;

        统计表准实时更新;

            统计的数据不建议实时更新,这里就是商业需求影响性能,可使用定时实时更新;

 

    合适的数据类型:

        尽可能使用小的数据类型来减小磁盘的空间;

        经过合适的数据类型进行数值比较;

 

    规范的对象命名:

        数据库和表命名应尽量的和所属产品描述相符合;

        字段名也应和该列信息描述相符合;

        索引名称尽可能包含字段名称或字段缩写;

 

    备注:数据库性能的提高不是优化出来的而是设计出来的;

 

十、mysql性能优化

    mysql安装优化:

        安装适合的数据库版本;

 

    mysql日志性能优化:

        错误日志(error log);

        更新日志(update log);

        二进制日志(binlog);

        查询日志(query log);

        慢查询日志(slow query sql);

 

    mysql query cache的优化:

        mysql query cache产生可让mysql性能产生质的飞越;

 

    mysql server的其余优化:

        网络容许的最大链接数;max_connections处理并发能力

        用户容许的组大链接数;max_user_connextions针对于单个用户的链接限制;

        网络包传输中,传输信息以前net_buffer的初始化大小;net_buffer_length;

        网络传输中一次传输信息的最大值;max_allowed_packet;

        mysql链接等待中的最大数量;back_log;

 

十一、经常使用存储引擎优化

    mysql中MyISAM存储引擎优化;

    mysql中Innodb存储引擎优化;

 

十二、mysql可拓展设计的基本原则

1三、可拓展性设计之mysql replication(复制)

1四、可拓展性设计之数据切分

    何为数据切割:

        按照不一样的表来切分到不一样的数据库上这个是垂直(纵向)切割模式;

        把同一个表按照某种逻辑关系分别拆分存放到不一样的数据库上这个是水平切割模式;

 

        备注:垂直分隔的特色就是简单,低耦合的表能够进行垂直分隔;

        若是咱们作了垂直分隔后还任然不能提升性能时咱们还的进行水平分隔;

 

    数据的垂直分隔:

        数据库中的表都是有多个功能模块组成,每一个功能模块以前的耦合度越小越容易进行垂直分隔;

 

    垂直分隔优势:

        数据库拆分简单明了,拆分规则明确;

        应用程序模块清晰明确,整合容易;

        数据维护方便容易定位;

    垂直分隔缺点:

        部分表关联没法在数据库中完成;

        切分红必定程度以后拓展性下降;

 

    数据水平分隔:

        数据的水平分隔是高并发查询的表经过某个字段的规则吧数据分别存放不一样的表中进行查询,

        这样每张表的数据集合就没有以前一张表大,从而来提示查询速度,常见的方案是经过userid

        对5取模而后分别存放到5个表中,显示查询则经过userid对5取模,余数就知道此userid存在哪里;

 

    备注:经过数据分隔技术将一个大的数据mysql server分隔成多个小数据的mysql server,这样提升了

        查询和写入性能, 最佳方案是先进行垂直分隔再进行水平分隔;

 

1五、可拓展性设置cache和search的利用

    分布式缓存cache解决方案memcached;

    利用search实现高效的全文索引;

    备注:数据库只是存储数据的工具,他的特色就是持久化,除了数据库咱们还有不少其余方式的数据存储;

 

1六、mysql cluster(集群)

    mysql cluster是一个基于NDB cluster存储引擎的完整的分布式数据库系统;

相关文章
相关标签/搜索