性能优化

SQLSERVER SQL 性能优化系列　　 　　 1. 选择最有效率的表名顺序 ( 只在基于规则的优化器中有效 ) 　　 　　 SQLSERVER 的解析器按照从右到左的顺序处理 FROM 子句中的表名，因此 FROM 子句中写在最后的表（基础表 driving table ）将被最先处理，在 FROM 子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表，当 SQLSERVER 处理多个表时，会运用排序及合并的方式连接它们， 　　 首先，扫描第一个表（ FROM 子句中最后的那个表 ) 并对记录进行排序；然后扫描第二个表（ FROM 子句中最后第二个表 ) ；最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并 　　 例如 : 表 TAB1 16,384 条记录表 TAB2 5 条记录，选择 TAB2 作为基础表 ( 最好的方法 ) select count(*) from tab1,tab2 执行时间 0.96 秒，选择 TAB2 作为基础表 ( 不佳的方法 ) select count(*) from tab2,tab1 执行时间 26.09 秒； 如果有 3 个以上的表连接查询，那就需要选择交叉表（ intersection table ）作为基础表，交叉表是指那个被其他表所引用的表　　 　　 例如 : 　　 EMP 表描述了 LOCATION 表和

今天听组内SQL小王子分享了一篇Hive Sql性能优化的总结报告，甚觉精彩，赶紧来分享给大家！！ 一、尽量使用索引，避免全表查询 ① 在where 和 order by 常用的字段上 创建索引 ，提升效率的核心！但是用不到的字段就别加索引了，反而浪费存储空间；频繁更新的字段也不适合创建索引 ② where子句中尽量避免进行 nul值判断，少使用!=,<>等操作符，等号左边避免函数、算数和其它表达式运算 ，这此操作都会导致索引无效，启动全表查询 ③ where 子句中将 in，not替换成exists和not exists ，将会避免掉全表查询，同时如果是数值用Between替代in也是很好的选择 ④ where 子句中尽量少用or，如果一定要多条件并集查询，可以使用 Union All替代OR ⑤ where子句中 LIKE 字符第1个不要是%，这样会启动全表查询 二、多表关联小技巧 ① 避免笛卡尔积出现 ，如果多表关联，在符合业务需求情况下，能去重就都去重，比如登录表和充值表就是多条记录表，如果要关联获得登录用户的累计充值金额，则可以将登录表先去重，充值表汇总，再关联 ② 多表关联 小表在前，大表在后 ，hive会默认第1个表纳入内存，然后再对大表进行关联计算，小表放前将会大大提升效率 ③ 尽量早过滤 ，减少每个阶段的数据量，过滤条件执行顺序：关联表中的WHERE>ON

引言： 　　 　　以前在面试的过程中，总有面试官问道：你做过sql性能优化吗？对此，我的答复是没有。一次没有不是自己的错误，两次也不是，但如果是多次呢？今天痛下决心，把有关sql性能优化的相关知识总结一下，以便在不久的将来，我的回答不是“没有”，总能多多少少说一些东西。算是长进吧。说到性能优化，本人感觉到有必要先了解sql语句的执行顺序，因为对优化或多或少的会有些帮助。 sql语句执行顺序： 　　 　　sql语句和其他相关的编程语言最大不同的地方应该是执行顺序。对于大多数编程语言来说都是按照顺序进行执行，但对于sql语句，尽管select是最开始出现，但几乎总是最后一个执行，最开始执行的往往是from子句。每一步骤产生一个虚拟表，这些虚拟表对于调用者来说是不能用的，仅仅作用于下一步骤，而只有最后的查询结果表才能被调用者所使用。当有步骤没有出现时便跳过该执行步骤。下面上代码： (8)SELECT (9)DISTINCT (11)<Top Num> <select list> (1)FROM [left_table] (3)<join_type> JOIN <right_table> (2) ON <join_condition> (4)WHERE <where_condition> (5)GROUP BY <group_by_list> (6)WITH <CUBE | RollUP>

