优化策略

本文要感谢我职级评定过程中的一位评委，他建议把之前所做的各种性能优化的案例和方案加以提炼、总结，以文档的形式沉淀下来，并在内部进行分享。力求达到如下效果： 1. 形成可实践、可借鉴、可参考的各种性能优化的方案以及选型考虑点，同时配合具体的真实案例，其他人遇到相似问题时，不用从零开始。 2. 有助于开阔视野，除了性能优化之外，也能提供通用的常见思路以及方案选型的考虑点，帮助大家培养在方案选型时的意识、思维以及做各种权衡的能力。 文章在内部分享后，引起强烈分享，得到了不少同事和朋友的认可和好评，觉得对日常的工作有很好的指导作用。考虑到这些经验可能对业界同行也有帮助，所以在美团点评技术团队博客公开。 代码 之所以把代码放到第一位，是因为这一点最容易引起技术人员的忽视。很多技术人员拿到一个性能优化的需求以后，言必称缓存、异步、JVM等。实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。有一些性能问题，完全是由于代码写的不合理，通过直接修改一下代码就能解决问题的，比如 for循环次数过多、作了很多无谓的条件判断、相同逻辑重复多次 等。 数据库 数据库的调优，总的来说分为以下三部分： SQL调优 这是 最常用、每一个技术人员都应该掌握基本的SQL调优手段（包括方法、工具、辅助系统等） 。这里以MySQL为例，最常见的方式是，由 自带的慢查询日志或者开源的慢查询系统

本文要感谢我职级评定过程中的一位评委，他建议把之前所做的各种性能优化的案例和方案加以提炼、总结，以文档的形式沉淀下来，并在内部进行分享。力求达到如下效果： 1. 形成可实践、可借鉴、可参考的各种性能优化的方案以及选型考虑点，同时配合具体的真实案例，其他人遇到相似问题时，不用从零开始。 2. 有助于开阔视野，除了性能优化之外，也能提供通用的常见思路以及方案选型的考虑点，帮助大家培养在方案选型时的意识、思维以及做各种权衡的能力。 文章在内部分享后，引起强烈分享，得到了不少同事和朋友的认可和好评，觉得对日常的工作有很好的指导作用。考虑到这些经验可能对业界同行也有帮助，所以在博客公开分享给大家。 常见性能优化策略分类 代码 之所以把代码放到第一位，是因为这一点最容易引起技术人员的忽视。很多技术人员拿到一个性能优化的需求以后，言必称缓存、异步、JVM等。实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。有一些性能问题，完全是由于代码写的不合理，通过直接修改一下代码就能解决问题的，比如for循环次数过多、作了很多无谓的条件判断、相同逻辑重复多次等。 数据库 数据库的调优，总的来说分为以下三部分： SQL调优 这是最常用、每一个技术人员都应该掌握基本的SQL调优手段（包括方法、工具、辅助系统等）。这里以MySQL为例，最常见的方式是

背景 如今前端工程化的概念早已经深入人心，选择一款合适的编译和资源管理工具已经成为了所有前端工程中的标配，而在诸多的构建工具中， webpack 以其丰富的功能和灵活的配置而深受业内吹捧，逐步取代了grunt和gulp成为大多数前端工程实践中的首选，React，Vue，Angular等诸多知名项目也都相继选用其作为官方构建工具，极受业内追捧。但是，随者工程开发的复杂程度和代码规模不断地增加，webpack暴露出来的各种性能问题也愈发明显，极大的影响着开发过程中的体验。 问题归纳 历经了多个web项目的实战检验，我们对webapck在构建中逐步暴露出来的性能问题归纳主要有如下几个方面： 代码全量构建速度过慢，即使是很小的改动，也要等待长时间才能查看到更新与编译后的结果（引入HMR热更新后有明显改进）； 随着项目业务的复杂度增加，工程模块的体积也会急剧增大，构建后的模块通常要以M为单位计算； 多个项目之间共用基础资源存在重复打包，基础库代码复用率不高； node的单进程实现在耗cpu计算型loader中表现不佳； 针对以上的问题，我们来看看怎样利用webpack现有的一些机制和第三方扩展插件来逐个击破。 慢在何处 作为工程师，我们一直鼓励要理性思考，用数据和事实说话，“我觉得很慢”，“太卡了”，“太大了”之类的表述难免显得太笼统和太抽象，那么我们不妨从如下几个方面来着手进行分析：

