まず、どのような影響データベースクエリの速度
1.1のデータベースクエリの速度に影響を与える4つの要因
1.2リスク分析
QPS：
Queries Per Second
「毎秒クエリが」毎秒クエリの適切な数の可能なサーバであることを意味し、処理フローのどのくらいの指定された時間内に特定のクエリ・サーバの尺度です。
TPS：ある
TransactionsPerSecond
トランザクション/秒の数である略語、。これは、測定ソフトウェアテスト結果の単位です。クライアントは、使用時と完了したトランザクションの数を計算するために、サーバの応答を受信した後、送信開始タイミング、終了タイミングを要求します。
ヒント：最高の主要なイベントの前にそのような計画をキャンセルし、メインのライブラリにデータベースをバックアップしません。
- 非効率性
sql：超高QPSとTPS。 - 同時の多数：データ接続が充填されている（
max_connectionデフォルトでは100、一般的なセット多数の接続）。
並行性：同じデータベースサーバ処理時間の要求数 - 超高
CPU用法：CPU資源の枯渇のダウンタイム。 -
ディスク
IO：ディスクIO性能の急激な低下は、スケジュールされたタスクのディスク性能の多くを消費します。解決策：より高速なディスクデバイスは、スケジュールされたタスク、正常なディスクのメンテナンスを調整します。
1.3 NIC交通：どのような状況を回避するためにデータベースに接続できません
- サーバーの数から（サーバログからのマスターサーバーからコピーされた）の増減
- （キャッシュ・ミスは、フロントエンドの多数を避ける）キャッシュの分類
- 使用しないでください
select *クエリを - 独立したビジネスネットワークとサーバネットワーク
1.4は（表に大きな問題をもたらします重要）
1.4.1大きな台を備えています
- 千万単一テーブルの上に巨大な行数、
- 以上の表の巨大なデータファイル
10AG
1.4.2ハザード大きなテーブル
1.スロークエリ：するために必要なデータをフィルタリングすることは困難である短時間で
のクエリワード差別を下げるには- >データの一部がディスクを大量に生成されますテーブルに大量のデータをフィルタリングするにはio >ディスク効率を低下させます-
2. DDL影響：
インデックス作成には長い時間がかかります。
MySQL -v<5.5インデックスは、テーブルをロックしますMySQL -v>=5.5索引付けは、（マスタ・スレーブ遅延をもたらすであろうmysql最初の実行のグループに、索引付け、および、ライブラリ上で実行されます）
遅延から長い主な原因（480秒の「遅れ「）：長い時間がテーブルロックテーブルの構造を変更する必要があり
データベースに大きなテーブルに対処する方法1.4.3
複数の小さなテーブルに大きなテーブルにサブライブラリーサブテーブル
難易度：
- 部品表の主キーを選択します
- ポイントテーブルのパーティション間でクエリと統計データ
によって引き起こさ1.5大きなトランザクションの問題（重要）
1.5.1トランザクションとは何ですか
1.5.2業務のACID性質
1、アトミック（
atomicity
）：すべてのロールバックに失敗、成功します。銀行預金。
図2に示すように、整合性（一貫性）：銀行振込の総量は変わりません。
図3に示すように、分離（単離）：
絶縁定格：
- 非コミット読み取り（
READ UNCOMMITEDそれぞれ他の二つのトランザクションの間に見られる）ダーティ・リード、。 - （、READ COMMITTED
READ COMMITED分離に沿った基本的な概念を）、取引が行われ、他のものはあること、他のトランザクションが提出されたデータを得ることができ、表示されているトランザクションに提出されました。 - 反復可能読み取り（
REPEATABLE READ）InnoDB的默认隔离等级。トランザクションは、実行見えない他のすべてのトランザクションが、何度も読んだとき、結果は同じです！ - Serializableを（
SERIALIZABLEデータの各行には）ロックを読まれ、厳格なデータの一貫性と同時実行性が利用できない、ロック・タイムアウト、ロック依頼の多くの原因となります。
システムのトランザクション分離レベルのビュー：show variables like '%iso%';
新しいトランザクションを開きますbegin。
トランザクションをコミット：commit;
分離レベルのものを変更しますset session tx_isolation='read-committed'。
4、持続性（
DURABILITY
）：永続データベースの観点から、ディスクが損傷しません
redo logトランザクションの一貫性と耐久性、更新を確保するためのメカニズム
1.5.3大規模なトランザクション
長い時間、より多くのデータトランザクション処理のために実行します。
リスク：あまりにも多くのデータ、ロールバックに長い時間、長い実行時間をロックします。
- 外に渋滞やロックを引き起こして、あまりにも多くのデータをロックします。
- 時間が長い時間をロールバックするために必要な、データがまだロックになります。
- プライマリサーバがすべて終了ログに書き込ま実行するときにのみ、遅延が発生、同期するために、サーバーから起動しますので、実行時間ならば、それは、マスターからの遅延が発生します。
ソリューション：
- バッチで処理されるように処理し、あまりにも多くのデータを避けてください。
- 不要の除去
SELECT操作、トランザクションが書き込みにのみ必要であることを保証します。
第二には、何（のMySQLのパフォーマンスに影響を与えます非常重要）
パフォーマンスに影響を与える2.1いくつかの側面
- サーバーハードウェア。
- サーバ・システム（システムパラメータの最適化）。
- ストレージエンジン。
MyISAM：、テーブルレベルのロックをトランザクションをサポートしていません。InnoDB：サポートサービス、サポート行レベルのロック、トランザクションACID。 - データベース構成パラメーター。
数据库结构设计和SQL语句。（重点优化）
2.2 MySQLのアーキテクチャ
- >サービスレイヤー - >ストレージエンジンクライアント：3層に分かれ
MySQL市插件式的存储引擎は非常に多くのためのストレージエンジンの、。長いMySQLのストレージエンジンの遵守を達成するためのインタフェースのように、自分自身のストレージエンジンを開発することができます！- すべてにわたってストレージエンジンの機能は、サービス層に実装されています。
- MySQLのストレージエンジンではなく、ライブラリのために、テーブルのためです。これは、データベース内の異なるストレージエンジンを使用することができます。しかし、これはお勧めしません。
2.3 InnoDBストレージエンジン
MySQL5.5そして、デフォルトのストレージエンジンのバージョンの後：InnoDB。
表2.3.1 InnoDBのデータ・ストレージ・スペース。
show variables like 'innodb_file_per_table
如果innodb_file_per_table 为 ON 将建立独立的表空间，文件为tablename.ibd；
如果innodb_file_per_table 为 OFF 将数据存储到系统的共享表空间，文件为ibdataX（X为从1开始的整数）；
.frm ：是服务器层面产生的文件，类似服务器层的数据字典，记录表结构。
2.3.2 (MySQL5.5默认)系统表空间与(MySQL5.6及以后默认)独立表空间
1.1 系统表空间无法简单的收缩文件大小，造成空间浪费，并会产生大量的磁盘碎片。
1.2 独立表空间可以通过optimeze table 收缩系统文件，不需要重启服务器也不会影响对表的正常访问。
2.1 如果对多个表进行刷新时，实际上是顺序进行的，会产生IO瓶颈。
2.2 独立表空间可以同时向多个文件刷新数据。
强烈建立对Innodb 使用独立表空间，优化什么的更方便，可控。
2.3.3 系统表空间的表转移到独立表空间中的方法
1、使用mysqldump 导出所有数据库数据（存储过程、触发器、计划任务一起都要导出 ）可以在从服务器上操作。
2、停止MYsql 服务器，修改参数（my.cnf加入innodb_file_per_table），并删除Inoodb相关文件（可以重建Data目录）。
3、重启MYSQL，并重建Innodb系统表空间。
4、 重新导入数据。
或者 Alter table 同样可以的转移，但是无法回收系统表空间中占用的空间。
2.4 InnoDB存储引擎的特性
2.4.1 特性一：事务性存储引擎及两个特殊日志类型：Redo Log 和 Undo Log
Innodb是一种事务性存储引擎。- 完全支持事务的
ACID特性。 - 支持事务所需要的两个特殊日志类型：
Redo Log和Undo Log
Redo Log：实现事务的持久性(已提交的事务)。
Undo Log：未提交的事务，独立于表空间，需要随机访问，可以存储在高性能io设备上。
Undo日志记录某数据被修改前的值，可以用来在事务失败时进行rollback；Redo日志记录某数据块被修改后的值，可以用来恢复未写入data file的已成功事务更新的数据。
2.4.2 特性二：支持行级锁
- InnoDB支持行级锁。
- 行级锁可以最大程度地支持并发。
- 行级锁是由存储引擎层实现的。
2.5 什么是锁
2.5.1 锁
2.5.2 锁类型
2.5.3 锁的粒度
MySQL的事务支持不是绑定在MySQL服务器本身，而是与存储引擎相关
将table_name加表级锁命令：lock table table_name write; 写锁会阻塞其它用户对该表的‘读写’操作，直到写锁被释放：unlock tables；
- 锁的开销越大，粒度越小，并发度越高。
- 表级锁通常是在服务器层实现的。
- 行级锁是存储引擎层实现的。innodb的锁机制，服务器层是不知道的
2.5.4 阻塞和死锁
（1）阻塞是由于资源不足引起的排队等待现象。
（2）死锁是由于两个对象在拥有一份资源的情况下申请另一份资源，而另一份资源恰好又是这两对象正持有的，导致两对象无法完成操作，且所持资源无法释放。
2.6 如何选择正确的存储引擎
参考条件：
- 事务
- 备份(
Innobd免费在线备份) - 崩溃恢复
- 存储引擎的特有特性
总结:Innodb大法好。
注意:尽量别使用混合存储引擎，比如回滚会出问题在线热备问题。
2.7 配置参数
2.7.1 内存配置相关参数
确定可以使用的内存上限。
内存的使用上限不能超过物理内存，否则容易造成内存溢出；（对于32位操作系统，MySQL只能试用3G以下的内存。）
MySQLは決定された
各接続のための
单独
メモリ使用量。
sort_buffer_size #定义了每个线程排序缓存区的大小，MySQL在有查询、需要做排序操作时才会为每个缓冲区分配内存（直接分配该参数的全部内存）；
join_buffer_size #定义了每个线程所使用的连接缓冲区的大小，如果一个查询关联了多张表，MySQL会为每张表分配一个连接缓冲，导致一个查询产生了多个连接缓冲；
read_buffer_size #定义了当对一张MyISAM进行全表扫描时所分配读缓冲池大小，MySQL有查询需要时会为其分配内存，其必须是4k的倍数；
read_rnd_buffer_size #索引缓冲区大小，MySQL有查询需要时会为其分配内存，只会分配需要的大小。 注意：その後、100接続、必要×100がある場合は、これらの4つのパラメータが、スレッドに割り当てられています。
MySQLのデータベースインスタンス：①MySQLである
单进程多线程こと、（およびOracleは、マルチプロセスである）MySQL場合、プロセス、システム上のサービス処理性能です。②MySQL例は、例えば、データベースファイルの実際の動作のために、スレッドとメモリから構成されています。
一般的に、1つまたは複数のデータベースの動作例、クラスタ化され動作する1つまたは複数のデータベースの複数のインスタンス。
バッファプールのためにメモリを割り当てる方法：
Innodb_buffer_pool_size InnoDBはリフレッシュにバッファプールからの際に汚れたページを閉じたので、より多くの時間が必要であること、その性能は非常に重要であり、十分な大きさが、あまりにも大きくなければなりません、InnoDBが使用するバッファプールのサイズを定義しますディスク;
总内存-（每个线程所需要的内存*连接数）-系统保留内存
key_buffer_sizeデータがキャッシュに格納されたオペレーティングシステム、オペレーティングシステム用に予約される複数のメモリ空間に依存しているので、使用されるバッファプールのMyISAMのサイズを定義します。
select sum(index_length) from information_schema.talbes where engine='myisam'注：システムは、MySQLのテーブルはまだMyISAMテーブルで使用しているため、だけでなく、MyISAMのためのすべての開発テーブルのInnoDBテーブルの使用は、メモリを予約した場合でも。
max_connections コントロール2000一般に、より大きな最大接続数を、可能にします。
データの整合性を確保するために、外部キー制約を使用しないでください。
2.8パフォーマンスの最適化のため
上から下へ：