选择最有效率的表名顺序 WHERE子句中的连接顺序 SELECT子句中避免使用‘*‘ 当你想在select子句中列出所有的column时，使用动态sql列引用‘‘是一个方便的方法，不幸的是，这是一个非常低效的方法。 实际上，oracle在解析的过程中，会将‘‘依次转换成所有的列名。这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间。 字符型字段必须加单引号 减少访问数据库的次数 ARRAYSIZE参数设置 使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表 你可以用decode函数高效地得到相同结果 ‘x‘表示任何一个字段。类似的，decode函数也可以运用于group by和order by子句中。 整合简单,无关联的数据库访问 如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系),相同语句书写，同一功能同一性能不同写法SQL的影响，如： 四个SQL在ORACLE分析整理后产生的结果及执行的时间是一样的，但从ORACLE共享内存的原理，可以看出ORACLE对每一个SQL进行了一次解析，并且独立的占用共享内存，如果将SQL完全相同的格式，ORACLE只解析一次，共享内存只保留一次分析结果，这样不仅可以减少解析SQL的时间，而且可以减少共享内存里的重复信息。 删除重复记录 用TRUNCATE替代DELETE 尽量多使用COMMIT

预加载方案的集成方式请参考上篇 小程序性能优化之预加载方案 集成篇 再次声明，这个预加载方案要求与服务器的通信时间，不能大于 350ms ，渲染时传入的 data 数据量也不能太大，若超过这个值或数据量过大，页面依旧会先空后有数据，也就是跳转后闪一下。如果超过了这个值，建议服务器优化数据处理速度，或者拆分协议，先请求一部分轻量级的数据，繁重的数据根据时机之后再请求。 还有，一定要记住，在真机上测试时，一定要关闭小程序的调试模式，否则，会极大的减慢渲染数据的速度！ 这个技术核心思想是 延迟跳转和预加载 。 延迟跳转是什么？通常情况下，一个按钮，你都要给他加点击反馈的，在小程序的 view 组件里是有这么两种属性。 hover-class ：指定按下去的样式类。当 hover-class=”none” 时，没有点击态效果，默认值是 none 。 hover-stay-time ：手指松开后点击态保留时间，单位毫秒。默认值是400ms。 一个按钮的点击态持续时间， 100ms 的体验是很好的（我自己是这么感觉的，哈哈）。 按钮点击态可以这样处理： 在 wx.navigateTo 上包裹一层 setTimeout ，延迟时间设置为150ms。 给 view 添加了 hover-class 和 hover-stay-time 这两个属性。 指定 hover-stay-time 的值为100

Android性能优化之布局优化 一、Android系统是如何处理UI组件的更新操作的 　　既然和布局相关，那么我们需要了解Android系统是如何处理UI组件的更新操作的。 　　1、Android需要把XML布局文件转换成GPU能够识别并绘制的对象。这个操作是在DisplayList的帮助下完成的。DisplayList持有所有将要交给GPU绘制到屏幕上的数据信息。 　　2、CPU负责把UI组件计算成Polygons，Texture纹理，然后交给GPU进行栅格化渲染。 　　3、GPU进行栅格化渲染。 　　4、硬件展示在屏幕上。 　　 那么什么是栅格化呢?Resterization栅格化是绘制那些Button，Shape，Path，String，Bitmap等组件最基础的操作，它把那些组件拆分到不同的像素上进行显示，如上图所示，手机的屏幕其实都是有一个一个小格子组成的图片，而当这些小格子非常非常小的时候，。这是一个很费时的操作，因此这也是为什么要引入GPU原因。 　　每次从CPU转移到GPU是一件很麻烦的事情，所幸的是OpenGL ES可以把那些需要渲染的文理Hold在GPU的Memory里面，在下次需要渲染的时候直接进行操作。 Android里面那些由主题所提供的资源，例如Bitmap，Drawables都是一起打包到统一的Texture文理当中， 然后再传递到GPU里面