直接说内容： 监控报警策略实战 冗余设计理念实战 限流原理与实现 降级的策略与实现 回滚策略规范与实践 重试技术策略理解 峰值应对： 面对峰值到来时候， 应该准备的工作。 分为了事前，事中， 事后 三个阶段来进行介绍。 其中比较重点的 全链路压测 步骤包含哪些东西。 线上问题实战： 异常问题排查的实战经验。 包括： JVM(OOM, FULL GC, LOAD飙升等) 数据库(慢SQL， 数据扩展，同步) 网络(DNS解析异常， 链接异常，超时异常) 性能优化(优化方向， 优化技术， 优化实践) 具体的细节， 大家可以搜索51CTO视频学院频道， 有详细的课程讲解。 转载于:https://blog.51cto.com/14123565/2337077 来源： https://www.cnblogs.com/ceshi2016/p/11679510.html

1、hive抓取策略 hive.fetch.task.conversion = more/none more不走mr，none走mr 2、explain 显示执行计划 3、设置本地运行模式 set hive.exec.mode.local.auto = true hive.exec.mode.local.inputbytes.max 默认128M，表示加载文件的最大值，若大于该配置仍会以集群方式运行 4、并行计算 Set hive.exec.parallel = true/falses Set hive.exec.parallel.thread.number 默认8个 5、严格模式 set hive.mapred.mode = strict/nonstrict 限制查询： 对于分区表，必须添加where对于分区字段的过滤条件 order by语句必须包含limit输出限制 限制执行笛卡尔积的查询 6、hive排序 order by：对于查询结果做全排序，只允许一个reduce处理（当数据量较大时，慎用。严格模式下，必须结合limit来使用） sort by：对于单个reduce的数据进行排序 distribute by：分区排序，经常和sort by结合使用 cluster by：相当于sort by+distribute by 　　cluster by不能通过asc

mysql添加索引 1、主键索引 LATER TABLE 'table_neme' ADD PRIMARY KEY('column'); 2、唯一索引 unique空串（null）可以放多个 如果是具体的内容则不能重复 a: 肯定在where条经常使用 ； b: 该字段的内容不是唯一的几个值(sex)； （只有三个数据形成2级二叉树） c: 字段内容不是频繁变化. ALTER TABLE 'table_name' ADD UNIQUE ('column'); 3、普通索引 ALTER TABLE 'table_name' ADD INDEX ('column'); 4、全文索引（主要是针对对文件，文本的检索, 比如文章, 全文索引针对MyISAM有用） ALTER TABLE 'table_name' ADD FULLTEXT ('column'); 5、多列索引 ALTER TABLE 'table_name' ADD INDEX index_name('column1','column2','column3'); 更详细的添加索引的方法 mysql中可以使用alter table这个sql语句来为表中的字段添加索引。 ALTER TABLE <表名> ADD INDEX <字段>; ag:我们来尝试为test中t_name字段添加一个索引 alter table test

magento的网站实在是太慢了，想了好多办法，参考了好多资料，做了很多测试，总结一下大概的步骤如下 （继续） ： １、压缩js,css代码，如果有必要把所有的css,js分别综合到一个文件中，并压缩，缓存 ２、清除magento模板中不必要的注释，为所使用到的图片瘦身 ３、 优化magento代码，这个步骤工作量大，但可能是效果显著的步骤，不过前提是你非常熟悉magento，彻底删除不用的模块，关闭没用的block， 清除无效，无用的xml（解析xml非常昂贵的），在一个页面中尽量不要大量调用magento的image resize功能，非常消耗内存，除非你自己优化代码。 ４、mysql配置优化，充分发挥你的硬件资源，下面的数值要根据你的配置调整 key_buffer_size = 512M max_allowed_packet = 64M table_cache = 512 sort_buffer_size = 4M net_buffer_length = 8K read_buffer_size = 4M read_rnd_buffer_size = 2M myisam_sort_buffer_size = 64M tmp_table_size = 128M query_cache_size = 96M query_cache_type = 1 thread_cache

