ここで遭遇した仕事99％のSQLの最適化はあなたに解決策を与えることができます（III）

-- 示例表
CREATE TABLE `employees` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',
  `age` int(20) NOT NULL DEFAULT '0' COMMENT '年龄',
  `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',
  `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '入职时间',
  PRIMARY KEY (`id`),
  KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE,
  KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=136326 DEFAULT CHARSET=utf8 COMMENT='员工表'

--创建100000条记录
drop procedure if EXISTS insert_emp;
delimiter ;;
create procedure insert_emp()
BEGIN
    declare i int;
    set i=1;
    while(i < 100000)DO
        INSERT INTO employees(name,age,position) values(CONCAT('xiaoqiang',i),i,'coder');
        SET i=i+1;
    end WHILE;
end;;
delimiter ;
call insert_emp();

インクリメントと連続主ソートキーページングクエリ

select * from employees LIMIT 9999 ,5;

5記録から削除行が従業員のテーブルから10000行を開始表します。一見だけで5つのレコードを照会し、このSQLは最初の10005件のレコードを読み、その後、最初の10,000レコードを破棄し、次にあなたが5の背後に必要なデータを読み、実際にあります。第1ソートキーによって表されることで別々のための添加なし。
したがって、比較により大きなテーブルの後にデータを照会するために、効率が非常に低いです。
：自己増力主キーと連続しているので、次のように始まる最初の5行クエリ10001からマスター鍵データに応じて書き換えることができます。

select * from  employees WHERE id > 9999 limit 5;

あなたは2つのSQL実行計画、明らかにSQL書き換えてしまったインデックス、および大幅に減少し、スキャンラインの数を見ることができ、効率が高くなります。テーブル内の一部のレコードが削除されている可能性の後、主キー欠員が、一貫性のない結果につながるしかし、多くのシーンで、この書き換えられたSQLは、実用的ではありません。
元のSQL SQLと最適化後に記録し、次のテストを削除します。

select * from employees LIMIT 9999 ,5;

 select * from employees where id> 9999 limit 5;

主キーが連続していない場合、SQL二つの結果は、上記の方法を使用することができない、したがって、同一ではありません。
また、非SQL主キーフィールドによって元の順序であるように、上記の方法に従ってSQL一貫性のない結果を書き換えられます。だから、これは次の2つの条件を満たすように書き直さ：

そして継続的に主キーをインクリメント
結果は、マスターキーに基づいてソートされ

クエリをページング非プライマリソートキーフィールド

select * from employees order by name limit 9000, 5;

 explain select * from employees order by name limit 9000, 5;

キーフィールドの値に対応するnullで、インデックス名フィールドを使用して見つかりません。索引全体をスキャンし、インデックスのない行を見つけ、インデックス・ツリーがより便利である可能性があるので、インデックスを使用して放棄し、全表スキャンのコストよりも多くの費用がかかるインデックスオプティマイザ。
キーの最適化は、次のとおりです。あなたが主キー、主キーに基づいて求め、対応するレコードを識別するために、ソートやページング操作を行うことができますので、できるだけご注文時のフィールドが返さましょう。
次の変更の下で：

select * from employees as e inner join(select id from employees order by name limit 9000,5) as ed on e.id=ed.id;

私たちは、実行時間が一般よりも低減され、元のSQL結果との結果が同じであることがわかり、その後、次の実行計画を比較することができます：

元のSQLは、filesortレコードのソート使用して、およびSQLインデックスの順序付けを使用して最適化されました。

そして、最適化に存在します

原理：小さなテーブル駆動大型テーブル、すなわち、大規模なテーブルを設定する小テーブル駆動データセットのデータ
に：データセットが原因が存在するので、データセットテーブルAよりも小さい表B

select * from A where id in(select id from B)
等价于
 for(select id from B){
     select * from A where A.id=B.id
 }

存在する：表データがデータテーブルよりも少ないセットBを設定すると、よりもexitsts
クエリデータAの前部には、Bは、クエリを決定する（trueまたはfalse）、検証結果に応じて、サブクエリ検証条件に構成されていますデータは保持されているかどうか。

select * from A  exists(select 1 from B where A.id=B.id)

等价于
for(select * from A){
    select * from B where A.id=B.id
}

COUNT（*）クエリの最適化

explain select count(1) from employees;
explain select count(id) from employees;
explain select count(name) from employees;
explain select count(*) from employees;

ほぼ4 SQLの実行計画と同じように、関節のインデックスを使用して（名前を）数え、統計の主な違いは、フィールドに基づいて動作磁界データラインnull値をカウントされません。
他のカウント動作に加えて、二次索引より少ないデータストレージ、より高い検索性能ので、代わりにセカンダリインデックス主キーインデックスに使用される（名前）を数えます。

私は公共の数を懸念していませんよ？

以下のように受信することができる[社会的関心Xiaoqiang高度道路の二次元コードの数を終了スイープ。
教材：1Tビデオチュートリアル：フロントとリアエンドはJavaweb教育ビデオ、機械学習/ AI教育ビデオ、Linuxシステムのチュートリアル動画、IELTSのビデオチュートリアルをカバー。
以上の100冊：含むC / C ++やJava、Pythonプログラミング言語は3冊、LeetCodeの説明Daquanのを見なければなりません。
ソフトウェアツール：ほとんどのソフトウェアは、ほとんどあなたが道をプログラミングに使用する場合があります含み;
プロジェクトソース：20件のJavaWebソースプロジェクト。