アプリケーションの最適化
1コネクションプーリングを使用して
私たちは頻繁に近い接続を作成するため、データベースにアクセスするために、接続のコストの設立は、比較的高価であり、それはより多くのリソースを大量に消費され、我々はパフォーマンスのアクセスを改善するために、データベース接続プールを確立する必要があります。
2 MySQLのアクセスを減らします
2.1繰り返しデータ検索を避けるために
アプリケーションのコードを書くときには、データベースへの論理アクセスを整理できるようにする必要があります。接続の結果が得られることができ、それは役に立たないデータベースの繰り返しの要求を低減することができる、2を接続していません。
たとえば、次のようにidと名前のフィールドが取得書籍に必要な、クエリは次のとおりです。
select id , name from tb_book;
その後、本のビジネスロジックの状態で情報を入手する必要がある次のように、クエリは次のとおりです。
select id , status from tb_book;
この方法では、データベースに2つの要求を提出する必要があり、データベースには、2つのクエリを実行する必要があります。実際には、SQL文を使用して、望ましい結果を得ることができます。
select id, name , status from tb_book;
2.2増加キャッシュ層
アプリケーションでは、データベースの負荷を軽減する目的を達成するために、アプリケーション層でキャッシュを増やすことができます。バッファ層は、アプリケーションの要件をすることができ会うことができるデータベースを低減させる負担限り、達成することができ、達成するための多くの方法がありますが、多くがあります。
アプリケーション側に格納されたテキストにデータベースから抽出されたデータの一部であっても、またはフレーム（MyBatisの、休止状態）を使用して、バッファ/キャッシュを提供し、使用のRedisデータベースまたはキャッシュデータができます。
3ロードバランシング
ロードバランシングは、最適化の方法に使用される非常に一般的なアプリケーションであり、そのメカニズムは、最適な結果を達成するために、単一のサーバの負荷を軽減するために、バランシングアルゴリズムのいくつかの種類、異なるサーバ上に分散される負荷の一定量を使用することです。
MySQLのレプリケーションのシャントを使用して3.1クエリ
別々のリードの複製によるマスターからMySQLおよびそれによって圧力測定値を低減し、単一のサーバを書き込み、離れクエリノードから離れマスタノードCRUD操作を書き込みます。
3.2使用する分散データベースアーキテクチャ
大量のデータ、高負荷条件のためのデータベースアーキテクチャを分散、それは良いスケーラビリティと高可用性を持っています。複数のサーバー間でデータを分散することで、アクセス効率を向上させるために、複数のサーバー間で負荷分散を実現することができます。
MySQLのクエリキャッシュの最適化
1概要
オープンMySQLのクエリキャッシュまったく同じSQL文を実行するときに、サーバーは、キャッシュテーブルがクエリキャッシュには適していません修正より頻繁に失敗する前に、データが変更されたとき、その結果、キャッシュから直接読み込みます。
2動作フロー
- 客户端发送一条查询给服务器；
- 服务器先会检查查询缓存，如果命中了缓存，则立即返回存储在缓存中的结果。否则进入下一阶段；
- 服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划；
- MySQL根据优化器生成的执行计划，调用存储引擎的API来执行查询；
- 将结果返回给客户端。
3 查询缓存配置
-
查看当前的MySQL数据库是否支持查询缓存：
SHOW VARIABLES LIKE 'have_query_cache';
-
查看当前MySQL是否开启了查询缓存 ：
SHOW VARIABLES LIKE 'query_cache_type';
-
查看查询缓存的占用大小 ：
SHOW VARIABLES LIKE 'query_cache_size';
-
查看查询缓存的状态变量：
SHOW STATUS LIKE 'Qcache%';
各个变量的含义如下：
参数 含义 Qcache_free_blocks 查询缓存中的可用内存块数 Qcache_free_memory 查询缓存的可用内存量 Qcache_hits 查询缓存命中数 Qcache_inserts 添加到查询缓存的查询数 Qcache_lowmen_prunes 由于内存不足而从查询缓存中删除的查询数 Qcache_not_cached 非缓存查询的数量（由于 query_cache_type 设置而无法缓存或未缓存） Qcache_queries_in_cache 查询缓存中注册的查询数 Qcache_total_blocks 查询缓存中的块总数
4 开启查询缓存
MySQL的查询缓存默认是关闭的，需要手动配置参数 query_cache_type ， 来开启查询缓存。query_cache_type 该参数的可取值有三个 ：
| 值 | 含义 |
|---|---|
| OFF 或 0 | 查询缓存功能关闭 |
| ON 或 1 | 查询缓存功能打开，SELECT的结果符合缓存条件即会缓存，否则，不予缓存，显式指定 SQL_NO_CACHE，不予缓存 |
| DEMAND 或 2 | 查询缓存功能按需进行，显式指定 SQL_CACHE 的SELECT语句才会缓存；其它均不予缓存 |
在 /usr/my.cnf 配置中，增加以下配置 ：
配置完毕之后，重启服务既可生效 ；
然后就可以在命令行执行SQL语句进行验证 ，执行一条比较耗时的SQL语句，然后再多执行几次，查看后面几次的执行时间；获取通过查看查询缓存的缓存命中数，来判定是否走查询缓存。
5 查询缓存SELECT选项
可以在SELECT语句中指定两个与查询缓存相关的选项 ：
SQL_CACHE : 如果查询结果是可缓存的，并且 query_cache_type 系统变量的值为ON或 DEMAND ，则缓存查询结果 。
SQL_NO_CACHE : 服务器不使用查询缓存。它既不检查查询缓存，也不检查结果是否已缓存，也不缓存查询结果。
例子：
SELECT SQL_CACHE id, name FROM customer;
SELECT SQL_NO_CACHE id, name FROM customer;
6 查询缓存失效的情况
1） SQL 语句不一致的情况， 要想命中查询缓存，查询的SQL语句必须一致。
SQL1 : select count(*) from tb_item;
SQL2 : Select count(*) from tb_item;
2） 当查询语句中有一些不确定的时，则不会缓存。如 ： now() , current_date() , curdate() , curtime() , rand() , uuid() , user() , database() 。
SQL1 : select * from tb_item where updatetime < now() limit 1;
SQL2 : select user();
SQL3 : select database();
3） 不使用任何表查询语句。
select 'A';
4） 查询 mysql， information_schema或 performance_schema 数据库中的表时，不会走查询缓存。
select * from information_schema.engines;
5） 在存储的函数，触发器或事件的主体内执行的查询。
6） 如果表更改，则使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除。这包括使用MERGE映射到已更改表的表的查询。一个表可以被许多类型的语句，如被改变 INSERT， UPDATE， DELETE， TRUNCATE TABLE， ALTER TABLE， DROP TABLE，或 DROP DATABASE 。
Mysql内存管理及优化
1 内存优化原则
1） 将尽量多的内存分配给MySQL做缓存，但要给操作系统和其他程序预留足够内存。
2） MyISAM 存储引擎的数据文件读取依赖于操作系统自身的IO缓存，因此，如果有MyISAM表，就要预留更多的内存给操作系统做IO缓存。
3） 排序区、连接区等缓存是分配给每个数据库会话（session）专用的，其默认值的设置要根据最大连接数合理分配，如果设置太大，不但浪费资源，而且在并发连接较高时会导致物理内存耗尽。
2 MyISAM 内存优化
myisam存储引擎使用 key_buffer 缓存索引块，加速myisam索引的读写速度。对于myisam表的数据块，mysql没有特别的缓存机制，完全依赖于操作系统的IO缓存。
key_buffer_size
key_buffer_size决定MyISAM索引块缓存区的大小，直接影响到MyISAM表的存取效率。可以在MySQL参数文件中设置key_buffer_size的值，对于一般MyISAM数据库，建议至少将1/4可用内存分配给key_buffer_size。
在/usr/my.cnf 中做如下配置：
key_buffer_size=512M
read_buffer_size
如果需要经常顺序扫描myisam表，可以通过增大read_buffer_size的值来改善性能。但需要注意的是read_buffer_size是每个session独占的，如果默认值设置太大，就会造成内存浪费。
read_rnd_buffer_size
对于需要做排序的myisam表的查询，如带有order by子句的sql，适当增加 read_rnd_buffer_size 的值，可以改善此类的sql性能。但需要注意的是 read_rnd_buffer_size 是每个session独占的，如果默认值设置太大，就会造成内存浪费。
3 InnoDB 内存优化
innodb用一块内存区做IO缓存池，该缓存池不仅用来缓存innodb的索引块，而且也用来缓存innodb的数据块。
innodb_buffer_pool_size
该变量决定了 innodb 存储引擎表数据和索引数据的最大缓存区大小。在保证操作系统及其他程序有足够内存可用的情况下，innodb_buffer_pool_size 的值越大，缓存命中率越高，访问InnoDB表需要的磁盘I/O 就越少，性能也就越高。
innodb_buffer_pool_size=512M
innodb_log_buffer_size
决定了innodb重做日志缓存的大小，对于可能产生大量更新记录的大事务，增加innodb_log_buffer_size的大小，可以避免innodb在事务提交前就执行不必要的日志写入磁盘操作。
innodb_log_buffer_size=10M
Mysql并发参数调整
从实现上来说，MySQL Server 是多线程结构，包括后台线程和客户服务线程。多线程可以有效利用服务器资源，提高数据库的并发性能。在Mysql中，控制并发连接和线程的主要参数包括 max_connections、back_log、thread_cache_size、table_open_cahce。
1 max_connections
采用max_connections 控制允许连接到MySQL数据库的最大数量，默认值是 151。如果状态变量 connection_errors_max_connections 不为零，并且一直增长，则说明不断有连接请求因数据库连接数已达到允许最大值而失败，这是可以考虑增大max_connections 的值。
Mysql 最大可支持的连接数，取决于很多因素，包括给定操作系统平台的线程库的质量、内存大小、每个连接的负荷、CPU的处理速度，期望的响应时间等。在Linux 平台下，性能好的服务器，支持 500-1000 个连接不是难事，需要根据服务器性能进行评估设定。
2 back_log
back_log 参数控制MySQL监听TCP端口时设置的积压请求栈大小。如果MySql的连接数达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log，将不被授予连接资源，将会报错。5.6.6 版本之前默认值为 50 ， 之后的版本默认为 50 + （max_connections / 5）， 但最大不超过900。
如果需要数据库在较短的时间内处理大量连接请求， 可以考虑适当增大back_log 的值。
3 table_open_cache
このパラメータは、すべてのSQL文の実行スレッドに開閉可能なテーブルキャッシュの数を制御するために使用され、ときに、SQL文の実行、少なくとも1つのテーブルのキャッシュに各オープンのためのSQLの実行スレッド。このパラメータの値は、接続MAX_CONNECTIONSの最大数とセットのクエリの実行に関与する各接続テーブルに関連付けられている最大数に設定されるべきです。
MAX_CONNECTIONSは、NをX;
4 thread_cache_size
データベースへの接続を高速化するためには、MySQLは、パラメータthread_cache_sizeを介して顧客サービスのMySQLのスレッドキャッシュの数を制御することができ、再利用のための顧客サービススレッドの一定量をキャッシュします。
5 innodb_lock_wait_timeout
このパラメータは、トランザクションのInnoDBの行ロック待機時間を設定するために使用され、デフォルト値は、あなたが動的に必要に応じて設定することができ、50ミリ秒です。急速なビジネスのフィードバックシステムの必要性は、待ち時間が長い時間のために保留中のトランザクションを避けるために、小さな行ロックで調整することができ、バックグラウンドで実行されているバッチ処理プログラムのため、待ち時間がないようにするには、高まで行ロックすることができ大規模なロールバック操作が発生します。