针对类似于广晟有色这样的股票，在横盘期间制定的策略，通过反复的波段，降低成本，效果还是很显著的，能够从32的成本降到23，仓位基本没有太大变化。上图中基准收益选择的就是广晟有色本身，二者收益率的差值，表现出来就是成本的降低。 原始策略，将每个0.5元划分为一个区间，股价达到某个区间后，通过对应数组进行判断和分析，操作。前面帖子有代码。今天对区间和对冲获利的距离进行了测试，区间从0.5调到0.1，获利距离从1到4，这是结果： 结论：因为设定的操作点，是由成交量、价格、仓位等诸多因素决定的，此时价格相对固定，在这块优化，并不能改变或者选择更好的价位，所以优化效果有限。 来源： https://www.cnblogs.com/jetz/p/11389715.html

关系数据库的查询优化策略二(转) 3 书写高效的 SQL 语句 虽然特定的数据库服务器都会对输入的查询语句进行一定的优化操作，但是查询效率主要取决于 DBA 所书写的 SQL 语句的好坏。为确保编写的 SQL 语句有较好的性能，应考虑以下的优化方法： ⑴ 尽量减少使用负逻辑的操作符和函数，因为它们会导致全表扫描，而且容易出错。可以把含有 NOT 、 <> 、！ = 等负逻辑的条件表达式转化为意思相当的正逻辑。 ⑵ 字段提取要多少，取多少，避免使用“ select * ”格式，因为在数据量较大的时候，影响查询性能的最大因素不在与数据的查找，而在于物理 I/O 的操作。 ⑶ 避免使用 LIKE 、 EXISTS 、 IN 等标准表达式，他们会使字段上的索引无效，引起全表扫描。尽量减少表的联接操作，不可避免的时候要适当增加一些冗余条件，使参与联接的字段集尽量少。 ⑷ OR 会使字段上的索引失效，引起全表扫描。下面的例子中，可以把 or 子句分开，在把结果做加法和算，也可以编写一个存储过程来避免索引的失效。 Select work-name, work-dept from work where work-id=’2’ or work-id=’3’; ⑸ 尽量减少使用联接字段而把所有的条件分列出来用 and 来进行连接，可以充分的利用在某些字段上已经存在的索引。 select work-id

关系数据库的查询优化策略一(转) 1 引言 随着计算机应用技术的不断普及和发展，数据库系统正越来越多的走进人们的日常生活。在要求查询结果正确无误的同时，人们越来越关心查询的效率问题。影响查询效率的因素很多，诸如处理器的速度、 I/O 速度、存储器的容量、操作系统、采取何种的数据库服务系统等。但是对于特定服务器来说查询的效率主要取决于 DBA （数据库管理员）所给定的查询语句。 2 合理使用索引 数据库服务器对数据进行访问一般采用下面的两种方式： ① 索引扫描，通过索引访问数据； ② 表扫描，读表中的所有页。当对一个表进行查询时，如果返回的行数占全表总行数的 10% 到 15% 时，使用索引可以极大的优化查询的性能。但是如果查询涉及到全表 40% 以上的行时，表扫描的效率比使用索引扫描的效率高。在具体使用的过程中，要结合实际的数据库和用户的需求来确定要不要索引以及在什么字段上建立什么样的索引。下面给出一些通用的规则： 1. 在经常用作过滤器或者查询频率较高字段上建立索引； 2. 在 SQL 语句中经常进行 GROUP BY 、 ORDER BY 的字段上建 立索引； 3. 在不同值较少的字段上不必要建立索引，如性别字段； 4. 对于经常存取的列避免建立索引； 5. 用于联接的列（主健 / 外健）建立索引； 6. 在经常存取的多个列上建立复合索引