一、在结合业务需求时遇到的：
1、创建索引
尽量避免全表扫描，有预想的结合需求建立合适的索引。
1）最先应该想到的是在order by 和 where这两个关键字上建立适当的索引，比如经查使用planName这个字段进行查询计划，那应该在这个字段上建立索引
2）建立索引对于查询的好处是巨大的，但是过多的索引会导致update和insert的速度变慢，因为update和insert有可能会重构索引导致速度变慢，索引一般一张表的索引不宜建太多。
2、避免通过索引字段进行计算
在创表阶段需有预见性的创建索引。因为在where字句中，如果索引列是计算或者函数的一部分，DBMS的优化器将不会使用索引而使用全表查询,函数属于计算的一种,同时如果需要使用到in和exists的情况下，推荐使用EXISTS，因为in不走索引。
二、在开发过程中时遇到的：
1、开发过程中使用where字段的顺序。
DBMS一般采用自下而上的顺序解析where字句，根据这个原理表连接最好写在其他where条件之前，那些可以过滤掉最大数量记录。
2、能用一条SQL语句解决的尽量不要用多条语句，但是如果需要连表，尽量不要超过4张表。
在每次执行SQL的时候，都要建立网络连接、进行权限校验、进行SQL语句的查询优化、发送执行结果，这个过程是非常耗时的，因此应该尽量避免过多的执行SQL语句，能够压缩到一句SQL执行的语句就不要用多条来执行，但是连接的表太多的话，我认为尽量不要超过4张表，过多的表会影响SQL可读性
3、用union all替换 union
当SQL语句需要union两个查询结果集合时，即使检索结果中不会有重复的记录，如果使用union这两个结果集同样会尝试进行合并，然后在输出最终结果前进行排序，因此如果可以判断检索结果中不会有重复的记录时候，应该用union all，这样效率就会因此得到提高。
4、查询select语句优化
在项目中优化得最多，也觉得挺重要的一点就是在任何的地方都不要用select* from a表，你需要查询什么字段就使用什么字段。同时尽量避免在where 后面进行null判断，这个我在项目中·使用过，经过测试，导致引擎放弃了索引，进行全盘扫描
5、关于更新update
在项目中如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。
6、模糊查询like
关键词%你好%，由于‘你好’前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%。
7、多表连接（join）查询（避免子查询）
项目中稍微测试过，详细的查看借鉴
8、针对业务周期性卡顿。
（1） 查看slowlog,分析slowlog，分析出查询满的语句；
（2） 按照一定优先级，一个一个排查所有慢的语句；
（3） 分析top SQL，进行explain调试，查看语句执行；
（4）调整索引或语句本身。
9、数据库参数优化
连接层：设置合理的连接客户和连接方式：
ax_connections # 最大连接数，看交易笔数设置
max_connect_errors # 最大错误连接数，能大则大
connect_timeout # 连接超时
max_user_connections # 最大用户连接数
skip-name-resolve # 跳过域名解析
wait_timeout # 等待超时
back_log # 可以在堆栈中的连接数量
SQL层：
query_cache_size： 查询缓存 >>> OLAP类型数据库,需要重点加大此内存缓存，但是一般不会超过GB。
对于经常被修改的数据，缓存会立马失效。
通常可以加用实用内存数据库（redis、memecache），替代他的功能。
来源：CSDN
作者：ai码农
链接：https://blog.csdn.net/qq13263794420/article/details/104374595