性能优化

简要总结： 1.资源压缩合并，减少http请求 2.非核心代码异步加载（异步加载方式，异步加载区别） 3.利用浏览器缓存（缓存的分类，缓存的原理） 4.使用CDN 5.与解析DNS 　　<mata http-equiv="x-dns-prefetch-control" content="on"> // https 协议下开启a链接的prefetch(http协议下会默认开启) 　　<link rel="dns-prefetch" href="//host_name_to_prefetch.com"> //========================================================================= content 方面 减少 HTTP 请求：合并文件、 CSS 精灵、 inline Image 减少 DNS 查询： DNS 缓存、将资源分布到恰当数量的主机名 减少 DOM 元素数量 Server 方面 使用 CDN 配置 ETag 对组件使用 Gzip 压缩 Cookie 方面 减小 cookie 大小 css 方面 将样式表放到页面顶部 不使用 CSS 表达式 使用 <link> 不使用 @import Javascript 方面 将脚本放到页面底部 将 javascript 和 css 从外部引入 压缩 javascript

sql性能优化、查询提速总结 这次sql性能优化，不讨论缓存服务器如redis等来增强，仅从表字段设置和业务操作角度考虑。 场景1: 表数据量大，比如几百上千万的流水数据表、跑批过程表查询。 1、根据业务做分库分表存储，降低表的数量级。比如按流水时间或者场景进行分表保存 2、增加常用查询表字段的索引 3、降低不必要查询字段查询，通过过滤不必要的字段查询，仅仅过去业务所需字段，当查询数量级上升一定层级，可以降低数据库服务器的计算压力和流量压力。 4、 场景二： 表连接频繁的表 提升性能办法： 1、有些常用表一直被连接起来进行统计，所以没理由不能先预暂存起来，在此基础上进行查询 2、当出现数据量大的表连接查询时候，可以考虑先从表中查询出临时表再做连接查询，这些避免大量笛卡尔积计算。因为工作就遇到一些报表sql设计，其中有许多表连接查询，因为设计不好导致查询效率长度几秒甚至更长。此时可以通过分析sql执行先后顺序，进行一定嵌套查询出子集再进行相应表连接查询，这样就极大的提升了查询效率。 场景三： 判断某些数据是否存在某些表中 1、判断表的数据量多少，然后根据设置查询的先后关系使用exits或in来查询所需的数据 场景四： 批量操作，如删除、更新 1、因为有事物的关系、数据量打的更新、删除操作会影响性能，出错回滚的代价很大。此时缩小批量操作来提高性能是可行的。 场景五： 少使用视图 1

ORACLE SQL性能优化系列 (一) 关键字 ORACEL SQL Performance tuning 1. 选用适合的ORACLE优化器 ORACLE的优化器共有3种: a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL 句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行analyze 命令,以增加数据库中的对象统计信息(object statistics)的准确性. 如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关. 如果table已经被analyze过, 优化 器模式将自动成为CBO , 反之,数据库将采用RULE形式的优化器. 在缺省情况下,ORACLE采用CHOOSE优化器, 为了避免那些不必要的全表扫描(full table scan) , 你必须尽量避免使用CHOOSE优化器,而直接采 用基于规则或者基于成本的优化器. 2. 访问Table的方式 ORACLE

sqlserver性能优化之索引的使用和优化 在应用系统中,尤其在联机事务处理系统中,对数据查询及处理速度已成为衡量应用系统成败的标准。而采用索引来加快数据处理速度也成为广大数据库用户所接受的优化方法。 在良好的数据库设计基础上，能有效地使用索引是SQL Server取得高性能的基础，SQL Server采用基于代价的优化模型，它对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部分开销是磁盘I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需读几次磁盘就可以了。所以如果建立了合理的索引，优化器就能利用索引加速数据的查询过程。但是，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。本文就SQL Server索引的性能问题进行了一些分析和实践。 一、聚簇索引(clustered indexes)的使用 　　聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面

1、尽量不要使用模糊查询（会导致相关列的索引不可用）； 2、有索引的列避免在sql语句中进行计算操作，尽量不使用not、<>、!=、is null、is not null，不进行数据类型转换、不使用函数、空值； 3、复杂的update和select语句适当拆分，多子句sql语句影响性能； 4、where子句中使用exist和not exist代替in和not in，having； 5、不要用字符格式来声明数字：where id = '100001'； 6、不使用select * from ... select count（*） from... ； 7、尽可能少的使用耗费数据库引擎的distinct、union、minus、intersect、order by... 来源： CSDN 作者： LeoGanlin 链接： https://blog.csdn.net/LeoGanlin/article/details/77992581

