MySQL5.1性能优化方案
MySQL5.1性能优化方案
1.平台数据库
1.1.操作系统
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
32位Linux服务器，单独作为MySQL服务器使用。
1.2.M ySQL
系统使用的是MySQL5.1，最新的MySQL5.5较之老版本有了大幅改进。主要体现在以下几个方面：
1）默认存储引擎更改为InnoDB
InnoDB作为成熟、高效的事务引擎，目前已经广泛使用，但MySQL5.1之前的版本默认引擎均为MyISAM，此次MySQL5.5终于将默认数据库存储引擎改为InnoDB，并且引进了Innodb plugin 1.0.7。此次更新对数据库的好处是显而易见的：InnoDB的数据恢复时间从过去的一个甚至几个小时，缩短到几分钟(InnoDB plugin 1.0.7，InnoDB plugin 1.1，恢复时采用红-黑树)。InnoDB Plugin 支持数据压缩存储，节约存储，提高内存命中率，并且支持adaptive flush checkpoint, 可以在某些场合避免数据库出现突发性能瓶颈。
Multi Rollback Segments：原来InnoDB只有一个Segment，同时只支持1023的并发。现已扩充到128个Segments，从而解决了高并发的限制。
2）多核性能提升
Metadata Locking (MDL) Framework替换LOCK_open mutex (lock)，使得MySQL5.1及过去版本在多核心处理器上的性能瓶颈得到解决。
3）制功能(Replication)加强
过去的异步复制方式意味着极端情况下的数据风险，MySQL5.5将首次支持半同步(semi-sync replication)在MySQL的高可用方案中将产生更多更加可靠的方案。
4）增强表分区功能
MySQL 5.5的分区更易于使用的增强功能，以及TRUNCATE PARTITION命令都可以为管理和维护数据库节省大量的时间，并且具有更加灵活高效的分区方式。
1.3.C PU
系统所用CPU是单个4核CPU。对于CPU密集的负载，MySQL通常从更快的CPU中获益，而不是更多CPU。MySQL5.1的架构对多CPU的扩展性不好，并且MySQL不能在多个CPU上并行地运行某个查询，因此在对于单个CPU进行密集的查询时，CPU速度限制了响应时间。为了实现低延迟，即快速响应时间，需要快速的CPU，因为单个查询只能使用一个CPU。值得注意的是，MySQL5.5在多核心处理器上的性能有了很大的提升。另外，MySQL在64位架构上工作得更好，比32位架构更能有效地使用大量内存。
尽管本系统使用的是32位操作系统，CPU运行在32位模式下，但它仍支持64位计算。（cat /proc/cpuinfo | grep flags | grep ' lm ' | wc -l）
1.4.磁盘空间
系统的磁盘空间目前没有压力。
1.5.内存
内存总大小为4G，只供操作系统和数据库使用。
1.6.数据库的表和文件
数据库addb共有339张表：其中InnoDB表303张，MyISAM表34张，MEMORY表2张。
InnoDB数据文件ibdata1大小为30138MB，一周后ibdata1大小为30234MB，
MyISAM数据文件（包括表结构、索引及数据）总大小约为1642MB，一周后约为1639MB。可以看出，数据库的数据量较稳定，InnoDB数据文件增加了约106MB，总大小一周内没有大的变化。MyISAM表中，值得注意的是表terminalalarm_bak，该表总大小约为1623MB，占整个MyISAM 表总大小比重近99%。
二进制日志单个文件大小为1GB，二进制日志文件总大小接近20GB。
1.7.数据分布情况
服务器某时间点非精确值：
1< rows<1万136张（MyISAM表9张，MEMORY表2张）
rows=0（无数据）140张
观察系统中数据量很大且未进行表分区的InnoDB表
adrotateresultdetail_fail的数据量达到4千万，createTime列是datatime类型，且有索引，意味着存在以该列为查询条件或关联条件查询的需求，因此可以在该列上以自然月份进行表分区。
terminalalarm的数据量也突破千万，AlarmTime列是datatime类型，且有索引，意味着存在以该列为查询条件或关联条件查询的需求，因此可以在该列上以自然月份进行表分区。在事件ev_terminalalarm中会查询该表，若进行表分区，也能一定程度上提高事件的执行效率。
terminalalarminfo表仅自增列有索引，主要用于存储数据，可不用分区。
Terminallogin表的loginTime列是datatime类型，且有索引，意味着存在以该列为查询条件或关联条件查询的需求，因此可以在该列上以自然月份进行表分区。
adplayinfo_bak表存在多个以INT类型为索引的列，根据实际业务情况选择查询频率高且能以范围值来分区的整型列对该表进行分区。
adrotateresultdetail的createTime列是datatime类型，且有索引，意味着存在以该列为查询条件或关联条件查询的需求，因此可以在该列上以自然月份进行表分区。
upfile_bak表仅自增列有索引，若存在查询或者统计业务则可以createTime列进行分区，若该表没有查询方面业务可不必进行分区。
除去配置参数等属性表，对于数据量大且不断递增的业务数据表，最直接的办法可以按照时间字段进行分区，或是根据查询业务来选择合适的列进行表分区和创建索引，这样能够有效提高存储和查询效率。
1.8.服务器配置参数
记录查询：普通日志log、慢速日志log_slow_queries
MySQL有两种查询日志：普通日志和慢速日志，它们都会记录查询。普通日志记录了服务器接收到的每一个查询，也包含了没有被执行的查询，比如因为错误而未被执行的查询，还有一些非查询事件，比如连接和断开连接，普通日志不包含执行时间或其他只有在查询结束之后才能得到的信息。相反，慢速日志只包含了已经执行过的查询，如果是启动状态，它记录了执行时间超过了特定长度的查询。两种日志都有助于分析，但是慢速日志更有利找到性能较慢的查询。
一个相关配置是log_queries_not_using_indexes，它使服务器把没有使用索引的查询记录到慢速查询日志中，无论它们执行速度有多快。尽管打开慢速日志相对于执行慢速查询来说，通常只增加了很少的时间，但是如果没有使用索引的查询非常快，例如从小数据量表中查询，这样就会记录它们可能导致服务器变慢，甚至还会使用大量的磁盘空间，慢速日志也许就会被那些快速高效的查询塞满。
慢查询日志可以用来找到执行时间长的查询，可以用于优化。慢日志打开后，通过设置long_query_time来配置记录查询超过的指定时间，默认值为10秒，根据系统的负载和性能要求进行设置(SET GLOBAL long_query_time = …)。
检查又长又慢的查询日志会很麻烦，可以使用MySQLdumpslow命令获得日志中显示的查询摘要来处理慢查询日志。系统两种日志都没有开启，可以在需要的时候打开慢速日志来帮助分析性能较慢的查询。具体实施参考MySQL手册。
需要注意的是查询在日志中只出现一次并不意味着它是一个不好的查询，也不意味将来也会慢，查询时快是慢有多种原因：
1）表也许被锁定，导致查询处于等待状态；
2）数据或索引也许没有被缓存在内存中；
3）或者正在进行批处理大量的数据，使得磁盘I/O变慢；
4）服务器可能同时在运行其他的查询，影响了当前查询的效率。
因此，只能把慢速查询日志看成调优工作的一部分，可以用它来找到可疑的查询，但需要对它们进行仔细地排查和分析。
启用系统慢速日志，分析查询性能慢的时候可以观察该日志信息。
Qcache_hits
Com_select
Qcache_inserts
检查是否从查询缓存中受益的最直接办法就是检查缓存命中率。它是提供缓存提供的查询结果的数量，而不是服务器执行的数量。当服务器收到select语句的时候，Qcache_hits和Com_select这两个变量会根据查询缓存的情况进行递增。
查询缓存命中率的计算公式：Qcache_hits/(Qcache_hits+Com_select)，根据公式计算得出查询缓存命中率为7%。初看上去该命中率很低，但注意到com_select等于qcache_inserts + qcache_not_cache + 权限检查错误的总和，即这个比率中包含了缓存失效的因素，而对于数据变更频繁的系统来说，缓存是及其容易失效的，表的任何时刻的数据插入或更新都会使该表的缓存失效，所以本系统缓存的插入率很低，抛开失效的缓存因素，用如下公式计算缓存命中率：Qcache_hits/(Qcache_hits+Qcache_inserts)= 84.87%，该比值要好得多，意味着大部分的查询都命中了缓存，换一种说法就是仍有一小部分查询没有被缓存。没被缓存和缓存失效是两个概念，分别计数，但都会引起com_select的值增加。
命中率要多少才好，这视情况而定，因为对于每一个查询，不执行它所节约的资源远大于缓存中保存结果以及让查询失效的开销，如果缓存命中代表了开销最大的查询，那么即使很低
的命中率也是有好处的。缓存可能会因为碎片、内存不足或数据改变而失效。如果已经给缓存分配了足够的内存，并且把Query_cache_min_res_unit调整到了合适的值，那么大部分缓存失效都应该是由数据改变而引起的。Com_update, Com_delete等的值知道有多少查询修改了数据，也可以通过检查Qcache_lowmen_prunes的值了解有多少查询因为内存不足而失效。
接近85%的命中率可以满足系统要求，如果该命中率持续降低则需要对系统进行性能分析并调整。系统表数据变更频繁，查询缓存的失效率较高，如果对变更频繁大表的查询频率较高，则使用SQL_NO_CACHE 和SQL_CACHE来控制是否需要使用查询缓存。
Query_cache_size
分配给查询的总内存必须是1024的倍数，系统设置为128MB。在服务器启动的时候，MySQL 会为查询缓存一次性分配变量所定义数量的内存。如果更新了变量，MySQL会立即删除所有缓存的查询，重新把缓存设置为定义的大小，并重新初始化缓存的内存。
Query_cache_type
Query_cache_type设置在何场景下使用 Query Cache。系统的查询缓存是开启状态。_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache，只有显示要求才使用query cache(使用sql_cache)。
Query_cache_limit
该选项限制了MySQL存储的最大结果为2M，如果查询的结果比这个值大，那么就不会被缓存。服务器在产生结果的同时进行缓存，它无法预先知道结果是否会超过这一限制。如果在缓存的过程中发现已经超过了限制，MySQL会自动增加Qcache_not_cached的值，并且丢掉已经缓存过的值。如果预先判断会有这种情况，可以给查询加上SQL_NO_CHACHE来避免这种开销。
以查询某表（18列）中的5000条结果为例，结果集数据大小约为1.4M，该设置是能满足
要求的，保持该值即可。但如果查询结果数据过万的情况较多的话则应适当增加该值，最大不要超过4M。
Qcache_free_memory
如果缓存由大结果和小结果混合而成，那么就很难找到一个合适的大小，既能避免碎片，也能避免过多的内存分配，但是缓存大结果没有太大的益处，可以通过降低Query_cache_limit的值阻止缓存大结果，它有时有助于在碎片和在缓存中保存结果的开销中得到平衡。
Query_cache_min_res_unit
Qcache_free_blocks
Qcache_total_blocks
Qcache_lowmen_prunes
可以通过检查Qcache_free_blocks的值来观察缓存中碎片的情况，它可以显示缓存中有多少内存块处于空闲状态。碎片最严重的情况就是在每两个存储了数据的块之间都有一个比最小值稍小的可用块，这样每隔一个存储块就有一个自由块，因此，如果Qcache_free_blocks 大致等于Qcache_total_blocks/2，则说明碎片非常严重。Qcache_lowmem_prunes表示由于缓存内存不足被清除出查询缓存的条数，如果Qcache_lowmem_prunes的值正在增加，并且有大量的自由块，就说明碎片导致查询正被从缓存中永久删除。
查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。使用FLUSH QUERY CACHE命令移除碎片，该命令会把所有的存储块向上移动，并把自由块移到底部。当它运行的时候，会阻
止访问查询缓存，这会锁定整个服务器，但它通常会很快，除非缓存特别大。
如果缓存没有碎片，但是命中率却不高，那么就应该给缓存分配较少的内存，如果服务器找不到足够大小的块来存储结果，就应该从缓存中清理掉一些查询，可以使用RESET QUERY CACHE命令从缓存中移除查询。当服务器清理查询的时候，Qcache_lowmen_prunes值会增加，如果它的值增加得很快，可能有两个原因：1）如果有很多自由块，就可能是有碎片引起的；2）如果自由块比较少，就可能表示工作负载使用的内存大小超过了所分配的内存，可以检查Qcache_free_memory知道为使用的内存数量。
如果有很多自由块，碎片很少，由于内存不足引起的清理工作也很少，但命中率仍然不高，这说明工作负载也许不能从缓存中受益，一定有什么阻止了查询使用缓存，很多update语句可能会是原因，另一个原因可能是查询是不可缓存的。
查询缓存分配的最小块的大小Query_cache_min_res_unit为4MB。
当查询进行的时候，MySQL把查询结果保存在查询缓存中，但如果要保存的结果比较大，超过query_cache_min_res_unit的值，这时候MySQL会一边检索结果，一边保存结果，所以，有时候并不是把所有结果全部得到后再进行一次性保存，而是每次分配一块query_cache_min_res_unit 大小的内存空间保存结果集，使用完后，接着再分配一个这样的块，如果还不够，接着再分配一个块，依此类推，也就是说，有可能在一次查询中，MySQL要进行多次内存分配的操作。当一块分配的内存没有完全使用时，MySQL会把这块内存截掉，把没有使用的那部分归还以重复利用，当连续操作后剩下的内存大小不足以分配一个内存单元时，内存碎片便产生了。
通常无法避免所有的碎片，但是仔细选择Query_cache_min_res_unit可以避免在查询缓存中造成大量的内存浪费，关键在于每一个新块和服务器已分配给存储结果的块的数量之间找到平衡，如果值过小，服务器将会浪费较少的内存，但会更频繁地分配块，这对服务器意味着
更多的工作。如果值过大，碎片将会很多，合适的折中是在浪费内存和增加处理时间上取得平衡。
空缓存百分比：Qcache_free_blocks / Qcache_total_blocks ≈16%，且系统Qcache_free_blocks值较高，有可能是出现碎片了，使用flush query cache整理查询缓存并消除碎片，该命令不会从缓存中移除任何查询。同时定期观察内存碎片情况。
Key_buffer_size
Key_reads
Key_reads_requests
键缓存读命中率：100-（（Key_reads*100）/ Key_reads_requests）= 99.975
Key_read_requests和Key_reads是两个计数器，Key_read_requests是从缓存读取索引的请求次数，Key_reads是从磁盘读取索引的请求次数。
key_buffer_size指定MyISAM表索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。MyISAM键缓存默认只有一个缓冲区，MyISAM自身只缓存了索引，没有数据，它让操作系统缓存数据，它的值应该占到所有保留内存的25%到50%，操作系统缓存用来保存从MYD文件中读取出来的数据。该变量给键缓冲分配指定大小的空间，但是操作系统只有在实际用到这些空间的时候才会进行分配，也可以创建多个键缓存，如果对于一个非默认大小的键缓存设置为0，MySQL就会把每一个索引从特定的缓存移到默认的缓存中，并且在没有对象使用特定的缓存时就将其删掉，给一个不存在的缓存设置这个变量将会创建缓存，对一个已有的缓存设置非零值将会冲洗缓存，这是一个在线操作，它会阻止所有访问该缓存的动作，直到缓存冲洗完成。另一个参考指标是单位时间内Key_reads值的变化情况。
系统使用MyISAM表查询频率较低，键缓存读命中率在99%以上，表明键缓存能满足系统的性能要求。
Key_blocks_unused
Key_blocks_used
键缓存使用率= Key_blocks_used/ (Key_blocks_used+ Key_blocks_unused)=37%尽管键缓存使用率较低，说明key_buffer_size设置较高，MySQL没有将其使用完，基于键缓存各方面都能满足系统要求且内存够用，不必调整。
table_cache_size/table_open_cache (5.1.2之后叫做table_open_cache)
Open_tables
Opened_tables
Open_tables表示当前打开的表缓存数，如果执行flush tables操作，则此系统会关闭一些当前没有使用的表缓存而使得此状态值减小；opend_tables表示曾经打开的表缓存数，会一直进行累加，如果执行flush tables操作，值不会减小。
应该将Open_tables的值和table_cache进行对照。如果每秒有太多Opened_tables，那么说明table_cache还不够大，表缓存没有被完全利用上时，显式的临时表也能导致Opened_tables 增加。
table_cache指定表高速缓存的大小。设置该变量不会立即生效，要等到下一个线程打开表的时候才会生效，当它生效的时候，MySQL会检查变量的值，如果值大于缓存表中的数量，线程就可以把新打开的表插入到缓存中，这样可以更快地访问表内容。如果值小于缓存表中的数量，MySQL就会从缓存中删除掉没有使用的表。通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_cache的值。如果发现open_tables等于table_cache，并且opened_tables在不断增长，那么就需要增加table_cache的值了。
Open_tables值与table_cache相等，且观察到Opened_tables较大，应适当增加table_cache，可将其设置为512。
thread_cache_size
thread_cache_size是缓存的同时操作的线程数。线程缓存保存了和当前连接无关的线程，这些线程可以供新连接使用。当一个新连接被创建出来并且缓存中有一个线程的时候，MySQL会把这个线程从缓存中删除，并且把它赋给连接。连接关闭时，MySQL会回收线程，把它放回到缓存中。如果缓存中没空间了，MySQL就会销毁该线程。只要缓存中有自由的线程，MySQL就能很快地响应连接请求，因为它不需要为每个连接都创建新的线程。
设置该变量不会立即生效，需要等到下一次线程关闭的时候，MySQL会检查缓存中是否有空间存储线程。如果是，他会把线程缓存起来，供另外一个连接使用，如果不是，它会直接结束线程，这种情况下，缓存中线程的数量，以及线程缓存使用的内存数量不会立即下降。只有当新连接为了使用线程而把它从缓存中移走的时候才会看到下降。MySQL只有在连接关闭的时候才会把线程加入缓存，也只有在创建新连接的时候才从缓存中移除线程。
Connections
thread_connected
threads_created
Connections变量表示连接意图的数量，而不是当前接连的数量（threads_connected），如果它的值快速增加，比如每秒几百，就应该检查连接以及操作系统的网络设置。本系统中该值正常。
thread_cache_size定义了MySQL能在缓存中保存的线程数量，可以通过观察threads_created变量的值，以确定线程缓存是否足够大。如果Threads_created的值较大或正在增加，可以尝试增加thread_cache_size的值，通过检查Threads_created知道有多少缓存已经在缓存中了。
如果每秒创建的线程数量少于10个，缓存的大小就是足够的。另外，可以观察
thread_connected值的变化来设置线程缓存，本系统中它的值保持在100以下。大多数情况，非常大的线程缓存是没有必要的，通常需要把线程缓存保持足够大以使threads_created不会经常增加，但是如果它的值非常大，本系统已超过一万就属于非常大了，那么就应该把它设置得小一点，因为操作系统不能很好地处理太多的线程，即使它们处于睡眠状态也不行。通常情况，据物理内存设置规则如下：1G内存设为8，2G内存设为16，3G内存设为32，4G或4G以上设为64。
本系统内存为4G，且thread_connected 的增幅并不大，thread_cache_size设置为64，不需要更改。
read_buffer_size
read_buffer_size是MySQL读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySQL会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁，并且频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能。MySQL只有在查询需要的时候才会为该缓存分配内存，并且是一次性把指定的大小分配给该缓存。
read_rnd_buffer_size
read_rnd_buffer_size是MySQL的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySQL会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。MySQL只有在查询需要的时候才会为该缓存分配内存，并且只会分配所需的内存。
sort_buffer_size
sort_buffer_size是MySQL执行排序使用的缓冲大小。如果想要增加ORDER BY的速度，
首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能，可以尝试增加sort_buffer_size变量的大小。MySQL只有在查询需要排序的时候才会为该缓冲区分配内存，只要发生了排序，MySQL会立即分配变量定义的所有内存，不管是否需要这么大的空间。如果它的值大于排序需要的空间，那么就意味着浪费。sort_buffer_size有可能会受CPU缓存的影响。
Sort_merge_passes
Sort_merge_passes的值较大说明应该增加sort_buffer_size，也许仅仅是为某些查询，最好的办法就是优化排序性能较慢的查询。
sort_buffer_size为3M，能够满足系统的查询要求。对于排序没有额外要求的情况下不需要调整。
innodb_log_file_size
Innodb_log_files_in_group
InnoDB日志文件总体大小由innodb_log_file_size和innodb_log_files_in_group控制，并且它们对写入的性能影响较大。这两个文件默认大小都较小，对于高性能的负载，这个大小是不够的，日志文件总大小的上限是4GB，但是即使是写入负载极高的查询也只需要几百兆，比如总共256MB。
innodb_log_buffer_size
InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innodb_log _buffer 中，当满足innodb_flush_log_at_trx_commit参数所设置的相应条件(或者日志缓冲区写满)之后，才会将日志写到文件中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。控制缓冲大小的变量是innodb_log_buffer_size。不需要把缓冲区变得很大。推荐值是1MB到8MB。除非要写入大量的巨型BLOB记录，否则这个大小就足够了，日志相对
InnoDB的正常数据要紧凑得多。它们不是基于页面的，所以它们不会在存储数据的时候浪费整个页面。
innodb_os_log_written
可以通过show innodb status命令的log部分检测InnoDB向日志文件写入了多少数据，一个好的办法就是观察10秒到100秒时间间隔内的数据，并且注意最大值，可以使用这个值来判断日志缓冲大小是否合适。例如，如果最大数据是每秒写入100KB，那么1MB的日志缓存可能就足够了。也可以使用这个指标来决定日志文件的合适大小。如果最大值是每秒100KB，256MB日志文件就已足够了。
innodb_flush_log_at_trx_commit
如果比起持久性而更在意性能，可以通过设置innodb_flush_log_at_trx_commit的值来控制日志缓存被刷写到什么地方及刷写的频率。
该参数可以设置为0，1，2，解释如下：
0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的提交并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作；
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步；
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。
上午10点抽样查看半小时的日志数据情况，每分钟InnoDB向日志文件写入了多少数据，抽取其中数据较大的10条信息分析查看：
InnoDB平均每分钟向日志文件写入约9.2MB，而本系统大部分情况下每分钟写入约5MB～
6MB，每秒写入约100KB，本系统innodb_log_file_size设置为64MB，可以将该值设置为256MB，使其足够大满足性能要求，日志文件越大，越节省IO，但是会增长恢复时间。该抽样可能不是系统最高峰值，在系统负载最大时分析得出的结果更加准确。
innodb_max_dirty_pages_pct
innodb_max_dirty_pages_pct不是用来设置用于缓存某种数据的内存大小的一个参数，而是用来控制在 InnoDB缓冲池中可以不用写入数据文件中的脏数据页的比例（本系统为默认值：90%），即已经被修改但还没有从内存中写入到数据文件的脏数据。这个比例值越大，从内存到磁盘的写入操作就会相对减少，所以能够一定程度下减少写入操作的磁盘I/O。
保持默认值。
innodb_file_per_table
innodb_file_per_table选项使InnoDB为每一个表使用一个文件，它在数据库目录中以表名.ibd文件形式保存数据，这使得删除表后回收数据变得比较容易，并且它对于把表分布到多个磁盘上也很有用处，但将数据放在多个文件中能导致浪费更多的存储空间，因为它把单个InnoDB表空间的碎片都放在了ibd文件中，这对于小表尤其会成为一个问题，因为InnoDB 的页面大小是16KB，即使表只有1KB数据，它也需要至少16KB的磁盘空间。即使开启了innodb_file_per_table选项，还需要为撤销日志和其他系统数据定义表空间，而且不能简单地通过拷贝文件来移动、备份或恢复表，且肯定不能在服务器之间拷贝数据。
本系统数据小于1万条表比重超过80%，不需要为每个表使用一个文件，保持默认值。concurrent_insert
可以使用concurrent_insert变量配置MyISAM表的并发插入行为，它有下面的值：0，MyISAM不允许并发插入，每一次插入都会把表锁住；1，默认值，只要表中没有空缺，MyISAM 就允许并发插入；2，它强制并发插入到表尾，即使表有空缺也不例外，如果没有线程从表中
读取数据，MySQL就会把新数据插入到空缺中。使用了该值，表的碎片会增多，也就需要更经常地对表进行优化。
保持默认值。
delay_key_write
对于MyISAM表，可以通过配置把一些操作延迟，然后合并到一起执行，例如可以使用delay_key_write延迟写入索引，但也会带来一些矛盾：立即写入索引，安全但代价较高，或者等待写入并邪王在写入前不要断电，这样更快，但断电就会导致大规模的索引损坏。innodb_thread_concurrency
InnoDB控制并发最基本的方式是使用innodb_thread_concurrency变量，它限制了一次有多少线程，它限制了一次有多少线程能进入内核，没有办法为所有的架构和负载确定最佳的并发数量，但通常情况下可以这样计算：
并发=CPU数量×磁盘数量×2，本系统计算并发数为8。
innodb_thread_sleep_delay
如果InnoDB内核中已经有了允许数量的线程，那么线程就不能再进入内核了，InnoDB采用了一种两阶段的过程来保证线程可以尽可能高效地进入内核，这种策略减少了操作系统引起的开销。线程首先睡眠innodb_thread_sleep_delay所规定的微秒数，然后再进行尝试，如果还是不能进入，它就会进入一个等待线程的队列中并且把控制权交给操作系统。第一阶段默认的睡眠时间是10000微秒，当有很多线程都处于‘正在等待进入队列’这一状态时，改变这个值有助于提高系统并发，而默认值在有大量小查询的时候会太大了，因为它给查询增加了10毫秒延时。
保持默认值，当并发使用大查询时才有必要调整该值。
innodb_commit_concurrency
InnoDB在提交阶段还有另外一种形式的并发瓶颈，就是刷写操作造成的密集I/O操作。innodb_commit_concurrency变量决定了某一时刻有多少线程能进行提交。当系统有大量线程状况不佳时，可以尝试将该变量增加。
保持默认值，即不限制并发提交线程数。
max_length_for_sort_data
max_sort_length
MySQL有两种文件排序算法，如果需要进行排序的列的总大小超过了max_length_for_sort_data定义的字节，MySQL就会使用双路排序，反之就会选择单路排序，双路排序需要两次访问数据，尤其是第二次读取操作会导致大量的随机I/O操作。如果将并不需要的Columns也取出来，就会极大地浪费排序过程所需要的内存，为了尽可能地提高排序性能，尽量使用第二种排序算法，所以在查询中仅取出需要的列是非常有必要的。
对于本系统，默认值足够大，能满足性能要求。
Aborted_clients
如果Aborted_clients变量随时间增加，那么就要确定是否正常地关闭了连接。如果不是，就要检查网络性能，并且检查max_allowed_packet变量，超多了max_allowed_packet的查询会被强制地中断。
Aborted_connects
Aborted_connects变量的值应接近于0，否则就可能有网络问题，有几个被中断的连接是正常的。例如，试着从错误的主机连接、使用了错误的用户名和密码，或者定义了无效的数据库，都会发生这样的情况。
观察本系统10分钟内的Aborted_clients变化，一直保持为0，说明没有连接方面的异常情况，可以定期观察该变量分析连接问题。
binlog_cache_size
Binlog_cache_disk_use
Binlog_cache_use
当使用事务的表存储引擎InnoDB时，所有未提交的二进制日志会被记录到一个缓存中，等该事务提交时直接将缓冲中的二进制日志写入二进制日志文件，而该缓冲的大小由binlog_cache_size决定，默认大小为32KB。此外，binlog_cache_size是基于会话的，当一个线程开始一个事务时，MySQL会自动分配一个大小为binlog_cache_size的缓存，因此该值不能设置过大。当一个事务的记录大于设定的binlog_cache_size时，MySQL会把缓冲中的日志写入一个临时文件中，因此该值又不能设得太小。通过查看binlog_cache_use、binlog_cache_disk_use的状态,可以判断当前binlog_cache_size的设置是否合适。Binlog_cache_use记录了使用缓冲写二进制日志的次数，binlog_cache_disk_use记录了使用临时文件写二进制日志的次数。如果binlog_cache_disk_use与Binlog_cache_use之间的比值很大，就应该增加binlog_cache_size的值，只要保证大部分的事务都在二进制日志缓存里就可以了。
binlog_cache_disk_use/Binlog_cache_use比值非常小，说明本系统绝大部份事务都能下入在二进制日志缓存。
Created_tmp_disk_tables
Created_tmp_tables
每次创建临时表时，Created_tmp_tables增加，如果是在磁盘上创建临时表，则Created_tmp_disk_tables也会增加，通常可以通过Created_tmp_tables/(Created_tmp_disk_tables + Created_tmp_tables)来判断基于内存的临时表利用率。如果Created_tmp_disk_tables太大，则需要检查并优化查询语句，或有可能
是tmp_table_size和max_heap_table_size不够大。Created_tmp_disk_tables / Created_tmp_tables <= 5%就属于比较好的情况，如果该比值超过25%则需要调整，本系统中该比值约为11.24%。
tmp_table_size
max_heap_table_size
tmp_table_size规定了内部内存临时表的最大值，每个线程都要分配，但实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。如果内存临时表超出了限制，MySQL 就会自动地把它转化为基于磁盘的MyISAM表，存储在指定的tmpdir目录下（show variables like 'tmpdir'）。
max_heap_table_size变量定义了用户可以创建的内存表(memory table)的大小.这个值用来计算内存表的最大行数值。这个变量支持动态改变，改变后对于已经存在的内存表就没有什么用了，除非这个表被重新创建(create table)或者修改(alter table)或者truncate table。当然也可以在配置文件中设置全局变量。本系统中，只有32MB以下的临时表才能全部放内存，超过的就会用到硬盘临时表。
基于内存的临时表利用率：
Created_tmp_tables/(Created_tmp_disk_tables + Created_tmp_tables) ≈90%，该比值较理想，如果需要使用大数据量临时表时，则手工创建新表来存储数据，避免临时表目录空间不够的问题。
Max_connections和Max_used_connections
max_connections表示允许的并行客户端连接数目。增大该值则增加MySQLd 需要的文件描述符的数量。table_cache、max_connections和max_tmp_tables系统变量影响服务器保持打开的文件的最大数量。如果你增加这些值其中的一个或两个，会遇到操作系统为每个进程打
web性能优化(服务器优化)
Web网站性能优化的相关技术 来源：站长网 https://www.sodocs.net/doc/36772166.html, 2011-03-04 06:50:47 Web站点性能问题吸引或者迫使越来越多的人投入到这个问题的研究中来，产生了很多解决方案。下面是我根据自身的理解对这些技术进行了归类总结，如有不足之处欢迎拍砖。 一、提高服务器并发处理能力 我们总是希望一台服务器在单位时间内能处理的请求越多越好，这也成了web 服务器的能力高低的关键所在。服务器之所以可以同时处理多个请求，在于操作系统通过多执行流体系设计，使得多个任务可以轮流使用系统资源，这些资源包括CPU、内存以及I/O等。这就需要选择一个合适的并发策略来合理利用这些资源，从而提高服务器的并发处理能力。这些并发策略更多的应用在apache、nginx、lighttpd等底层web server软件中。 二、Web组件分离 这里所说的web组件是指web服务器提供的所有基于URL访问的资源，包括动态内容，静态网页，图片，样式表，脚本，视频等等。这些资源在文件大小，文件数量，内容更新频率，预计并发用户数，是否需要脚本解释器等方面有着很大的差异，对不同特性资源采用能充分发挥其潜力的优化策略，能极大的提高web 站点的性能。例如：将图片部署在独立的服务器上并为其分配独立的新域名，对静态网页使用epoll模型可以在大并发数情况下吞吐率保持稳定。 三、数据库性能优化和扩展。 Web服务器软件在数据库方面做的优化主要是减少访问数据库的次数，具体做法就是使用各种缓存方法。也可以从数据库本身入手提高其查询性能，这涉及到数据库性能优化方面的知识本文不作讨论。另外也可以通过主从复制，读写分离，使用反向代理，写操作分离等方式来扩展数据库规模，提升数据库服务能力。 四、Web负载均衡及相关技术 负载均衡是web站点规模水平扩展的一种手段，实现负载均衡的方法有好几种包括基于HTTP重定向的负载均衡，DNS负载均衡，反向代理负载均衡，四层负载均衡等等。 对这些负载均衡方法做简单的介绍：基于HTTP重定向的负载均衡利用了HTTP 重定向的请求转移和自动跳转功能来实现负载均衡，我们熟悉的镜像下载就使用这种负载均衡。DNS负载均衡是指在一个DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时返回不同的解析结果将客户端的访问引到不同的机
性能优化的方法和技巧
性能优化方法和技巧：概述 性能优化有三个层次： ?系统层次 ?算法层次 ?代码层次 系统层次关注系统的控制流程和数据流程，优化主要考虑如何减少消息传递的个数；如何使系统的负载更加均衡；如何充分利用硬件的性能和设施；如何减少系统额外开销（比如上下文切换等）。 算法层次关注算法的选择（用更高效的算法替换现有算法，而不改变其接口）；现有算法的优化（时间和空间的优化）；并发和锁的优化（增加任务的并行性，减小锁的开销）；数据结构的设计（比如lock-free的数据结构和算法）。 代码层次关注代码优化，主要是cache相关的优化（I-cache, D-cache相关的优化）；代码执行顺序的调整；编译优化选项；语言相关的优化技巧等等。 性能优化需要相关的工具支持，这些工具包括编译器的支持；CPU的支持；以及集成到代码里面的测量工具等等。这些工具主要目的是测量代码的执行时间以及相关的cache miss, cache hit等数据，这些工具可以帮助开发者定位和分析问题。 性能优化和性能设计不同。性能设计贯穿于设计，编码，测试的整个环节，是产品生命周期的第一个阶段；而性能优化，通常是在现有系统和代码基础上所做的改进，属于产品生命周期的后续几个阶段（假设产品有多个生命周期）。性能优化不是重新设计，性能优化是以现有的产品和代码为基础的，而不是推倒重来。性能优化的方法和技巧可以指导性能设计，但两者的方法和技巧不能等同。两者关注的对象不同。性能设计是从正向考虑问题：如何设计出高效，高性能的系统；而性能优化是从反向考虑问题：在出现性能问题时，如何定位和优化性能。性能设计考验的是开发者正向建设的能力，而性能优化考验的是开发者反向修复的能力。两者可以互补。
Web性能测试方案
Web性能测试方案 1测试目的 此处阐述本次性能测试的目的，包括必要性分析与扩展性描述。 性能测试最主要的目的是检验当前系统所处的性能水平，验证其性能是否能满足未来应用的需求，并进一步找出系统设计上的瓶颈，以期改善系统性能，达到用户的要求。 2测试范围 此处主要描述本次性能测试的技术及业务背景，以及性能测试的特点。 编写此方案的目的是为云应用产品提供web性能测试的方法，因此方案内容主要包括测试环境、测试工具、测试策略、测试指标与测试执行等。 2.1测试背景 以云采业务为例，要满足用户在互联网集中采购的要求，实际业务中通过云采平台询报价、下单的频率较高，因此云采平台的性能直接决定了业务处理的效率，并能够支撑业务并发的压力。 例如：支撑100家企业用户的集中访问，以及业务处理要求。 2.2性能度量指标 响应时间（TTLB） 即“time to last byte”，指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。响应时间＝网络响应时间+应用程序响应时间。 响应时间标准：
事务能力TPS（transaction per second） 服务器每秒处理的事务数； 一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。 客户机在发送请求时开始计时，收到服务器响应后结束计时，一次来计算使用的时间和完成的事务个数。它是衡量系统处理能力的重要指标。 并发用户数 同一时刻与服务器进行交互的在线用户数量。 吞吐率（Throughput） 单位时间内网络上传输的数据量，也可指单位时间内处理的客户端请求数量，是衡量网络性能的重要指标。 吞吐率=吞吐量/传输时间 资源利用率 这里主要指CPU利用率（CPU utilization），内存占用率。 3测试内容 此处对性能测试整体计划进行描述，包括测试内容以及关注的性能指标。Web性能测试内容包含：压力测试、负载测试、前端连接测试。 3.1负载测试 负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大
web前端工程师实习心得体会(精选3篇)
web前端工程师实习心得体会（精选3篇） web前端工程师实习心得体会 引导语：每个大学生都会有一段实习时间，相信这段时间会给他们带来不少的收获，那么，作为一个在web前端方向实习的学生来说，在编写实习心得体会时，应该从哪些方面入手呢？提供了几篇L：尽量掌握尽可能多的标签。必须掌握的标签有等，这些虽然平时比较少用甚至几乎不用，但是当你学到Boostrap框架时，你会发现Boostrap 框架为这些标签赋予了特定的功能与外观。除此之外，新增了很多标签和属性，使得HTML语言更加强大。还有很多新的内容，需要初学者更多的接触并掌握。 CSS：对各个属性以及一些属性之间结合使用的技巧应该多钻研。CSS能够统一有效地对页面的布局、字体等网页中的各个元素显示属性进行控制，可以方便快捷地实现精美的页面表现效果。你会用CSS 技术的使用技巧解决下列问题吗？清除浮动有哪些方式？比较好的方式是哪一种？当容器中具有浮动元素时，如何为容器设置边框或背景颜色？怎样让块级元素在容器中水平居中？当多个连续块级元素的浮动布局影响了原本不想浮动的对象时该如何处理？容器内部的对象如何实现相对于容器的自由定位？为什么要初始化CSS样式？ CSS+div布局模式：许多布局模式的基础，也是大部分前端开发人员接触到的第一种布局方式。这种布局模式对于PC端页面的设计是非常有帮助的，同时对于后面将会遇到的“移动端布局”、“响应
式布局”等，这种布局方式都具有一定的指导意义。 第二、将JavaScript作为前端学习的重点。JavaScript是目前大多数主流浏览器支持的面向对象的脚本语言，它可以在不与服务器交互的前提下对HTML的页面内容进行修改。JavaScript控制着网页的行为，决定着网页“做什么”。系统学习过JavaScript的同学们，你看看下列问题你能准确的找到答案吗？通过表达式来系统阐述“==”和“===”这两个运算符的区别。把某个元素移除你的视线的方法有哪些？你对JSON了解吗？通过哪个函数可以判断从文本框中获取的内容是不是数字？DOM 操作——怎样添加、移除、移动、复制、创建和查找节点？怎样判断是否为整数？运算符都能删除哪些内容？在脚本中，this有几种使用情况呢？ 第三、多练习多操作，实践是检验真理的唯一标准。IT编程是需要多加实践的，要不断反复进行上机操作，是学习编程开发的唯一方法。 这些问题的答案就是我的实习心得，经过这段时间的实习，我觉得自己可以独当一面，当一个web前端工程师了呢。 web前端工程师实习心得体会篇2 作为web前端工程师，在XX工作了5个月，自己从刚开始的一名新人到最后和大家融为一体，为组内贡献自己的一份力量，我经历了很多，成长了很多。 刚进到公司，我内心是很惶恐的。我对自己没有一个正确的定位，对公司的环境也是那么的陌生。我不知道自己能不能胜任公司的工
Linux操作系统性能调优的方法
按照传统，Linux不同的发行版本和不同的内核对各项参数及设置均做了改动，从而使得系统能够获得更好的性能。下边将分四部分介绍在Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server系统下，如何用以下几种技巧进行性能的优化： QUOTE: 1、Disabling daemons （关闭 daemons) 2、Shutting down the GUI (关闭GUI) 3、Changing kernel parameters (改变内核参数） 4、Kernel parameters （内核参数） 5、Tuning the processor subsystem（处理器子系统调优） 6、Tuning the memory subsystem （内存子系统调优） 7、Tuning the file system（文件系统子系统调优） 8、Tuning the network subsystem（网络子系统调优） 1 关闭daemons 有些运行在服务器中的daemons (后台服务)，并不是完全必要的。关闭这些daemons可释放更多的内存、减少启动时间并减少CPU处理的进程数。减少daemons数量的同时也增强了服务器的安全性。缺省情况下，多数服务器都可以安全地停掉几个daemons。 Table 10-1列出了Red Hat Enterprise Linux AS下的可调整进程. Table 10-2列出了SUSE LINUX Enterprise Server下的可调整进程.
注意：关闭xfs daemon将导致不能启动X，因此只有在不需要启动GUI图形的时候才可以关闭xfs daemon。使用startx命令前，开启xfs daemon，恢复正常启动X。 可以根据需要停止某个进程，如要停止sendmail 进程，输入如下命令： Red Hat: /sbin/service sendmail stop SUSE LINUX: /etc/init.d/sendmail stop
大数据库优化(SQLServer)
SQL SERVER性能优化综述 近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以 前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能 性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效 率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三
性能测试方案
XXX系统--版本号XXX 性能测试方案 XXX有限公司 XXXX年XX月XX日 修订历史记录
目录 1简介 (1) 1.1目的和软件说明 (1) 1.2内容摘要 (1) 1.3适用对象 (1) 1.4术语和缩略语 (1) 1.5参考文档 (1) 2系统概述 (2) 2.1项目背景 (2) 2.2系统架构 (3) 2.2.1架构概述 (3) 2.2.2运行环境 (3) 2.2.3处理流程 (4) 2.3技术方案设计 (4) 3测试目标 (5) 4测试范围 (6)
4.1测试对象 (6) 4.2需要测试的特性 (6) 4.3不需要测试的特性 (7) 5 4. 测试启动/结束/暂停/再启动准则 (8) 5.1启动准则 (8) 5.2结束准则 (8) 5.3暂停准则 (8) 5.4再启动准则 (9) 6测试人员 (10) 7测试时间 (11) 8测试环境 (12) 8.1系统架构图 (12) 8.2测试环境逻辑架构图 (12) 8.3测试环境物理架构图 (12) 8.4环境配置列表 (12) 8.4.1生产环境 (12)
8.4.2测试环境 (13) 8.4.3环境差异分析 (13) 8.4.4测试客户机 (14) 8.5测试工具 (14) 9测试策略 (15) 10测试场景设计 (16) 10.1总体设计思路 (16) 10.2业务模型 (16) 10.3测试场景设计 (17) 10.3.1......................................... 单交易负载测试 17 10.3.2....................................... 混合交易负载测试 18 10.3.3............................................. 稳定性测试 18 10.3.4...................................... 有/无缓存比对测试 19 10.3.5....................................... 网络带宽模拟测试 19 11测试实施准备.. (21) 11.1................................................. 测试环境准备 21
前端项目心得体会
前端项目心得体会 导语：作为一个程序猿，你的任务就是敲代码，接下来为大家介绍前端项目心得体会文章，仅供参考！ 前端项目心得体会 1、知识的总结 项目开发中也许学到了一个技能，或者一个知识点，但是通过写博客会加深巩固自己学习的东西，自己写不出来可能说明你对这个知识点理解还不够深入。 2、表达能力的提升 程序员大都不善于沟通，是因为表达能力不行，但是通过坚持写博客，自己的表达能力与表达逻辑会慢慢锻炼出来，逐渐的就会影响自己的沟通交流能力，这点我深有体会。 3、面试加分 假设我们同时面试了两个人，两人各方面能力差不多，但是一个写博客，一个不写，我想我肯定优先选择坚持写博客的人。他能坚持写博客，起码知道他善于经验总结，很勤快，因为大部分人不写博客很大原因是因为懒学习前端的心得学习前端的心得。 4、提升写作能力 写的多了，写作能力也就提升了，比如我，相信我的写作能力应该比大部分程序员要优秀，你们认同么?
5、提升名气 如果持续产出高质量的博客，被越来越多的人知道，那名气就会上升了，有了名气自身的价值一下就提升了，我深有感受，自从有了名气之后，每天都能收到各大猎头、CEO等的各种优越条件的邀请，选择接受或拒绝是一回事，但是有没有收到邀请就是另一回事了。 6、赚取外快 这个容易理解，有了名气之后就可以有办法赚取各种外快，而且本身也并不可耻，不偷不抢，靠自身技术赚点零花钱有何不可? 比如我，如果哪一天我很缺钱了(虽然现在也缺)，我可以立刻想办法花点精力去赚更多的钱，只不过现在我选择了我最喜欢，最不受约束的方式而已。 最后奉劝大家，如果你还没有写博客，那从现在开始开通个博客学习前端的心得文章学习前端的心得出自。 走出第一步，如果你已经开始写博客了，不要去奢望靠写博客去赚钱，安心的写博客提升自己能力，总结经验，把它看成一种投资自己的手段，别把目标搞错了 也许有一天你会突然发现，原来你已经走了这么远，而且还有意外收获! 勿忘初心，才能方得始终! 如何找实习机会 如果有校招，最好就从校招进去。一些比较优秀的企业都会培养储备人才，用以发展，所以校招能够有机会进到一些分工比较细化的企
系统性能优化方案
系统性能优化方案 (第一章) 系统在用户使用一段时间后（1年以上），均存在系统性能（操作、查询、分析）逐渐下降趋势，有些用户的系统性能下降的速度非常快。同时随着目前我们对数据库分库技术的不断探讨，在实际用户的生产环境，现有系统在性能上的不断下降已经非常严重的影响了实际的用户使用，对我公司在行业用户内也带来了不利的影响。 通过对现有系统的跟踪分析与调整，我们对现有系统的性能主要总结了以下几个瓶颈： 1、数据库连接方式问题 古典C/S连接方式对数据库连接资源的争夺对DBServer带来了极大的压力。现代B/S连接方式虽然不同程度上缓解了连接资源的压力，但是由于没有进行数据库连接池的管理，在某种程度上，随着应用服务器的不断扩大和用户数量增加，连接的数量也会不断上升而无截止。 此问题在所有系统中存在。 2、系统应用方式（架构）问题(应用程序设计的优化) 在业务系统中，随着业务流程的不断增加，业务控制不断深入，分析统计、决策支持的需求不断提高，我们现有的业务流程处理没有针对现有的应用特点进行合理的应用结构设计，例如在‘订单、提油单’、‘单据、日报、帐务的处理’关系上，单纯的数据关系已经难以承载多元的业务应用需求。 3、数据库设计问题（指定类型SQL语句的优化）
目前在系统开发过程中，数据库设计由开发人员承担，由于缺乏专业的数据库设计角色、单个功能在整个系统中的定位模糊等原因，未对系统的数据库进行整体的分析与性能设计，仅仅实现了简单的数据存储与展示，随着用户数据量的不断增加，系统性能逐渐下降。 4、数据库管理与研究问题(数据存储、物理存储和逻辑存储的优化) 随着系统的不断增大，数据库管理员（DBA）的角色未建立，整个系统的数据库开发存在非常大的随意性，而且在数据库自身技术的研究、硬件配置的研究等方面未开展，导致系统硬件、系统软件两方面在数据库管理维护、研究上无充分认可、成熟的技术支持。 5、网络通信因素的问题 随着VPN应用技术的不断推广，在远程数据库应用技术上，我们在实际设计、开发上未充分的考虑网络因素，在数据传输量上的不断加大，传统的开发技术和设计方法已经无法承载新的业务应用需求。 针对以上问题，我们进行了以下几个方面的尝试： 1、修改应用技术模式 2、建立历史数据库 3、利用数据库索引技术 4、利用数据库分区技术 通过尝试效果明显，仅供参考！
数据库性能优化基础步骤
1性能优化基本步骤 1.1定位跟踪耗费资源较多的SQL语句步骤 1.1.1 通过SQL查询 (1): 查询出最耗费资源的SQL语句 select t1.SID, t1.SERIAL#, tt.HASH_VALUE, tt.ADDRESS, tt.BUFFER_GETS, --读内存次数 tt.DISK_READS, --磁盘物理读次数 tt.EXECUTIONS, --语句的执行次数 tt.BUFFER_GETS / tt.EXECUTIONS, --平均读内存次数 tt.SQL_FULLTEXT from v$sqlareatt, v$session t1 where (tt.BUFFER_GETS>100000 or tt.DISK_READS>100000) and tt.HASH_VALUE = t1.SQL_HASH_VALUE and tt.ADDRESS = t1.SQL_ADDRESS and t1.STATUS = 'ACTIVE' orderby tt.BUFFER_GETS desc (2)：根据客户端程序发出的SQL来定位需要跟踪的session select s.sid sid, s.SERIAL# "serial#", https://www.sodocs.net/doc/36772166.html,ername, s.machine, s.program, s.server, s.LOGON_TIME from v$session s 1.1.2 通过Oracle提供的SQL TRACE进行SQL跟踪 (1)：跟踪前设定相应参数 1．查询得到需要跟踪的session 2．打开时间开关
Show parameter timed_statistics alter session set timed_statistics=true; execsys.dbms_system.set_bool_param_in_session(sid => 8,serial# => 3,parnam => 'timed_statistics',bval => true); 3．设置跟踪文件存放位置 Show parameter user_dump_dest alter system set user_dump_dest='c:\temp'; (2)：启动跟踪功能并让系统运行一段时间 alter session set sql_trace=true; execsys.dbms_system.set_sql_trace_in_session(8, 3, true); (3)：关闭跟踪功能 alter session set sql_trace=false; execsys.dbms_system.set_sql_trace_in_session(8, 3, false); (4)：格式化跟踪数据文件，并分析跟踪结果文件 tkprof dsdb2_ora_18468.trc dsdb2_trace.txt EXPLAIN=SCOTT/TIGER tkprof各参数含义： ' traced_file ' 指定输入文件，即oracle产生的trace文件 'formatted_file'指定输出文件，即我们想得到的易于理解的格式化文件 'EXPLAIN' 利用哪个用户对trace文件中的sql进行分析得到该sql语句的执行计划1.2查看分析执行计划 1.2.1查看执行计划 (1)：Sqlplus中可按F5查看执行计划 (2)：使用执行计划表进行查看 使用语句将SQL语句的执行计划装入plan_table表，然后进行分析查看explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value (3)：示例演示 1．让ORALCE自动选择最优的执行计划，不人为干预 explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value
网站界面分析和优化设计 (2)
网站界面分析和优化设计 一、网站界面优化的重要性。 web技术的发展，使得互联网用户从单纯浏览信息时代迈入了更加注重交互、更加人性化的时代。网民使用互联网产品已经不仅仅只关注工作效率，而是越来越关心使用过程中的体验。网站界面的本质是让用户做主，操作简便性、强调交互性。 在互联网发展的过程中，最初希望通过建立网站来抢占市场、树立形象的企业逐步认识到网站提供优质的用户体验才是可持续发展的竞争优势，而网站服务界面的设计效果是用户体验好坏的直接影响因素。某电商网站Allurent曾经做过一个调查，当用户对某一网站的验较差时，80%的用户表示不会再次访问该网站，60%的用户表示影响到了自己对该商家的整体印象，而40%的用户表示甚至可能不再去该商家的实体店铺。用户不良体验无疑是在与网站界面的交互中形成的。目前，很多商业网站已经充分认识到周到、贴心的网站界面设计对于企业利益获取的重要性。很多跨国公司如雅虎、惠普、IBM微软、苹果、等都先后成立了用户体验研究机构，尝试将用户体验的研究成果应用到界面设计中来，国内互联网企业如百度、腾讯等也都建立了相应的研究团队。 二、网站界面优化的核心要素 网站服务界面是指网站为用户办事服务和提供信息的网页内容展现方式。关注服务界面，就是要做好网页界面的优化设计工作。基于用户体验进行网站服务界面优化设计，需要将用户体验从不同层次、
维度进行分解，提取与网页界面相关的要素，然后才能对相应要素实施具体的优化设计。 Adaptive Path公司的创始人James Garrett对用户体验的要素进行过较为系统地研究，将用户体验划分为战略、范围、结构、框架、表现10个核心要素，如图所示。这5个层面自下而上逐步的从抽象转为具体。 图1. 用户体验要素模型 这一用户体验要素模型中与界面优化直接相关的是框架层和表现层的四个关键要素，即界面设计、导航设计、信息设计和视觉设计。我们主要讨论界面设计这一主要要素。 三、网站界面的优化 3.1提高页面响应速度 随着科技的发展用户等待网页加载的耐性越来越低。2009年，微软搜索引擎必应（bing）进行过一项调查，研究页面载入速度和其他网站指标是否有明显相关性。根据报告显示，每2秒钟的延迟页面会使用户满意度降低3.8%的，减少4.3%的单位用户收入和减少4.3%
安卓性能优化方案
随着技术的发展，智能手机硬件配置越来越高，可是它和现在的PC相比，其运算能力，续航能力，存储空间等都还是受到很大的限制，同时用户对手机的体验要求远远高于PC的桌面应用程序。以上理由，足以需要开发人员更加专心去实现和优化你的代码了。选择合适的算法和数据结构永远是开发人员最先应该考虑的事情。同时，我们应该时刻牢记，写出高效代码的两条基本的原则：（1）不要做不必要的事；（2）不要分配不必要的内存。 我从去年开始接触Android开发，以下结合自己的一点项目经验，同时参考了Google的优化文档和网上的诸多技术大牛给出的意见，整理出这份文档。 1. 内存优化 Android系统对每个软件所能使用的RAM空间进行了限制(如：Nexus o ne 对每个软件的内存限制是24M)，同时Java语言本身比较消耗内存，d alvik虚拟机也要占用一定的内存空间，所以合理使用内存，彰显出一个程序员的素质和技能。 1) 了解JIT 即时编译（Just-in-time Compilation，JIT），又称动态转译（Dynamic Translation），是一种通过在运行时将字节码翻译为机器码，从而改善字节码编译语言性能的技术。即时编译前期的两个运行时理论是字节码编译和动态编译。Android原来Dalvik虚拟机是作为一种解释器实现，新版
（Android2.2+）将换成JIT编译器实现。性能测试显示，在多项测试中新版本比旧版本提升了大约6倍。 详细请参考https://www.sodocs.net/doc/36772166.html,/cool_parkour/blog/item/2802b01586e22cd8a6ef3f6b. html 2) 避免创建不必要的对象 就像世界上没有免费的午餐，世界上也没有免费的对象。虽然gc为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则： 当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个Stri ngBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。 一个更极端的例子是，把多维数组分成多个一维数组： int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多。同理，这试用于所有基本类型的组合。如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[]
系统性能调优方案
第1章系统性能调优方案 1.1系统的性能扩展模型介绍 在进行性能指标设计工作前，必须从理论上对性能指标的可实现性进行分析。理论上，系统的扩展模型可以分成两类，系统可扩展模型和不可扩展模型，如下图所示： 两种性能扩展模型 以上左图代表了系统随着并发用户量的增加系统响应时间呈现线性增长的 趋势，是一种可扩展的情况；但对于系统右边的方式则是不可扩展的，它将随着用户数量的增大而响应时间大大急剧增加，这种模型是完全不可控制的。 通过系统压力实验，我们发现，即使是遵循可扩展模型设计的系统的响应性能和并发用户量并不能成永远的线性关系，在系统压力超过一定的值之后，如100并发，系统响应时间增加非常快，我们把这个点称为拐点。在拐点以下，系统性能呈现良好的线性特性，在拐点以上，则呈现出非线性的特征，同时CPU 和内存出现相当大的增长，甚至100%占用。这种现象的出现，说明系统的性能 不仅仅取决于软件系统，而也同时取决于承载系统的硬件基础环境，如计算能力和内存大小。 为此，系统性能设计的目的就是为系统设置合理的拐点并发值，而不可能无限制的追求无限大的并发下系统响应仍旧呈现线形特征。
1.2对响应时间的技术保障手段 金税三期工程第二阶段河南地税建设项目财务管理子系统对系统的性能要求是比较高的，为了满足这个要求，在系统实现上必须要采用一系列的技术措施才能达到，具体来说将采用下面方式进行： 1、预处理技术的应用 预处理技术是一种在预定计划上由系统激发主动执行的计算模式，它对于一些处理内容固定，处理方式固定的功能非常有效，通过提前处理，实现数据生成时间和数据访问时间的隔离，在数据访问的时候不再需要为拿到结果而执行任何的计算，只需要简单的查询结果即可，这样可以大大增强系统的访问性能，有效的利用系统闲置时间。 2、变动态内容查找为静态数据访问 一些情况下，经过各种调优手段仍不能满足要求，就需要将一些动态的内容进行静态化处理，如可以将复杂的动态报表转化成HTML网页并发布在WEB服务器上，这种方式可以大大减轻应用服务器的访问压力，进一步减少用户等待的时间。例如，对一段历史时期的数据的汇总报表结果的查询，复杂报表结果等查询。 3、异步功能调用模式 对一些耗时较长的处理内容，如果必须由人工进行启动，那么，可以采用这种方式，用户调用程序的时候，实际上只是发送了一个消息给后台服务器，并在服务器端注册信息处理完后需要回馈的客户端，然后系统提示用户系统正在或很快处理这个任务，这样，立刻就能够解放用户，用户可以利用在后台处理的时间去处理其他的任务，在系统处理完后，采用推技术(push)，将处理结果提示给用户，从而完成功能的调用全过程。 4、浏览器显示时采用分页、分时显示技术 用户从数据库查询得到的数据如果行数比较多，比如大于100行。在IE端显示就需要花费很长时间，有时让查询人员无法忍受。分页技术，就是利用先显示结果的一部分，一般结果的前50条记录，后面的记录通过翻页的功能去显示其余部分。比如在查询正常计划详细列表页面时，通过查询得到1000条记录，
web系统性能优化
WEB站点性能优化 由于较少的接触WAP站点的建设，缺乏类似站点的建设经验，导致后期的性能问题成了影响项目交付的较严重的因素。 经过后面深入的了解，发现浏览器在访问网站的过程中，有很多地方可以进行性能优化处理。案例分析： 首先，我们先来了解一下客户端(这里指终端浏览器)访问服务器的全过程。 以火狐3.6.8浏览器为例(图例来自火狐浏览插件firebug截图) 从上图可以看出，该页面前后一共向后台发送了6次请求，即建立6次连接。 ●过程一：第1次请求，url地址请求服务器，获得相应的页面html，该次请求需要服务器相 应的业务逻辑处理然后生成页面，花费的时间稍长。 ●过程二：第2、3次请求，终端浏览器接收到请求的html页面后，需要请求页面引入的外部 资源(如css样式,js脚本,图片等)，此时请求过程是并行连接。 ●过程三：第4、5、6次请求，终端浏览器接收到css样式资源后，需要为css中引入的其他外 部资源(图片较为常见)再次发送请求，所有的图片请求也是并行连接，与此同时也会进行页面的渲染工作。
另外，过程二、过程三中提到的并行连接，在各种不同浏览器中体现出来的能力也不一样。 下图显示了每个支持当前的浏览器为HTTP/1.1中以及HTTP/1.0的服务器最大连接数。 简化的浏览器响应时间的计算模型： 终端用户响应时间= 页面下载时间+ 服务器响应时间+ 浏览器处理及渲染时间 页面下载时间= 页面大小/ 网络带宽+ （网络延迟×HTTP 请求数）/ 并发度 所以如果我们可以通过监听互联网应用的网络传输行为得到页面大小、HTTP 请求数、并发度、服务器响应时间和浏览器处理及渲染时间，那么我们就可以推测这个应用在任意网络环境下的终端用户响应时间 优化思路 从上面公式中可以看出，网络带宽、网络延迟由网络环境决定，是系统不可控的，并发度是终端浏览器本身具备的能力，也是系统不可控的。余下的公式参数页面尺寸，HTTP请求数则是我们需要找寻的突破点，我们可以从如下几个方向着手。 1. 减少连接次数 终端浏览器响应的时间中，有80%用于下载各项内容。这部分时间包括下载页面中的图像、样式表、脚本、Flash等。通过减少页面中的元素可以减少HTTP请求的次数。这是提高网页速度的关键步骤。 合并文件 是通过把所有的脚本放到一个文件中来减少HTTP请求的方法，如可以简单地把所有的CSS 文件都放入一个样式表中。当脚本或者样式表在不同页面中使用时需要做不同的修改，这可能会相对麻烦点，但即便如此也要把这个方法作为改善页面性能的重要一步。 CSS Sprites 是减少图像请求的有效方法。把所有的背景图像都放到一个图片文件中，然后通过CSS的background-image和background-position属性来显示图片的不同部分；
网站前端性能优化总结
网站前端性能优化总结 一、服务器侧优化 1. 添加 Expires 或 Cache-Control 信息头 某些经常使用到、并且不会经常做改动的图片（banner、logo等等）、静态文件（登录首页、说明文档等）可以设置较长的有效期（expiration date），这些HTTP头向客户端表明了文档的有效性和持久性。如果有缓存，文档就可以从缓存（除已经过期）而不是从服务器读取。接着，客户端考察缓存中的副本，看看是否过期或者失效，以决定是否必须从服务器获得更新。 各个容器都有针对的方案,，以 Apache 为例： ExpiresActive On ExpiresByType image/gif "access plus 1 weeks" 表示gif文件缓存一周，配置可以根据具体的业务进行调整，具体配置可以参考： https://www.sodocs.net/doc/36772166.html,/Apache/ApacheMenu/mod/mod_expires.html 2. 压缩内容 对于绝大多数站点，这都是必要的一步，能有效减轻网络流量压力。
大型网站平台优化方案
1. 平台优化方案 大型网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。 上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。 1.1. HTML静态化 由于效率最高、消耗最小的就是纯静态化的html页面，所以尽可能使网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，无法全部手动去挨个实现，于是出现了常见的信息发布系统CMS，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。 除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，如Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。 同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
22提供性能优化方案---Google-Code
Linux系统性能测试与分析 1、前言 通过对系统中和性能相关的各个环节的介绍，使大家知道出现性能问题时可以从那些方面入手去查，而分析典型应用对系统资源使用的特点，让大家对应用和系统资源的依赖有了更直观的认识。大多数的硬件性能问题主要和CPU、磁盘、内存相关，还没有遇到因为开发语言的运行效率对整个应用的性能造成影响，而应用程序设计的缺陷和数据库查询的滥用反倒是最最常见的性能问题。需要注意的是，大多数情况下，虽然性能瓶颈的起因是程序性能差或者是内存不足或者是磁盘瓶颈等各种原因，但最终表现出的结果就是CPU耗尽，系统负载极高，响应迟缓，甚至暂时失去响应，因此我们观察服务器状况时，最先看的就是系统负载和CPU空闲度。当你阅读完了这遍文档以后就会有一个对系统分析的思路。 2、性能分析的目的 2.1找出系统性能瓶颈 1.硬件瓶颈 2.软件瓶颈 2.2提供性能优化方案 1.升级硬件 2.改进系统结构 达到合理的硬件和软件配置，使系统资源使用达到平衡。但遗憾的是解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待 CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销） 3、性能相关的各个环节 3.1 硬件资源 3.1.1、CPU ⒈ 是否使用SMP。 ⒉ 单颗CPU的性能对依赖CPU的某些应用的影响很严重，比如数据库的查询处理。 3.1.2、内存
MS_SQL_Server_数据库性能优化方法总结
1.列出数据库服务器、Web服务器的基本的硬件配置，如CPU、内存等。 2.检查数据库服务器是否真正启用了AWE内存。 (1) 启用AWE：数据库服务器检查C:\boot.ini文件,需要配置"/PAE"(*重启电脑才能生效),如下： [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /PAE (2) 开启sql server 服务用户的，内存中锁定页面权限 (*重启电脑才能生效)在“服务管理”中查看 SQL SERVER 服务登录账户，默认是本地系统帐户（System）。然后在运行 gpedit.msc ，选择计算机配置->windows 设置->安全设置->本地策略->用户权限分配->内存中锁定页面。添加SQL SERVER服务的登录用户到里面去。 (3)启用数据库AWE内存，以服务器8G内存为例，一般设置如下，最小2G，最大6G(重启SQL SERVER服务即可)： (4)跟踪数据库性能“Total Server Memory ”的使用情况，看看数据库真正使 用的内存，越接近为数据库分配的最大内存越好。 或使用如下语句，查询数据库的内存使用情况： use master go select * from sysperfinfo where counter_name like '%Total Server Memory(KB)%' go 3.Web服务器监控项：