Windows 7 质量优化,windows质量优化

Linux-CPU性能优化,

前言

何为性能优化?个人认为,性能优化是为了提高应用程序或系统能力为目的。那么如何才能实现对应用程序的性能调优呢?这里很设计到很多的内容,包括Linux内核、CPU架构以及Linux内核对资源的分配以及管理,了解进程的创建过程等。这方面由于篇幅较多,所以我的文章就不过多介绍。接下来的几篇文章中,都是讲解如何发现应用程序故障根源为目标讲解,这也是每一个系统工程师应该具备的能力。废话不多说,我直接进入主题。

常用术语

  延时:延时是描述操作之后用来等待返回结果的时间。在某些情况下,它可以指的是整个操作时间,等同于响应时间。

  IOPS:每秒发生的输入/输出操作的次数,是数据传输的一个度量方法。对于磁盘的读写,IOPS指的是每秒读写的次数。

  响应时间:一般操作完成的时间。包括用于等待和服务的时间,也包括用来返回结果的时间。

  使用率:对于服务所请求的资源,使用率描述在所给定时间区间内资源的繁忙程度。对于春初资源来说,使用率指的就是所消耗的存储容量。

  饱和度:指的就是某一资源无法满足服务的排队工作量。

  吞吐量:评价工作秩序的速率,尤其是在数据传输方面,这个属于用于数据传输速度(字节/秒和比特/秒)。在某些情况下,吞吐量指的是操作的速度。

Linux内核功能

  CPU调度级别:各种先进的CPU调度算法,非一直存储访问架构(NUMA);

  I/O调度界别:I/O调度算法,包括deadline/anticipatory和完全公平队列(CFQ);

  TCP网络阻塞:TCP拥堵算法,允许按需选择;

常见问题

进程、线程和任务之间的区别是什么?

  进程通常定义为程序的执行。用以执行用户级别程序的环境。它包括内存地址空间、文件描述符、线程栈和寄存器。
  线程是某一进程中单独运行的程序。也就是说线程在进程之中。
  任务是程序完成的某一活动,可以使一个进程,也可以是一个线程。

参考连接:

什么是上下文切换?

  执行一段程序代码,实现一个功能的过程介绍,当得到CPU的时候,相关的资源必须也已经就位,就是显卡、内存、GPS等,然后CPU开始执行。这里除了CPU以外所有的就构成了这个程序的执行环境,也就是我们所定义的程序上下文。当这个程序执行完或者分配给他的CPU执行时间用完了,那它就要被切换出去,等待下一次CPU的临幸。在被切换出去的最后一步工作就是保存程序上下文,因为这个是下次他被CPU临幸的运行环境,必须保存。

I/O密集型和CPU密集型工作负载之间的区别?

  I/O密集型指的是系统的CPU耗能相对硬盘/内存的耗能能要好很多,此时,系统运作,大部分的状况是
CPU 在等
I/O(硬盘/内存)的读/写,此时CPU负载不高。CPU密集型指的是系统的硬盘/内存耗能相对CPU的耗能要好很多,此时,系统运作,大部分的状况是
CPU负载 100%,CPU 要读/写 I/O
(硬盘/内存),I/O在很短的时间就可以完成,而CPU还有许多运算要处理,CPU负载很高。一般而言CPU占用率相当高,大部份时间用来做计算、逻辑判断等CPU动作的程序。

应用程序性能技术

1.选择I/O尺寸
  执行I/O的开销包括初始化缓冲区、系统调用、上下文切换、分配内核元数据、检查进程权限和限制、映射地址到设备、执行内核和驱动代码来执行I/O,以及在最后释放元数据和缓冲区。增加I/O尺寸是应用程序提高吞吐量的常用策略。
2.缓存
  操作系统用缓存提高文件系统的读性能和内存的分配性能,应用程序使用缓存也处于类似的原因。将经常执行的操作结果保存在本地缓存中以备后用,而非总是执行开销较高的操作。