首先，我们来看看Hadoop的计算框架特性，在此特性下会衍生哪些问题？ 数据量大不是问题，数据倾斜是个问题。 jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的。 sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使数据倾斜不成问题。 count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的。举个例子：比如男uv,女uv，像淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。 面对这些问题，我们能有哪些有效的优化手段呢？下面列出一些在工作有效可行的优化手段： 好的模型设计事半功倍。 解决数据倾斜问题。 减少job数。 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。 了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化

1.查询的模糊匹配 尽量避免在一个复杂查询里面使用 LIKE '%parm1%'―― 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用. 解决办法: 其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下： a、修改前台程序――把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。 b、直接修改后台――根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联 2.索引问题 在做性能跟踪分析过程中，经常发现有不少后台程序的性能问题是因为缺少合适索引造成的，有些表甚至一个索引都没有。这种情况往往都是因为在设计表时，没去定义索引，而开发初期，由于表记录很少，索引创建与否，可能对性能没啥影响，开发人员因此也未多加重视。然一旦程序发布到生产环境，随着时间的推移，表记录越来越多 这时缺少索引，对性能的影响便会越来越大了。 这个问题需要数据库设计人员和开发人员共同关注 法则：不要在建立的索引的数据列上进行下列操作: ◆避免对索引字段进行计算操作 ◆避免在索引字段上使用not，<>，!= ◆避免在索引列上使用IS NULL和IS NOT NULL ◆避免在索引列上出现数据类型转换 ◆避免在索引字段上使用函数

转载https://www.cnblogs.com/lys-iOS-study/p/7097774.html WebView 性能优化总结 一个加载网页的过程中， native 、网络、后端处理、 CPU 都会参与，各自都有必要的工作和依赖关系；让他们相互并行处理而不是相互阻塞才可以让网页加载更快： ・ WebView 初始化慢，可以在初始化同时先请求数据，让后端和网络不要闲着。 ・ 后端处理慢，可以让服务器分 trunk 输出，在后端计算的同时前端也加载网络静态资源。 ・ 脚本执行慢，就让脚本在最后运行，不阻塞页面解析。 ・ 同时，合理的预加载、预缓存可以让加载速度的瓶颈更小。 ・ WebView 初始化慢，就随时初始化好一个 WebView 待用。 ・ DNS 和链接慢，想办法复用客户端使用的域名和链接。 ・ 脚本执行慢，可以把框架代码拆分出来，在请求页面之前就执行好。 WebView 内存消耗 分析 为了测试 WebView 会消耗多少内存，我们设计了如下的测试方案： 1. 客户端启动后，记录消耗的内存。 2. 打开空页面，记录内存的上涨。 3. 退出。 4. 打开空页面，记录内存上涨。 5. 退出。 6. 打开加载了代码的页面，记录内存的额外增加。 得到如下测试结果： 测试系统： iOS 模拟器， Titans 10.0.7 测试系统： OPPO R829T Android

1、崩溃分析工具 VS，上手容易，图形界面化好，能分析启动耗时，CPU，内存等性能。 Windbg，功能十分强大，和VS一起分析，可以得到更多，但是各种命令比较多，不适合新手操作。死锁，崩溃，卡死，内存泄漏（umdh.exe工具），内存，CPU耗时，都不在话下。 IDA Pro 这个用的很少，不解释了。 2、 性能分析工具： Windows Performance Recorder 记录工具，可记录启动耗时，CPU，内存，硬盘，IO，帮助查找软件性能瓶颈，功能强大。 09-LockCop.exe 死锁分析工具，操作简单，功能强大，用windbg分析前可以先用这个工具查看一下是否有线程或进程死锁。 depends.exe 分析dll，exe文件的启动依赖关系，导出函数。 procdump.exe 抓取dump，可根据设置抓取进程的内存，CPU超过临界值的瞬间dump，可以用来抓取启动时占用CPU较高的dump，分析性能。 :: procdump -ma -c 50 -s 3 -n 2 5844(Process Name or PID) :: -ma 生成full dump, 即包括进程的所有内存. 默认的dump格式包括线程和句柄信息. :: -c 在CPU使用率到达这个阀值的时候, 生成dump文件. :: -s CPU阀值必须持续多少秒才抓取dump文件. :: -n