我把sql优化，分为四层：

1. 业务上的优化

2. 代码层的优化

3. sql层面的优化（包含索引优化）

4. 硬件层优化（硬件层的优化，其实都是运维啊，所以硬件层的优化，你可以直接说别人做的，说一下就ok。）

个人优化流程

假设表里面十多亿的数据，这里分库分表，集群了。索引什么的已经优化到最好了。

vip1级可以看多少数据，vip5级可以看全部的数据。

查数据，其实肯定都是分页查，分页的下面是有一个count。

不用mysql了，我直接上es。这是一个办法。

可以一页一页的来缓存。也是一个办法。

首先就是说可以跟产品经理交流，比如默认vip5级的用户上来访问，直接让他默认就带一些查询条件。这时候，他的查询就会筛选过滤。这样再查数据的话，就会比较的快了。

其次，因为这里count就必须给他改了。count单独给他写出来。

那问题又来了，count 还是十几亿的数据，还是非常非常慢。

那这里，只能在代码层面进行优化了，包括数据库上的设计层面。

当时是单独建立了一张表，然后这个表存储了数据表名称，主键，count数。

如果是加数据的话这里用异步的往这个单独的表去+1数据。然后就是查询的时候，count值直接查询这个表里面的count这个列就能把数据查询出来了。count的问题就解决了。

再其次就是sql层面优化了，最简单最直接的，其实就是创建联合索引。减少回表，也就是说所有数据直接在这一个索引树下就查询出来了。

连表查询，连表查的比较多了，比较慢了，这时候索引怎么建其实用处都不太明显了，优化。

可以代码层面做优化，可以写两个sql，查询出来数据，做拼装。

根据日志去查询慢查询的sql。

查询出来了，可以结合代码。根据实际情况去，修改。

个人优化见解

1. 使用缓存优化查询(进行多次相同的查询，结果就会放入缓存中，后续再进行同样的查询，就直接从缓存中提取，不会到表中提取。也可以在发售时做缓存预热。)

select name from table tb where date_user >= CURDATE()(返回当前时间);(因为的不是因定的值，所以缓存会失效。NOW()也一样)

select name from table tb where date_user >= '2020-10-10';

2. explain检测SQL查询

用法:(explain select)

3. 给搜索字段建立索引 where 后面的字段建立索引（大数据的清况下，查询的数据大于当前查询表的一半时，不易使用索引。原因：MySQL内部优化器在进行优化（先走非集聚索引在走集聚索引）（集聚索引和非集聚索引的查询原理））

4.索引会失效的情况

模糊查询。使用like关键宇的时候，要是以%开头，那索引就会失效。

数据类型。如果数据类型错误了，那索引也会失效。

函数。对索引的字段使用内部函数，那索引也会失效。这种情況呢应该建立基于函数的索引。

Null。索引不存储空值，如果不限制索引列是not Null，数据库会认为索引列有可能存在空值，所以也不会按照索引进行计算。

运算。对索引列进行加、减、乘、除等运算，会导致索引失效。

最左原则。在复合索引中，索引列的顺序非常重要，如果不是按照索引列最左列，开始进行查找，则无法使用索引。

全表扫描。如果数据库预计使用全表扫描比使用索引更快，那就不会使用索引。

5. limit 1（明确只有一行数据的时候）

6. 永久连接。（在一些极端的环境中，Apache会发出http请求，创建子进程去请求数据库）

7.选择正确的数据库引擎（myISAM适合大数据量的查询，对插入操作并不友好（在插入时进行表锁，这时查询是无效的，只有完成插入操作才能查询）。innoDB插入操作比较友好，对查询操作并不友好（支持SID、索引、行锁））

8.在进行大量delete、inscrt拆分，会进行锁表(可能会出现待机的问题，使用limit来分批操作。)

9.数据类型，尽量使用小的。（节省存储空间和查询速度）

10.固定字段长度。（trim去一下空格）（减少计划偏移量）

11.尽量不要给null，可以给' '。

12.明确的固定的字段上使用cnum(性别、国家、市)，不要使用varchar。

13.id主键每张表都要建立，对集群、分区

14.避免使用select * (查询越多，速度就越慢，数据越多对网络的传输也会负载过重)。

15.减少一些函数的使用如：rand() 计算是在cpu上面进行的，oder by rand

16.连接两表的时候，join时尽量保持两个字段的类型要一致。

17.垂直分割，将表按列的形式分割成表。（经常使用的优化手段）