3.缓冲区
  为了提高写操作性能,数据在送入下一层级之前会合并并放在缓冲区中。这样会增加写延时,因为第一次写入缓冲区后,在发送之前,还要等待后续的写入。

  1. 并发和并行
      并行:装在和开始执行多个可运行程序的能力(比如,同时接电话和吃饭)。为了利用多核处理器系统的优势,应用程序需要在同一时间运行在多颗CPU上,这种方式称为并行。应用程序通过多进程或多线程实现。
      并发:有处理多个任务的能力,不一定要同时。比如,接完电话在去吃饭,存在资源抢占;
      同步原语:同步原语监管内存的访问,当不允许访问时,就会引起等待时间(延时)。常见三种类型:
      mutex锁:只有锁持有者才能操作,其他线程会阻塞并等待CPU;
      自旋锁:自旋锁允许锁持有者操作,其他的需要自旋锁的线程会在CPU上循环自选,检查锁是否被释放。虽然这样可以提供低延时的访问,被阻塞的线程不会离开CPU,时刻准备着运行知道锁可用,但是线程自旋、等待也是对CPU资源的浪费。
      读写锁:读/写锁通过允许多个读者或者只允许一个写者而没有读者,来保证数据的完整性。
      自适应自旋锁:低延迟的访问而不浪费CPU资源,是mutex锁和自旋锁的混合。
    5.绑定CPU

关于CPU性能分析

uptime:
  系统负载,通过汇总正在运行的线程数和正在排队等待运行的线程数计算得出。分别反映1/5/15分钟以内的负载。现在的平均负载不仅用来表示CPU余量或者饱和度,也不能单从这个值推断出CPU或者磁盘负载。

vmstat:
  虚拟内存统计信息命令。最后几列打印系统全局范围内的CPU使用状态,在第一列显示可运行进程数。如下所示:

1234 [[email protected] ~]# vmstat procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----r  b   swpd   free   buff   cache   si   so    bi    bo   in   cs us sy id  wa  st0  0   0    14834208 158384 936512  0     0     0     0    1   3   0  0 100  0  0

提示:

  r: 运行队列长度和正在运行的线程数;

  b: 表示阻塞的进程数;

  swpd:
虚拟内存已使用的大小,如果大于0,表示你的机器物理内存不足了,如果不是程序内存泄露的原因,那么你该升级内存了或者把耗内存的任务迁移到其他机器;

  si: 每秒从磁盘读入虚拟内存的大小,如果这个值大于0,表示物理内存不够用或者内存泄露了,要查找耗内存进程解决掉。我的机器内存充裕,一切正常。

  so: 每秒虚拟内存写入磁盘的大小,如果这个值大于0,同上;

  bi: 块设备每秒接收的块数量,这里的块设备是指系统上所有的磁盘和其他块设备,默认块大小是1024byte,我本机上没什么IO操作,所以一直是0,但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s,磁盘写入速度差不多140M每秒;

  bo: 块设备每秒发送的块数量,例如我们读取文件,bo就要大于0。bi和bo一般都要接近0,不然就是IO过于频繁,需要调整;

  in: 每秒CPU的中断次数,包括时间中断;

  cs:  每秒上下文切换次数,例如我们调用系统函数,就要进行上下文切换,线程的切换,也要进程上下文切换,这个值要越小越好,太大了,要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中,我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了。系统调用也是,每次调用系统函数,我们的代码就会进入内核空间,导致上下文切换,这个是很耗资源,也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换,导致CPU干正经事的时间少了,CPU没有充分利用,是不可取的。

  st: cpu在虚拟化环境上在其他租户上的开销;

mpstat:
  多处理器统计信息工具,能够报告每个CPU的统计信息。

1234567891011121314151617 [[email protected] ~]# mpstat -P ALL 1Linux 2.6.32-573.el6.x86_64 (zbredis-30104)     09/14/2017  _x86_64_    (12 CPU) 03:14:03 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle03:14:04 PM  all    0.00    0.00    0.08    0.00    0.00    0.00    0.00    0.00   99.9203:14:04 PM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    4    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    5    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    6    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    7    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    8    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM    9    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM   10    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.0003:14:04 PM   11    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

提示:

  irq: 硬件中断CPU用量;

  sofr: 软件中断CPU用量;
  steal: 耗费在服务其他租户的时间;
  guest: 花在访客虚拟机的时间;

  重要关注列有%user/%sys/%idle。显示了每个CPU的用量以及用户态和内核态的时间比例。可以根据这些值查看那些跑到100%使用率(%user
+
%sys)的CPU,而其他CPU并未跑满可能是由单线程应用程序的负载或者设备中断映射造成。

