十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
我们先来看第一个阶段,MySQL慢的诊断思路,一般我们会从三个方向来做:
成都创新互联成都网站建设定制制作,是成都网站推广公司,为成都水处理设备提供网站建设服务,有成熟的网站定制合作流程,提供网站定制设计服务:原型图制作、网站创意设计、前端HTML5制作、后台程序开发等。成都网站制作热线:13518219792
第一个方向是MySQL内部的观测
第二个方向是外部资源的观测
第三个方向是外部需求的改造
1.1 MySQL 内部观测
我们来看MySQL内部的观测,常用的观测手段是这样的,从上往下看,第一部分是Processlist,看一下哪个SQL压力不太正常,第二步是explain,解释一下它的执行计划,第三步我们要做Profilling,如果这个SQL能再执行一次的话, 就做一个Profilling,然后高级的DBA会直接动用performance_schema ,MySQL 5.7 以后直接动用sys_schema,sys_schema是一个视图,里面有便捷的各类信息,帮助大家来诊断性能。再高级一点,我们会动用innodb_metrics进行一个对引擎的诊断。
除了这些手段以外,大家还提出了一些乱七八糟的手段,我就不列在这了,这些是常规的一个MySQL的内部的状态观测的思路。除了这些以外,MySQL还陆陆续续提供了一些暴露自己状态的方案,但是这些方案并没有在实践中形成套路,原因是学习成本比较高。
1.2 外部资源观测
外部资源观测这部分,我引用了一篇文章,这篇文章的二维码我贴在上面了。这篇文章是国外的一个神写的,标题是:60秒的快速巡检,我们来看一下它在60秒之内对服务器到底做了一个什么样的巡检。一共十条命令,这是前五条,我们一条一条来看。
1.uptime,uptime告诉我们这个机器活了多久,以及它的平均的负载是多少。
2.dmesg -T | tail,告诉我们系统日志里边有没有什么报错。
3.vmstat 1,告诉我们虚拟内存的状态,页的换进换出有没有问题,swap有没有使用。
4. mpstat -P ALL,告诉我们CPU压力在各个核上是不是均匀的。
5.pidstat 1,告诉我们各个进程的对资源的占用大概是什么样子。
我们来看一下后五条:
首先是iostat-xz 1,查看IO的问题,然后是free-m内存使用率,之后两个sar,按设备网卡设备的维度,看一下网络的消耗状态,以及总体看TCP的使用率和错误率是多少。最后一条命令top,看一下大概的进程和线程的问题。
这个就是对于外部资源的诊断,这十条命令揭示了应该去诊断哪些外部资源。
1.3 外部需求改造
第三个诊断思路是外部的需求改造,我在这里引用了一篇文档,这篇文档是MySQL的官方文档中的一章,这一章叫Examples of Common Queries,文档中介绍了常规的SQL怎么写, 给出了一些例子。文章的链接二维码在slide上。
我们来看一下它其中提到的一个例子。
它做的事情是从一个表里边去选取,这张表有三列,article、dealer、price,选取每个作者的最贵的商品列在结果集中,这是它的最原始的SQL,非常符合业务的写法,但是它是个关联子查询。
关联子查询成本是很贵的,所以上面的文档会教你快速地把它转成一个非关联子查询,大家可以看到中间的子查询和外边的查询之间是没有关联性的。
第三步,会教大家直接把子查询拿掉,然后转成这样一个SQL,这个就叫业务改造,前后三个SQL的成本都不一样,把关联子查询拆掉的成本,拆掉以后SQL会跑得非常好,但这个SQL已经不能良好表义了,只有在诊断到SQL成本比较高的情况下才建议大家使用这种方式。
为什么它能够把一个关联子查询拆掉呢?
这背后的原理是关系代数,所有的SQL都可以被表达成等价的关系代数式,关系代数式之间有等价关系,这个等价关系通过变换可以把关联子查询拆掉。
上面的这篇文档是一个大学的教材,它从头教了关于代数和SQL之间的关系。然后一步步推导怎么去简化这句SQL。
第一,MySQL本身提供了很多命令来观察MySQL自身的各类状态,大家从上往下检一般能检到SQL的问题或者服务器的问题。
第二,从服务器的角度,我们从巡检的脚本角度入手,服务器的资源就这几种,观测手法也就那么几种,我们把服务器的资源全部都观察一圈就可以了。
第三,如果实在搞不定,需求方一定要按照数据库容易接受的方式去写SQL,这个成本会下降的非常快,这个是常规的MySQL慢的诊断思路。
首先定义三个表,学生(id,sno,name),课程(cid,cname),成绩表(sid,id,cid,score),这样,数据库表基本定义完成,这个是数据库操作的关键,接下来用sql语句给每张表插入数据:例如学生表,id自增长
insert into student(sno,sname) values(学号,学生姓名)
参考一下。
数据库设计需求
1. 需求概述
建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。
数据库的框架和结构必须根据设备和运行状态而设计,方便提供强大的录入、查询、统计、分析和报表等各种功能操作,较好的反映平台业务的基本情况和运行状况,满足平台的基本要求。
2. 外部设计需求
2.1 标识符和状态
数据库表前缀:根据模块名定义(如用户模块:sys_)
用户名:root
密码:待定
权限:全部
有效时间:开发阶段
说明:系统正式发布后,可能更改数据库用户/密码。
2.2 使用它的程序
本系统主要利用java作为后端的应用开发工具,使用MySQL作为后台的数据库, Linux或Windows均可作为系统平台。
2.3 约定
所有命名一定要具有描述性,杜绝一切拼音、或拼音英文混杂的命名方式。
字符集采用 UTF-8,请注意字符的转换。
所有数据表第一个字段都是系统内部使用主键列,自增字段,不可空,名称为:id,确保不把此字段暴露给最终用户。
除特别说明外,所有日期格式都采用date格式。
除特别说明外,所有字段默认都设置不充许为空, 需要设置默认值。
所有普通缩影的命名都是表名加设置缩影的字段名组合,例如用户表User中name字段设置普通所以,则缩影名称命名方式为user_name_index。
2.4 专门指导
对本系统的开发者、使用这、测试员和维护人员,提出以下参考意见:
在使用数据库时,首先要参考上面的约定内容,做好软件的安装以及表格的建立。
数据库的输入统一采用键盘。对于数据库的使用权限,请参考本系统其他相关文档。
数据库的后台管理员没用等级差异,可根据实际情况添加删除管理员。
2.5 支持软件
操作系统: Linux / Windows
数据库系统:MySQL
查询浏览工具:Navicat Premium
命令行工具:mysql
注意:mysql 命令行环境下对中文支持不好,可能无法书写带有中文的 SQL 语句。
3. 结构设计需求
3.1 概念结构设计需求
概念数据库的设计是进行具体数据库设计的第一步,概念数据库设计的好坏直接影响到逻辑数据库的设计,影响到整个数据库的好坏。
我们已经得到了系统的数据流程图和数据字典,现在就是要结合数据规范化的理论,用一种模型将用户的数据要求明确地表示出来。
概念数据库的设计应该极易于转换为逻辑数据库模式,又容易被用户所理解。概念数据库设计中最主要的就是采用“实体-关系数据”模型来确定数据库的结构。
数据是表达信息的一种重要的量化符号,是信息存在的一种重要形式。数据模型则是数据特征的一种抽象。它描述的是数据的共性,而不是描述个别的数据。一般来说,数据模型包含两方面内容:
数据的静态特性:主要包括数据的基本结构、数据间的关系和数据之间的相互约束等特性。
数据的动态特性:主要包括对数据进行操作的方法。
在数据库系统设计中,建立反映客观信息的数据模型,是设计中最为重要的,也最基本的步骤之一。
数据模型是连接客观信息世界和数据库系统数据逻辑组织的桥梁,也是数据库设计人员与用户之间进行交流的共同基础。概念数据库中采用的实体-关系模型,与传统的数据模型有所不同。“实体-关系”模型是面向现实世界,而不是面向实现方法的,它主要是用使用方便,因而在数据库系统应用的设计中,得到了广泛应用。“实体-关系”模型可以用来说明数据库中实体的等级和属性。
以下是实体-关系模型中的重要标识:
在数据库中存在的实体;
实体的属性;
实体之间的关系;
3.2 逻辑结构设计需求
物理结构设计需求
1)定义数据库、表及字段的命名规范:
数据库、表及字段的命名要遵守可读性原则。
数据库、表及字段的命名要遵守表意性原则。
数据库、表及字段的命名要遵守长名原则。
2)选择合适的存储引擎:
3)为表中的字段选择合适的数据类型。
4)建立数据库结构
4. 运用设计需求
4.1 表名的命名规范
表名以英文单词、单词缩写、简写、下划线构成,总长度要求小于30位。
4.2 表字段的命名规范
字段名以英文单词、单词缩写、简写、下划线构成,总长度要求不超过30位。
字段名以名词或名词短语,字段采用单数形式。若表名由多个单词组成,则取各个单词的缩写组成,单词缩写间使用下划线作为分隔。
若某个字段是引用某个表的外键,则字段名应尽量与源表的字段名保持一致,一面混淆。
5. 安全保密设计需求
5.1 防止用户直接操作数据库的方法
通过把关键应用服务器和数据库服务器进行分离,防止用户对数据库服务器的直接操作,保证数据库安全。
5.2 应用系统的用户口令进行加密
在软件系统中,对于数据的保护、业务操作的许可是通过识别用户身份和权限来完成的。用户口令相比较,相同的话系统将该用户的操作权限分配给用户,用户再根据所分配的权限对系统进行操作。
由以上过程可知,用户口令在传输过程中容易被窃取泄漏,另外如果数据库被非法进入则其中保存的口令能够被非法查看。因此,在传输过程中和数据库中的口令记录字段不应使用明文传递和保存,应该在口令被传递前对其明文口令使用有效的主流技术,对传输数据进行加密部分描述的加密算法进行加密,在加密后传输到系统。系统将用户提交的经过加密的口令数据保存的加密口令进行比较,相一致则进行后续操作。