データファイル：
frmファイルはテーブル構造を保存し、mydファイルはテーブルデータを保存し、myiファイルはテーブルインデックスを保存します。
データベースエンジンコマンドの表示show engines：;
MyISAMテーブルとの比較
MyISAM不支持主外键，InnoDB支持主外键のInnoDB：
MyISAM不支持事物，InnoDB支持事物;
MyISAM使用的是表锁，InnoDB使用的是行级锁;
MyISAM只缓存索引，不缓存数据，InoDB即缓存索引又缓存数据;
MyISAM的表空间小，InnoDB的表空间大;;
MyISAM的关注点在性能，InnoDB的关注点在事物;
SQL分析：
制限による順序を選択してグループ化する結合時から
インデックス：
MySQLのデフォルトのインデックス構造はB +ツリーです。
長所：提高了数据检索的效率，降低了数据库的IO成本 ;
短所：降低了MySQL的更新速度，既要维护数据表信息，又要维护索引信息 ;
インデックスタイプ：
主キーインデックス：
ユニークインデックス：索引的列必须唯一，允许有空值;
通常のインデックス：单值索引（一个索引只包含一个列，一个表可以有多个单值索引）、复合索引（一个索引包含多个列）;
フルテキスト对文本的内容进行分词，进行搜索インデックス：;
インデックス構造：
B-ツリー：平衡多路搜索树，它的每个叶子都可以拥有大于等个2个子节点，所以叫多路，是为了降低高度，查询性能提高;
B +ツリー：在B-Tree的基础上改造，它的数据都存在叶子节点，同时叶子节点还加了指针形成链表;
赤黒木（平衡二分木）の代わりにB +ツリーを使用する理由
因为B+Tree的高度远远小于红黑树。索引文件本身也很大，不可能一次性加载进内存;
索引的结构要尽可能的减少查找过程中磁盘IO的存取次数;
InnoDB
データストレージを編成するための主キーインデックスであり、特定のデータはリーフノードに格納され、
補助インデックスのリーフノードは、メインファイルを指す主キーキーワードを保存します。
比如第1块磁盘块里面有P1指针、数据项17、P2指针、数据项35、P3指针， 那么P1指针指向的是小于数据项17的磁盘块2，里面又分为P1指针、数据项8、P2指针、数据项12、P3指针。 那么p2指针指向的是在数据项17和数据项35之间的磁盘块3，里面又分为P1指针、数据项26、P2指针、数据项30、P3指针。 以此类推下去。
どのような状況でインデックスを作成する必要がありますか？
1 主键自动创建唯一索引。;
2 频繁使用查询的条件。;
3 表关联的字段。;
4 频繁更新的字段不适合建立索引。;
どのような状況でインデックスを作成しないのですか？
1 表记录太少。;
2 经常增删改的表。;
説明：
実行プランを表示して、クエリステートメントまたはテーブル構造のパフォーマンスのボトルネックを分析します。
次のフィールドがあり
、上記のIDが：select 查询序列号，Id越大优先级越高，越先别执行;
の查询使用了何种类型，最好到最差依次是system>const>eq_ref>ref>range>index>all種類：;
possiable_key：显示可能应用到这张表的索引 ;
キー：实际使用到的索引 ;
行が：大致估算找到所需要的记录需要查找的行数 ;
インデックスの失敗を回避しますか？
1. 全值匹配
2. 最佳左前缀法则，查询从索引最左前列开始，且不跳过中间的列
3. 不在索引上做任何操作，比如计算、函数
4. 不能使用索引中范围右边的列
5. ！=会导致索引失效
6. is null 和 is not null 无法使用索引
7. like使用通配符开头索引失效
8。少用or，用它连接时索引失效
クエリログが遅い？
これは、mysqlによって提供される一種のログレコードであり、応答時間がしきい値を超えるステートメントを記録します。デフォルトのlong_query_time = 10;は、包括的な分析のためにExplainと組み合わされます。
かどうかをオープンに確認してください：show variables like '%slow_query_log%';
オープン：set global slow_query_log = 1;
現在のしきい値を表示しますshow variables like '%long_query_time%'。
しきい値を設定しますset global long_query_time = 3。
MySQLには、分析用のmsyqldumpslowツールが用意されています。
プロフィールを表示しますか？
現在のセッションでのSQLステートメント実行のリソース消費を分析するツール（デフォルトでは閉じられており、15回の実行結果を保持します）
かどうかをオープンに確認してください：show variables like 'profiling';
オープン：set profiling = on;
結果表示：show profiles;
診断show profile cpu,block io for query 查询编号SQLを：;
マスタースレーブレプリケーション？
master将改变记录到二进制日志（binary log);slave将master的二进制日志拷贝到它的中继日志;salve重做中继日志中的事件，将改变应用到自己的数据库，mysql的复制是异步且串行化的
ロックの分類？
データ操作のタイプ：
1.読み取りロック：共享锁，不会阻塞读，但会阻塞写
2.書き込みロック：排他锁，当前写操作没有完成，它会阻断其他写锁和读锁
粒子サイズ分析から：
1.テーブル・偏向于MyISAM存储引擎，开销小，加锁快，无死锁，锁定力度大，并发度低ロック：。
2.行ロック：偏向InnoDB存储引擎，开销大，加锁慢，有死锁，锁定力度小，并发度高;
锁定一行：for update
例：更新するid = xxxのテーブルから列を選択
最適化の提案？
1 尽可能让所有的数据检索都通过索引完成，避免行锁升级为表锁。;
2 尽可能较少检索条件，避免间隙锁。（set b= xxx where a>1 and a <5）。;
3 尽可能控制事物大小，减少锁定资源量和时间长度。;
データベースのステータスを照会して、デッドロックがあるかどうかを確認しますshow Engine InnoDB status。