sar:

  系统活动报告器。用来观察当前的活动,以及配置用以归档和报告历史统计信息。基本上所有资源使用的信息,它都能够查看到。具体的参数说明如下所示:

  -A: 所有报告的总和,类似”-bBdqrRSuvwWy -I SUM -I XALL -n ALL -u ALL
-P ALL”参数一起使用;
  -b: 显示I/O和传输速率的统计信息;
  -B:显示分页状态;
  -d:硬盘使用报告;
  -r:内存和交换空间的使用统计;
  -g:串口I/O的情况;
  -b:缓冲区使用情况;
  -a:文件读写情况;
  -c:系统调用情况;
  -n: 统计网络信息;
  -q:报告队列长度和系统平均负载;
  -R:进程的活动情况;
  -y:终端设备活动情况;
  -w:系统交换活动;
  -x { pid | SELF | ALL
}:报告指定进程ID的统计信息,SELF关键字是sar进程本身的统计,ALL关键字是所有系统进程的统计;

常用参数组合:

  查看CPU:

  整体CPU统计— sar -u 3 2,表示采样时间为3秒,采样次数为2次;
  各个CPU统计— sar -P ALL 1 1,表示采样时间为1秒,次数为1次;

    1. 若 %iowait 的值过高,表示硬盘存在I/O瓶颈;
    2. 若 %idle 的值高但系统响应慢时,有可能是 CPU
等待分配内存,此时应加大内存容量;
    3. 若 %idle 的值持续低于1,则系统的 CPU