SQL性能优化该注意的几点 1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。 3.应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。 5.in 和 not in 也要慎用，否则会导致全表扫描，能用 between 就不要用 in。 6.Like查询 8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。 10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。 11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。 12.不要写一些没有意义的查询。 13.很多时候用 exists 代替 in 是一个好的选择。 14.大量数据重复时索引没有作用。 15.一个表的索引数最好不要超过6个，应尽可能的避免更新 索引数据列。 17.尽量使用数字型字段

1、性能指标监控 1）打开perfmon.exe性能监视器 2)添加性能指标  Memory: Available Mbytes  Memory: Pages/sec  Paging File:%Usage  SQL Server: Buffer Manager: Buffer cache hit  SQL Server: Buffer Manager: Page life expectancy  SQL Server: Memory Manager: Memory Grants Pending 3)数据分析 在本文中，再次使用了可靠性和性能监视器这个工具。为了获取内存相关的性能计数器，需要在图形化界面中观察这些计数器。 首先先检查Memory: Available Mbytes，这个值意味着系统的可用内存。如果发现这个值经常很低，可能表示服务器内存不足，在生产数据库中，这个值可以使用GB为单位。 然后检查Memory: Pages/sec ，以为这因为硬页面错误导致的从磁盘读或写页面。这个值如果长期高于20，意味着内存不足使得应用程序使用虚拟内存，从而导致挂起。 接着是Memory: pages/sec ，同时也要检查Paging File:%Usage去预估内存挂起。如果这个值经常超过20%，可能意味着内存不足。 SQL Server: Buffer Manager

sql server 性能优化方法 目录 一、查看是否有死锁 二、查看当前正在执行的sql语句 三、查询前 10 个可能是性能最差的 SQL 语句 四、查询逻辑读取最高的sql 五、 查询索引碎片 六、修改索引填充因子（FILLFACTOR：填充因子,ONLINE:ON 重建索引时表仍然可以正常使用） 七、查询未使用过的索引 八、查询表下索引使用情况 九、查询表结构信息 一、查看是否有死锁 dECLARE @tab TABLE(NAME varchar(100),value varchar(200)); INSERT INTO @tab EXEC('DBCC OPENTRAN WITH TABLERESULTS'); SELECT name,CAST(value AS DATETIME) startDate,getdate() currentDate ,DATEDIFF(s,CAST(value AS DATETIME),getdate()) diffsecond FROM @tab WHERE name in ('OLDACT_STARTTIME') SELECT spid, blocked, DB_NAME(sp.dbid) AS DBName, program_name, waitresource, lastwaittype, sp.loginame, sp.hostname

性能优化之SQL语句改写 有这样一条SQL，在系统性能视图中显示执行时间30秒，单独拿出来执行时间6秒 SELECT * FROM TABLEA WHERE COND1 AND (A.FIELD2<>6 AND A.FIELD1 NOT IN (SELECT REPLACE(FIELD1,'Y','') FROM TABLEB WHERE ...) OR A.FIELD2=6 AND A.FIELD1 NOT IN (SELECT FIELD1 FROM TABLEB WHERE ...) ) ORDER BY 1 优化步骤 首先把COND1之前的语句拿出来执行约0秒 其次分别执行每个单独的子查询（NOT IN中的子查询）语句也是0秒 再次把OR的语句分别执行，发现执行速度均是0秒 分析问题可能出现在两个子查询的合并上，干脆直接把SQL语句改写成两个独立的语句再进行UNION试试看，如下格式 SELECT * FROM ( SELECT * FROM TABLEA WHERE COND1 AND A.FIELD2<>6 AND A.FIELD1 NOT IN (SELECT REPLACE(FIELD1,'Y','') FROM TABLEB WHERE ...) UNION SELECT * FROM TABLEA WHERE COND1 AND A.FIELD2=6 AND A

一，SQL语句性能优化 1， 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2，应尽量避免在 where 子句中对字段进行 null 值判断，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默 认值。 3，应尽量避免在 where 子句中使用!=或<>操作符， MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。 4，应尽量避免在 where 子句中使用 or 来连接条件， 否则将导致引擎放弃使用索引而进行全表扫描， 可以 使用UNION合并查询： select id from t where num=10 union all select id from t where num=20 5，in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了：Select id from t where num between 1 and 3 6，下面的查询也将导致全表扫描：select id from t where name like ‘%abc%’ 或者select id from t where name like ‘%abc’若要提高效率，可以考虑全文检索