性能优化

SQL语句优化-explain分析问题 Explanin select * from user 会产生如下信息： id:查询的序列号 select_type:表示查询的类型。 table:输出结果集的表 type:表示表的连接类型 possible_keys:表示查询时，可能使用的索引 key:表示实际使用的索引 key_len:索引字段的长度 ref: 哪个字段或常数与 key 一起被使用 rows:扫描出的行数 Extra:执行情况的描述和说明 select_type列说明 SIMPLE, 表示此查询不包含 UNION 查询或子查询 PRIMARY, 表示此查询是最外层的查询 UNION, 表示此查询是 UNION 的第二或随后的查询 DEPENDENT UNION, UNION 中的第二个或后面的查询语句, 取决于外面的查询 UNION RESULT, UNION 的结果 SUBQUERY, 子查询中的第一个 SELECT DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果. type列说明 通常来说, 不同的 type 类型的性能关系如下: ALL < index < range ~ index_merge < ref < eq_ref < const < system MySQL性能优化之慢查询 介绍

本文将简单介绍一下我所收集到的React Native应用优化方法，希望对你有所启发。很多方法也是适用React web应用的。 包体积优化 无论是热更新方案走网络下载js，还是直接将js打进apk,减小js bundle体积都很必要。 走网络的js体积大影响首次加载速度，打进apk的增加包体积。 压缩 为了测试，直接使用 react-native init 命令生成了一个rn工程，将其中的App.js改为下面这样简单的代码，验证这样简单的代码打包生成的js bundle体积情况。 import React from 'react'; import { Text, } from 'react-native'; const App: () => React$Node = () => { return ( <Text>1</Text> ) }; export default App; 使用 下边的命令可以打包js bundle # 非压缩 react-native bundle --entry-file ./index.js --bundle-output ./testBundle.js --dev true # 压缩 react-native bundle --entry-file ./index.js --bundle-output ./testBundle_min.js -

昨天参加37互娱的笔试时有个这样的问题： 说说你所知道的提高前端开发效率的工具或方法？ 说实话，确实知道的不多，于是从网上搜了下，挺不错，故转载之： http://www.jianshu.com/p/cdf777f13ff6 内容分发网络（CDN） CDN 可以帮你把网站的资源分发到世界各地，有助于提高网站的响应速度，当然，这对于那些特殊地区的用户是收效甚微的。 CloudFlare CloudFlare 的强大之处在于它可以成为你的 DNS 服务器（CDN 只是它所有服务的一个组成部分），这样对你的网站发起的所有请求都会经过它。 CloudFlare 的 CDN 在过去十五年的设计和发展中，并没有一味的守旧和固步自封。我们的专利技术中充分利用了最新的技术进步，包括并不限于硬件、web 服务器和网络路由。换言之，我们创新的建设了下一代的 CDN。新的 CDN 配置简单、价格低廉，其性能也一定比你使用过的任何传统 CDN 都要优秀。 MaxCDN CSS-Tricks 当前就在使用 MaxCDN 托管所有的静态资源。它可以无缝地融合 WordPres 和 W3 的所有缓存资源，所以我们无需做什么特别处理，即可将资源移入 CDN，并能保证链接的准确性。 对于一个博客来说，考虑到其中的大文件主要是 JavaScript、CSS 和图片，而不是视频等类型，这带宽占用的可真多。 我们的