处理能力相对较低,表明系统中最需要解决的资源是 CPU;

  查看内存:

  查看内存使用情况 – sar -r 1 2

    kbcommit:保证当前系统所需要的内存,即为了确保不溢出而需要的内存(RAM+swap);
    %commit:这个值是kbcommit与内存总量(包括swap)的一个百分比;

  pidstat:主要用于监控全部或指定进程占用系统资源的情况,如CPU,内存、设备IO、任务切换、线程等。

  cpu使用情况统计
    执行 “pidstat -u” 与单独执行 “pidstat”
  内存使用情况统计
    pidstat -r -p PID 1

    minflt/s: 每秒次缺页错误次数(minor page
faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page
fault次数;
    majflt/s: 每秒主缺页错误次数(major page
faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page
fault为major page fault,一般在内存使用紧张时产生;
  IO情况统计
    pidstat -d 1 2

关于CPU方面的优化

  1.编译器优化
  2.调度优先级和调度类(设置nice值)
    例如,nice -n 19 command
    renice 更改已经运行进程的优先级;
    chrt 命令显示并直接修改优先级和调度策略;
  3.进程绑定(一个进程可以绑定在一个或者多个CPU上)
    例如,taskset -pc 0-3 10790

  4.独占CPU
  5.BIOS调优

    启用睿频

出处:

参考:

查看评论

前言
何为性能优化?个人认为,性能优化是为了提高应用程序或系统能力为目的。那么如何才能实现对应用程序的性能…

前端性能优化(一),性能优化(

从1月10号第一篇文章开始,到现在过去了4个月又20天,陆续写下了性能优化系列文章共计十二篇,大概一个月三篇的节奏。本篇文章是性能系列文章的最后一篇,没有新的大方向优化,讲一下写性能优化系列文章的些许事情:初心,过程,所得。

Windows 7 性能优化,windows性能优化

1、“计算机”

2、右键》“属性”

3、“高级系统设置”》“高级”

4、“性能”》“设置”

5、“视觉效果”,这一项默认的选择为:“让Windows选择计算机的最佳设置(L)”,我们现在选择“自定义”,并勾选以下选项(其它选项全部取消选择):

  • 平滑字体边缘;
  • 在窗口和按钮上使用视觉样式。

 

总结:

节省至少2G左右的内存空间。

7 性能优化,windows性能优化 1、“计算机”
2、右键》“属性” 3、“高级系统设置”》“高级” 4、“性能”》“设置”
5、“视觉效…

Mysql性能优化二,mysql性能优化

接上一篇Mysql性能优化一

构建对象模型

浏览器要在屏幕上渲染内容,需要先构建 DOM 与 CSSOM
树。因此,我们需要确保将 HTML 和 CSS 尽可能快地提供给浏览器。

 

让我们从最简单的可能情况开始说:一个普通 HTML
网页,包含一些文字,一张图片。浏览器需要做什么才能处理这个简单页面呢?

图片 1

图片 2

上述整个流程的最终输出是文档对象模型,即这个简单网页的
“DOM”,浏览器使用它完成页面的所有后续处理。

每次浏览器处理 HTML
标记,都要完成上述各个步骤:将字节转换为字符,确认符号,将符号转换为节点,然后构建
DOM 树。整个过程需要一些时间,处理大量 HTML 时更是如此。

图片 3

 

Note

  • 我们假定您对 Chrome DevTools 有基本了解 –
    也就是说,您知道如何捕获网络瀑布图,或是录制时间轴。如果您需要快速重温,请访问Chrome开发者文档,又或您是首次使用
    DevTools,我们建议学习 Codeschool  DevTools课程。

  如果您打开 Chrome
DevTools,并在页面加载时录制时间轴,你可以看到执行这一步骤所需的实际时间
— 在上例中,将一堆 HTML 字节转换为 DOM 树大约需要 5
毫秒。当然,如果页面更大(大多数页面都是如此),这个过程需要的时间估计会更多。在后面创建流畅动画的章节中,您会看到,如果浏览器必须处理大量
HTML,这很可能变成你的瓶颈。

  DOM
树准备就绪后,我们是否就有足够信息在屏幕上渲染页面了?还不行!DOM
树捕获文档标记的属性及关系,但没有告诉我们元素在渲染时是什么样子。这是
CSSOM 的责任,也就是我们接下来要讲的。

 

1、 初心

建立适当的索引     

说起提高数据库性能,索引是最物美价廉的东西了。不用加内存,不用改程序,不用调sql,只要执行个正确的’create
index’,查询速度就可能提高百倍千倍,这可真有诱惑力。可是天下没有免费的午餐,查询速度的提高是以插入、更新、删除的速度为代价的,这些写操作,增加了大量的I/O。

是不是建立一个索引就能解决所有的问题?ename上没有建立索引会怎样?

select * from emp where ename='研发部';

—测试案例命令如下 (最好以 select * from emp e,dept d where
e.empno=123451 )

*添加主键

ALTER TABLE emp ADD PRIMARY KEY(empno);

*删除主键

alter table emp drop primary key;

CSS 对象模型 (CSSOM)

浏览器在构建我们的简单页面 DOM 时,在文档的 head 部分碰上一个 link
标签,引用了外部 CSS 样式表
style.css。浏览器预见到它会需要这个资源来渲染页面,因此会立即发出一个该资源的请求,该请求返回以下内容:

    body { font-size: 16px }
    p { font-weight: bold }
    span { color: red }
    p span { display: none }
    img { float: right }

当然,我们本可以在 HTML 标记中直接声明样式(内联),但是,将 CSS 与 HTML
分开,我们就可以分离关注点:设计人员处理 CSS,开发人员关注 HTML,等等。

与 HTML 一样,我们需要将收到的 CSS
规则转换为浏览器可以理解、能够处理的东西。因此,我们再重复一次与处理
HTML 非常相似的过程:

图片 4

CSS
字节会转换为字符,然后转换为符号和节点,最后链接进树状结构上,即所谓「CSS
对象模型」,缩写为 CSSOM:

图片 5

CSSOM 为什么采用树状结构?
在给页面上的一切对象计算最终的样式集时,浏览器会先从应用给该节点的最通用规则开始(例如,如果节点是
body 元素的子元素,则应用所有 body
样式),然后,通过应用更具体的规则递归细化计算的样式 –
亦即规则「向下层叠」。

再具体点说,我们来看一下上面的 CSSOM 树。body
元素中 span 标记内包含的任何文字均是 16 像素字体大小,红色文本 –
font-size 指令从 body 向下层叠到 span。但是,如果 span 标签是 paragraph
(p) 标签的子标签,则它的内容不会显示。

此外,请注意,上面的树不是完整的 CSSOM
树,它只显示了我们决定在样式表中覆盖的样式。每个浏览器都会提供一套默认的样式,也称为「用户代理样式」
– 即我们不提供任何自定义样式时看到的样式 –
我们的样式只是覆盖这些默认样式集(例如 默认 IE 样式)。如果您曾在 Chrome
DevTools
中检查过「计算的样式」,并且想知道所有样式从何来,现在您应该知道答案了!

好奇 CSS 处理需要的时间? 在 DevTools 中录制时间轴,并查找 “Recalculate
Style” 事件:与 DOM 解析不同,timeline 不显示单独的 “Parse CSS”
条目,而是在 “Recalculate Style” 这一个事件下一同捕获解析、CSSOM
树的构建及计算的样式的递归计算。

图片 6

处理我们的小样式表需要大约 0.6 毫秒,影响网页上的 8 个元素 –
时间不多,但也会产生成本。只不过,8 个元素从何而来呢?CSSOM 和 DOM
是独立的数据结构。结果证明,浏览器隐藏了一个重要步骤。接下来,让我们聊聊将
DOM 与 CSSOM 链接在一起的渲染树。

 

构建对象模型
浏览器要在屏幕上渲染内容,需要先构建 DOM 与 CSSOM
树。因此,我们需要确保将 HTML 和 CS…

1.1 为什么要做全方位、深入的性能优化?

故事发生在去年年底:某版本上线前当我打开App,唯一的体验就是那如同乌龟爬行般的启动速度。不仅被竞品碾压,更是碾压了我的技术荣辱心:自己做出的App表现差,就是自己差!这是我下定决心要对项目做性能优化的起因。

索引的原理说明     

没有索引为什么会慢?

使用索引为什么会快?

btree类型的索引,就是使用的二分查找法,肯定快啊,算法复杂度是log2N,也就是说16条数据查4次,32条数据查5次,64条数据查6次….依次类推

索引的代价

1、磁盘占用

2、对dml(update delete insert)语句的效率影响

btree 方式检索,算法复杂度: log2N 次数

 图片 7

1.2 为什么写系列文章?

既然要实践性能优化,而我自己也有知识整理的习惯,那么写系列文章自然是水到渠成,顺便是对自己的一个督促。但还有一个原因:

  • 翻阅各种资料,我发现,官方文档作为性能优化过程中最佳的参考资料,而国内开发者的翻译水平不敢过于恭维以及很多开发者关注的角度不一,导致很少有优秀并且全面的参考文章。

那既然我要做性能优化,就挑战下这个优秀且全面。也留下好的参考文章给后来的人!

哪些列上适合添加索引       

1、较频繁的作为查询条件字段应该创建索引

select * from emp where empno = 1;

2、唯一性太差的字段不适合单独创建索引,即使频繁作为查询条件

   select * from emp where sex = '男'

3、更新非常频繁的字段不适合创建索引

select * from emp where logincount = 1

4、不会出现在WHERE子句中的字段不该创建索引

2、 过程

索引的类型             

  • 主键索引,主键自动的为主索引 (类型Primary)
  • 唯一索引 (UNIQUE)
  • 普通索引 (INDEX)
  • 全文索引 (FULLTEXT) [适用于MyISAM] ——》sphinx + 中文分词   
    coreseek [sphinx 的中文版 ]
  • 综合使用=>复合索引

简述mysql四种索引的区别

lPRIMARY 索引 =》在主键上自动创建

lUNIQUE 索引=> 只要是UNiQUE
就是Unique索引.(只能在字段内容不重复的情况下,才能创建唯一索引)

lINDEX 索引=>就是普通索引

lFULLTEXT => 只在MYISAM 存储引擎支持,
目的是全文索引,在内容系统中用的多, 在全英文网站用多(英文词独立).
中文数据不常用,意义不大,国内全文索引通常使用
sphinx来完成,全文索引只能在 char varchar text字段创建.

全文索引案例

1.创建表

create table news(id int , title varchar(32),con varchar(1024)) engine=MyISAM;

2.建立全文索引

create fulltext index ful_inx on news (con);

3.插入数据

这里要注意,对于常见的英文 fulltext
不会匹配,而且插入的语句本身是正确的.

‘but it often happens that they are not above supporting themselves by
dishonest means.which should be more disreputable.Cultivate poverty like
a garden herb’

4.看看匹配度

mysql> select match(con) against('poverty') from news;

+-------------------------------+

| match(con) against('poverty') |

+-------------------------------+

|                             0 |

|                             0 |

|                             0 |

|            0.9853024482727051 |

+-------------------------------+

0表示没有匹配到,或者你的词是停止词,是不会建立索引的.

使用全文索引,不能使用like语句,这样就不会使用到全文索引了.

复合索引

create index 索引名 on 表名(列1,列2);

2.1 性能优化不是温馨的请客吃饭

性能优化的过程是一个非常困难的过程,需要你对优化的方向不仅有知识上的充足储备还要有对现存业务上的了解。拿第一篇App启动优化来举例:

  1. 查看官方文档对启动优化的概述;
  2. 梳理App启动的逻辑;
  3. 使用工具对启动逻辑代码进行准确的度量;
  4. 针对瓶颈确定优化方案;
  5. 优化、测试。

难点在于中间三步:

  • App多人开发,又历经多个版本,没人说得清App启动有多少逻辑以及补偿逻辑;
  • 不同风格的代码读起来,那感觉绝对是一个酸爽;
  • 确认了问题点,如何优化?重构还是重做?

而整理文章的过程更是难上加难,发布出来文章就是自己的一种承诺,既要具备专业性、又要通俗易懂;既要有深度,优化的招数又要尽可能的全面。因此查文档、翻源码是家常便饭。而平时工作也较忙,因此对于一个月三篇的节奏我甚至觉得有点高产(捂脸)。

索引的使用             

建立索引

create [UNIQUE|FULLTEXT]  index index_name on tbl_name (col_name [(length)] [ASC | DESC] , …..);
alter table table_name ADD INDEX [index_name]  (index_col_name,...)

添加主键(索引) ALTER TABLE 表名 ADD PRIMARY KEY(列名,..); 联合主键

删除索引

DROP INDEX index_name ON tbl_name;
alter table table_name drop index index_name;

删除主键(索引)比较特别: alter table t_b drop primary key;

查询索引(均可)

show index(es) from table_name;
show keys from table_name;
desc table_Name;

修改索引,我们一般是先删除在重新创建.

查询要使用索引最重要的条件是查询条件中需要使用索引。

下列几种情况下有可能使用到索引:
1,对于创建的多列索引,只要查询条件使用了最左边的列,索引一般就会被使用。
2,对于使用like的查询,查询如果是  ‘%aaa’ 不会使用到索引, ‘aaa%’
会使用到索引。

下列的表将不使用索引:
1,如果条件中有or,即使其中有条件带索引也不会使用。
2,对于多列索引,不是使用的第一部分,则不会使用索引。
3,like查询是以%开头
4,如果列类型是字符串,那一定要在条件中将数据使用引号引用起来。否则不使用索引。(添加时,字符串必须”)
5,如果mysql估计使用全表扫描要比使用索引快,则不使用索引。

测试案例(就在前面的dept表上做演示.)

CREATE TABLE dept(
deptno MEDIUMINT   UNSIGNED  NOT NULL  DEFAULT 0,
dname VARCHAR(20)  NOT NULL  DEFAULT "",
loc VARCHAR(13) NOT NULL DEFAULT ""
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;

–放入数据,前面应该已经添加了,如果没有则需要重新添加

–测试开始.

添加一个主键索引

alter table dept add primary key (deptno)

–测试语句

explain select * from dept where deptno=1;

结果是:

mysql> explain select * from dept where deptno=1;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: dept
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: const
         rows: 1
        Extra:
1 row in set (0.00 sec)

–创建多列索引

alter table dept add index myind (dname,loc);

–证明对于创建的多列索引,只要查询条件使用了最左边的列,索引一般就会被使用

explain select * from dept where dname=’研发部’;
会显示使用到了索引myind

explain select * from dept where loc=’MsBDpMRX’;
不会显示使用到了索引myind

–对于使用like的查询

explain select * from dept where dname like ‘%研发部’;
不会显示使用到了索引myind

explain select * from dept where dname like ‘研发部%’;
会显示使用到了索引myind

–如果条件中有or,即使其中有条件带索引也不会使用

–为了演示,我们把复合索引删除,然后只在dname上加入索引.

alter table dept drop index myind
alter table dept add index myind (dname)
explain select * from dept where dname='研发部' or loc='aa';-- 就不会使用到dname列上的

–如果列类型是字符串,那一定要在条件中将数据使用引号引用起来。否则不使用索引

select * from dept from dname=1234; //不会使用到索引

select * from dept from dname=’1234′; //会使用到索引

查看索引的使用情况
show status like ‘Handler_read%’;
大家可以注意:
handler_read_key:这个值越高越好,越高表示使用索引查询到的次数。

handler_read_rnd_next:这个值越高,说明查询低效。

*
这时我们会看到handler_read_rnd_next值很高,为什么,这是因为我们前面没有加索引的时候,做过多次查询的原因.

2.2 对优化,其实你只是一知半解

谈到性能优化,相信各位开发Android的老司机和新司机,都能说上几句。而在面试过程中性能优化也是必问的姿势。但人人都能说几句并不代表对性能优化的理解有多少,不信看几个问题:

  1. Android的内存管理在Dalvik和ART上有什么区别?通过adb获取内存信息时,哪个值是真正可回收的内存占用量?
  2. 如何计算资源图片所占的内存?
  3. 线程的优先级和进程有关吗?

相信不少司机肯定说不全,但这条估计要让崇尚“背诵记忆准则”的小伙伴们笑了:我不理解原理,但也能说出几条优化的规则,你安能说我不懂性能优化?诚然性能优化有很多经验、准则可以参考借鉴,但是性能优化却不应该是背诵记忆的机械动作。如果不理解原理,对性能优化的认识、理解不足,任何场景都拿统一的套路生搬硬套,那优化的深度、全面性、适用性一定会大打折扣。

常用SQL优化            

大批量插入数据(MySql管理员) 了解
对于MyISAM:

alter table table_name disable keys;
loading data//insert语句;
alter table table_name enable keys;

对于Innodb:
1,将要导入的数据按照主键排序
2,set unique_checks=0,关闭唯一性校验。
3,set autocommit=0,关闭自动提交。

优化group by 语句
默认情况,MySQL对所有的group by col1,col2进行排序。这与在查询中指定order
by col1, col2类似。如果查询中包括group
by但用户想要避免排序结果的消耗,则可以使用order by null禁止排序

有些情况下,可以使用连接来替代子查询。
因为使用join,MySQL不需要在内存中创建临时表。(讲解)

如果想要在含有or的查询语句中利用索引,则or之间的每个条件列都必须用到索引,如果没有索引,则应该考虑增加索引(与环境相关
讲解)

 select * from 表名 where 条件1=” or 条件2=’tt’

explaine select * from dept group by dname; =>这时显示 extra: using
filesort 说明会进行排序

explaine select * from dept group by dname order by null
=>这时不含有显示 extra: using filesort 说明不会进行排序

***有些情况下,可以使用连接来替代子查询。因为使用join,MySQL不需要在内存中创建临时表。

explain select * from emp , dept where emp.deptno=dept.deptno;

和下面比较就可以说明问题!!

explain select * from emp left join dept on emp.deptno=dept.deptno;

3、 所得

那么在这个并不轻松的性能优化过程中,我得到了什么?

选择合适的存储引擎           

MyISAM:默认的MySQL存储引擎。如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性要求不是很高。其优势是访问的速度快。

InnoDB:提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM,写的处理效率差一些并且会占用更多的磁盘空间。

Memory:数据存在内存中,服务重启时,数据丢失

MyISAM: 在插入数据时,默认放在最后.
,删除数据后,空间不回收.(不支持事务和外键)

InnoDB 支持事务和外键

对应我们程序员说,常用的存储引擎主要是 myisam / innodb / memory,heap 表

如果选用小原则:

1.如果追求速度,不在乎数据是否一直把保存,也不考虑事务,请选择 memory
比如存放用户在线状态.

2.如果表的数据要持久保存,应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性要求不是很高。选用MyISAM

3.如果需要数据持久保存,并提供了具有提交、回滚和崩溃恢复能力的事务安全,请选用Innodb

3.1 对产品业务的熟悉

性能优化看似是个纯技术的事情,但是实际上和业务密不可分,毕竟任何技术都是在具体的业务场景下实践应用。因此不熟悉模块业务、具体实现而生搬硬套的话,性能优化工作往往无从下手。

选择合适的数据类型           

在精度要求高的应用中,建议使用定点数来存储数值,以保证结果的准确性。deciaml
不要用float

对于存储引擎是MyISAM的数据库,如果经常做删除和修改记录的操作,要定时执行optimize
table table_name;功能对表进行碎片整理。

日期类型要根据实际需要选择能够满足应用的最小存储的早期类型

create table bbs(id int ,con varchar(1024) , pub_time int);

date(‘Ymd’,时间-3*24*60*60); 2038年-1-19

对于使用浮点数和定点数的案例说明

create table temp1( t1 float(10,2), t2 decimal(10,2));

insert into temp1 values(1000000.32,1000000,32); 发现 t1 成了 1000000.31
所以有问题.

对于optimize table 表名 演示

create table temp2( id int) engine=MyISAM;
insert into temp2 values(1); insert into temp2 values(2); insert into temp2 values(3);
insert into temp2 select * from temp2;--复制
delete from temp2 where id=1; 发现 该表对于的数据文件没有变小

定期执行 optimize table temp2 发现表大小变化,碎片整理完毕

&&对于InnoDB它的数据会存在data/ibdata1目录下,在data/数据库/只有一个
*.frm表结构文件.

接上一篇Mysql性能优化一 建立适当的索引
说起提高数据库性能,索引是最物美价廉的东西了。不用加内存,…

3.2 对性能优化的深入理解

性能优化不是一块孤立的知识,对性能优化的深入理解需要方方面面的技术为辅助,此处仍然以第一篇启动优化为例。

  • 应用启动分类及过程;
  • 启动优化方式;
  • Heavy app initialization(包含线程使用、网络请求、IO、布局嵌套等)。

尤其是第三点:每一项都有可能导致性能的瓶颈,而每一项都可以展开阐述,这个过程使你的技术能力得以强化。

3.3 知识整理和文档能力

大多数情况下,我们都不创造知识而只是知识的搬运工,一般做的就是对知识的搜集和整合。那对我们决胜就是快速的汲取知识以及完成对知识的判断及整合,知道什么地方会有权威、靠谱的资料,判断知识的使用场景等。

而写文章过程中的各种痛苦也不是无用功,经历过不知道怎么写文章的窘迫,才会知道怎么确定文章主题、主线、丰富文章,才会锻炼到自己的表达能力、文字组织能力。

4、 其它

4.1 为什么要重视性能优化?

  • 性能优化的学习与实践是技术人员成长进步的一条途径,同时也是改善代码质量的一次机会。
  • 伴随着App功能的增多,性能问题随之而来,不夸张的说任何App都有性能问题,只是程度不同。任由性能问题存在却视而不见最终一点会有集中式的爆发,那后果不仅仅是技术上的失责,更会影响产品及用户。
  • 性能优化的过程本身也是一个精益求精的过程,代表了你对代码的重视,对高质量应用的追求。

4.2 性能优化有哪些好的资料推荐?

  1. Android性能优化典范,官方推出,必属精品。不仅仅告诉你哪里有问题,更告诉你为什么!
  2. 胡凯的博客,翻译了关于Android性能优化典范的内容,不想看视频的话可以参考博客。不过官方的典范及翻译都是偏理论性,需要自己去实践。
  3. 官方文档,不管是Training模块还是API模块,都藏了很多干货。
  4. 《移动App性能评测与优化》,腾讯TMQ专项测试团队的大作,深入底层,追本溯源,精益求精,带给人技术上提升的同时更端正做技术的态度,强烈推荐!

4.3 对性能优化,平时怎么做?

四个字:防微杜渐。很多性能方面的问题都不是一朝一夕产生的,例如OOM,导致OOM发生的代码可能只是压死骆驼的最后一根稻草,前面很多地方已经埋下了隐患,只等最后一个地方点燃。还有很多代码本身并没有错,确实实现了功能,但是放错了位置。

模块开发之前最好对技术方案进行评审,从实现上(源头)尽早规避低性能的实现方式;最好在功能完成之后,使用工具进行性能的分析,进行针对性的优化。

4.4 其它

  • 优化完成之后务必充分测试,否则虽然性能是高了但是出现Bug也是不能接受的;
  • 推荐大家写博客,或者整理、总结也好;
  • 不忘初心,方得始终。

欢迎关注微信公众号:定期分享Java、Android干货!

图片 8

欢迎关注

相关文章