1.where子句的优化

不需要在牺牲可读性的情况下重写sql，因为mysql会自动进行类似的优化。

1.去掉无用的括号

((a AND b) AND c OR (((a AND b) AND (c AND d))))
-> (a AND b AND c) OR (a AND b AND c AND d)

2.恒定折叠

(a<b AND b=c) AND a=5
-> b>5 AND b=c AND a=5

3.恒定条件去除

  (B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
-> B=5 OR B=6

4.走索引的常量表达式只会计算一次

5.对于没有where 条件的 单表 Count(*)直接检索Information_schema库中的统计信息（对 myisam 和 memory表）。

6.更早的察觉无效的常量表达式。mysql快速发现select语句中不可能成立的where条件并且返回no rows;

7.如果没有使用group by 或者聚合函数（count(),min().max()）,having子句会被合并到where 子句中。

8.为表连接中的每个表构造一个简洁的 WHERE 语句，以得到更快的 WHERE 计算值并且尽快跳过记录

9.查询中所有的常量表都会比其他表更早读取。一个常量表符合以下几个条件：

1空表或者只有一条记录。
2与在一个 UNIQUE 索引、或一个 PRIMARY KEY 的 WHERE 子句一起使用的表，这里所有的索引部分和常数表达式做比较并且索引部分被定义为 NOT NULL。

3以下的几个表都会被当成常量表：
SELECT * FROM t WHERE primary_key=1;
SELECT * FROM t1,t2
    WHERE t1.primary_key=1 AND t2.primary_key=t1.id;

10.MySQL会进各种可能找到表连接最好的连接方法。 如果在 ORDER BY 和 GROUP BY 子句中的所有字段都来自同一个表的话，那么在连接时这个表就会优先处理

11.如果有 ORDER BY 子句和一个不同的 GROUP BY 子句，或者如果 ORDER BY 或 GROUP BY 中的字段都来自其他的表而非连接顺序中的第一个表的话，就会创建一个临时表了。

12.如果使用 SQL_SMALL_RESULT，MySQL就会使用内存临时表了。

https://blog.csdn.net/yunhua_lee/article/details/12064477

13.所有的表索引都会查询，最好的情况就是所有的索引都会被用到，除非优化程序认为全表扫描的效率更高。同时，数据表扫描是基于判断最好的索引范围超过数据表的30%。 现在，优化程序复杂多了，它基于对一些附加因素的估计，例如表大小，记录总数，I/O块大小，因此就不能根据一个固定的百分比来决定是选择使用索引还是直接扫描数据表

14.在某些情况下，MySQL可以直接从索引中取得记录而无需查询数据文件。如果所有在索引中使用的字段都是数字类型的话，只需要用索引树就能完成查询

15.每条记录输出之前，那些没有匹配 HAVING 子句的就会被跳过

16.以下查询的查询速度很快：

SELECT COUNT(*) FROM tbl_name;

SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;

SELECT MAX(key_part2) FROM tbl_name
  WHERE key_part1=constant;

SELECT ... FROM tbl_name
  ORDER BY key_part1,key_part2,... LIMIT 10;

SELECT ... FROM tbl_name
  ORDER BY key_part1 DESC, key_part2 DESC, ... LIMIT 10;

17.MySQL仅使用索引树解析以下查询，假设索引列是数字

SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;

SELECT COUNT(*) FROM tbl_name
  WHERE key_part1=val1 AND key_part2=val2;

SELECT key_part2 FROM tbl_name GROUP BY key_part1;

18.以下几个查询使用索引来取得经过顺序排序后的记录而无需经过独立的排序步骤

SELECT ... FROM tbl_name
  ORDER BY key_part1,key_part2,... ;

SELECT ... FROM tbl_name
  ORDER BY key_part1 DESC, key_part2 DESC, ... ;

问题：（没有解决，只记录当前自己的理解，后继继续补充）

现在有表auditing，

有以下索引

mysql> show index from auditing;
+----------+------------+----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table    | Non_unique | Key_name             | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+----------+------------+----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| auditing |          0 | PRIMARY              |            1 | id          | A         |     1871961 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_auditing_id      |            1 | auditing_id | A         |     1872265 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_org_id           |            1 | org_id      | A         |         519 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_customerId_orgId |            1 | customer_id | A         |      516063 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_customerId_orgId |            2 | org_id      | A         |     1872265 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_take_emp_id      |            1 | take_emp_id | A         |        2431 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_flow_id          |            1 | flow_id     | A         |      801822 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_name             |            1 | name        | A         |      338114 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_mobile           |            1 | mobile      | A         |      465760 |     NULL | NULL   |      | BTREE      |         |               |
| auditing |          1 | idx_identity_id      |            1 | identity_id | A         |      538624 |     NULL | NULL   |      | BTREE      |         |               |
+----------+------------+----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
10 rows in set (0.01 sec)

mysql> select customer_id,org_id from auditing limit 10;
+-------------+---------------------+
| customer_id | org_id              |
+-------------+---------------------+
| 1043109     | 4740105886238771577 |
| 1043109     | 745153438386488147  |
| 1043109     | 784871116307838216  |
| 1043109     | 791642077607667333  |
| 10691501    | 764594140097335471  |
| 10691501    | 769786088135692308  |
| 10691501    | 784871116307838216  |
| 10691501    | 784871116307838216  |
| 10691501    | 784871116307840827  |
| 10691501    | 789581320451461747  |
+-------------+---------------------+

发现

customer_id字段是表中不存在的值，执行计划走的是idx_customerId_orgId索引，而org_id字段是表中不存在的值得时候，走的是idx_org_id索引，两个字段都是表中存在的值得时候执行计划选择

idx_customerId_orgId索引，这是因为sql优化器会做成本分析，

mysql> explain select count(*) from auditing where customer_id='106' and org_id='784871116307838216';
+----+-------------+----------+------------+------+---------------------------------+----------------------+---------+-------------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys                   | key                  | key_len | ref         |rows | filtered | Extra       |
+----+-------------+----------+------------+------+---------------------------------+----------------------+---------+-------------+------+----------+-------------+
|  1 | SIMPLE      | auditing | NULL       | ref  | idx_org_id,idx_customerId_orgId | idx_customerId_orgId | 196     | const,const |   1 |   100.00 | Using index |
+----+-------------+----------+------------+------+---------------------------------+----------------------+---------+-------------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

mysql> explain select count(*) from auditing where customer_id='10691501' and org_id='7848711163';
+----+-------------+----------+------------+------+---------------------------------+------------+---------+-------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys                   | key        | key_len | ref   | rows | filtered| Extra       |
+----+-------------+----------+------------+------+---------------------------------+------------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | auditing | NULL       | ref  | idx_org_id,idx_customerId_orgId | idx_org_id | 98      | const |    1 |    10.00| Using where |
+----+-------------+----------+------------+------+---------------------------------+------------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

mysql> explain select count(*) from auditing where customer_id='10691501' and org_id='784871116307838216';
+----+-------------+----------+------------+------+---------------------------------+----------------------+---------+-------------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys                   | key                  | key_len | ref         |rows | filtered | Extra       |
+----+-------------+----------+------------+------+---------------------------------+----------------------+---------+-------------+------+----------+-------------+
|  1 | SIMPLE      | auditing | NULL       | ref  | idx_org_id,idx_customerId_orgId | idx_customerId_orgId | 196     | const,const |   2 |   100.00 | Using index |
+----+-------------+----------+------------+------+---------------------------------+----------------------+---------+-------------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)