本文提到的网站性能指网站的响应速度，这也符合绝大部分人对于网站性能的理解：访问快速的网站性能好，反之，访问速度越慢，则网站性能越差。本文总结的优化方法是宏观的工程层面的方法，并不包含微观的语言语法层面的方法，例如，JS、CSS的语法优化，这一部分同样影响网站的性能，但语言语法层面的优化更多的是取决于开发人员的编程水平。 什么样的网站响应速度快呢？其实很容易想到，网站加载资源的速度越快，网站响应速度越快；网站需要加载的资源越少，网站响应速度越快。这就分别对应网站性能优化的两大方向：资源缓存、资源合并压缩。当浏览器完成资源的加载后，需要进一步解析资源，才能渲染出最终的网页，所以，浏览器的解析机制也是网站性能优化的一个方向。各种优化方法都可以归类到这三个大方向中。 1.资源缓存 1.1 使用CDN 将网站的静态资源分离，如静态HTML、图片Image、样式CSS、脚本JS等，把静态资源部署到CDN中，可以明显加快这部分资源的加载速度。 1.2 利用HTTP缓存机制 HTTP缓存会把浏览器加载过的资源缓存到本地，下次加载时，只要缓存的资源没有过期，就可以直接使用本地的资源，减少了HTTP请求次数，加快了资源加载速度。具体做法是设置HTTP Header 中的Cache-Control参数。HTTP 1.0 中使用Pragma和Expires两个参数进行缓存，不过早已不推荐使用。 2.

大家一直都说Drupal的性能不怎么样，跑起来慢，即使不是在用户量大的时候，最近公司的蜜蜂培训产品在一个客户的使用过程中，由于用户量及数据量的激增，就遇到了比较大的性能问题，这篇文章就记录了整个优化过程，最终将性能调整到了正常水平。 蜜蜂培训系统由于是包含报名、签到、投票、评估、考试等场景，而这些场景往往都是有时间点的限制，这就造成较大的用户并发量。刚开始遇到性能问题的时候，大家的第一感觉肯定都是硬件水平跟不上，随后我们对服务器进行了扩容，但发现收效甚微，随着用户不断增加系统也越来越慢，于是我们开始着手优化系统。 首先我们从数据库开始，开启了mysql 慢查询日志，来看看有没有哪些逻辑的数据库查询有问题，这一看真吓一跳，有一个关键逻辑的sql居然最长要执行68秒！ 找到了问题所在，那么赶紧着手优化吧，来看看到底这个sql的执行时间到底耗费在了哪里，这里我们用 mysql 的 explain 命令来分析一下这个sql的执行计划， drush sql-cli 进入mysql命令行，敲入 explain + sql 就会打印出这个sql 的执行计划： 参考 explain 命令的说明，可以看到上图signup表是问题所在，这里没用到索引，使用了全表扫描和关联操作，经过对sql 和场景的分析，我们对sql中的这几个关键表对应的添加了新的索引： function wl_signup

为了面对博客园越来越大的访问量的挑战，这几天我专心于博客园网站的性能优化。 前天试验了用空间换时间的生成静态html文件的方法，感觉整体性能提高不是很明显，而且增加了程序的复杂度，并带来了一些新问题。 昨天，我又回到了对网站程序本身的优化。性能优化的目标是减少内存消耗。博客园的程序与数据库运行在同一台在服务器上，内存只有2G。节省内存是提高性能的重要因素。内存的两个大用户当然是Web应用程序与数据库， 所以性能优化从两方面着手，一是减少Web应用程序的内存占用，二是减少数据库查询，从面减少数据库占用的内存。昨天优化时，我发现了数据库中一张表的索引有问题。在代码中，发现了一处地方应该使用缓存减少数据库查询，却没有使用。我纠正了这两个问题。 同时，我也对machine.config的设置进行了调整，调整时参考了： 1、 Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications 2、 IIS 6.0 Tuning for Performance 需要修改的参数如下： Configuration setting Default value (.NET Framework 1.1) Recommended value

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作为一个前端开发， 我觉得很有必要了解浏览器对css选择器的解析，因为这个关系到页面的渲染，高效的方式、避开开销大的方式这些无疑为网站加载缩短了时间。 最近在新的项目中陷入了一个误区，也是出于对jquery使用的了解，于是把jquery中选择器的优化放到了写css上面，但是发现其实这两者是不一样的，浏览器解析css是本身默认的规则，而jquery是模拟出来的规则为了用户更好的使用。后面去查找这方面的资料，于是发现自己的错误是那么的可笑。 找到了阿里前端的一篇文章 http://www.aliued.cn/2013/01/24/ 网站css选择器性能讨论.html ，当然也找了其他的一些文章，不过都有说到了safari和webkit的架构师David Hyatt的两段话： 样式系统从最右边的选择符开始向左进行匹配规则。只要当前选择符的左边还有其他选择符，样式系统就会继续向左移动，直到找到和规则匹配的元素，或者因为不匹配而退出。 如果你非常在意页面的性能那千万别使用CSS3选择器。实际上，在所有浏览器中，用 class 和 id 来渲染，比那些使用同胞，后代选择器，子选择器（sibling, descendant and child selectors）对页面性能的改善更值得关注。 因为我项目的原因

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 使用最佳选择器 通常比较常用的选择器有以下几个： 1.ID选择器 $("#id") 2.标签选择器 $("td") 3.类选择器 $(".target") 4.属性选择器 $("td[target='target']") 5.伪类选择器 $("td:hidden") 结论 1.原生方法是最快的方法，如果可能，尽量选择用原生 2.性能顺序：ID选择器 > 标签选择器 > 类选择器 > 属性选择器 > 伪类选择器 3.ID(getElementById)、标签选择器(getElementsByTagName)都有原生的方法对应，所以很快；类选择器在除了IE5-IE8之外的主流浏览器几乎都有原生方法(getElementsByClassName)， 为了兼顾IE6、7、8的性能，避免使用全局的类选择器； 4.属性和伪类选择器非常慢，如非必要，尽量少使用伪类选择器和属性选择器 最佳实践 1.为模块中操作最频繁的元素和根元素设置id，然后缓存； 2.对没有id的元素检索，尽量采用路径最短的祖先元素id作为默认的搜索范围，并采用纯类选择器或者标签选择器； 3.尽量避免复杂的选择器 避免执行全局查找 $("div.bizHelp"); => $("#container").find(".bizHelp");

欢迎访问我的个人博客:www.ifueen.com MySql性能优化策略 文章目录 MySql性能优化策略 关系型数据库的优化方案 定位慢查询 找出执行效率慢的SQL(定位慢SQL) 开启慢查询记录日志 分析Sql语句 单机优化 通过表结构设计 数据库设计三范式 存储引擎 Innodb和MyISAM的区别 索引 索引分类 复合索引使用事项： 分表 垂直分表 水平分表 SQL语句优化 DDL优化 DML优化 DQL优化 关系型数据库的优化方案 关于MySQL的优化，大体方案可以分为以下步骤 找出执行效率低的Sql 分析慢的Sql 进行优化 定位慢查询 找出执行效率慢的SQL(定位慢SQL) 首先要明白原理，实际上我们在数据库上面所做的操作都会被日志记录下来，我们在定位慢查询就需要去通过日志记录来找到到底是哪条SQL效率慢 查询数据库状态的命令 运行了多久 show status like 'uptime' ; CRUD的执行次数 show status like '%Com_select%' show status like '%Com_insert%' show status like '%Com_update%' show status like '%Com_delete%' 查询所有的连接数 show status like 'connections' 查询慢查询次数 (

1、索引 简单的说，索引就像书本的目录，目录可以快速找到所在页数，数据库中索引可以帮助快速找到数据，而不用全表扫描，合适的索引可以大大提高数据库查询的效率。 (1). 优点 大大加快了数据库检索的速度，包括对单表查询、连表查询、分组查询、排序查询。经常是一到两个数量级的性能提升，且随着数据数量级增长。 (2). 缺点 索引的创建和维护存在消耗，索引会占用物理空间，且随着数据量的增加而增加。 在对数据库进行增删改时需要维护索引，所以会对增删改的性能存在影响。 a. 直接创建索引和间接创建索引 直接创建: 使用sql语句创建，Android中可以在SQLiteOpenHelper的onCreate或是onUpgrade中直接excuSql创建语句，语句如 CREATE INDEX mycolumn_index ON mytable ( myclumn ) 间接创建: 定义主键约束或者唯一性键约束，可以间接创建索引，主键默认为唯一索引。 b. 普通索引和唯一性索引 普通索引： CREATE INDEX mycolumn_index ON mytable ( myclumn ) 唯一性索引：保证在索引列中的全部数据是唯一的，对聚簇索引和非聚簇索引都可以使用，语句为 CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable (