从高明到普通一共有4种优化方式：
1、架构优化：最优解，一般来说在高并发的场景下对架构层进行优化其效果最为明显，常见的优化手段有：分布式缓存，读写分离，分库分表等，每种优化手段又适用于不同的应用场景。
2、硬件优化：有钱能使鬼推磨，性能差了、反应慢了，就更新/迭代，从物理层次高纬度打击，机械硬盘升级固态，一个服务器不够就两个服务器。
3、DB优化：数据库实例参数优化遵循三句口诀：日志不能小、缓存足够大、连接要够用。
4、SQL优化：最次解，就是通过给查询字段添加索引或者改写SQL提高其执行效率
具体架构优化：
1、分布式缓存：更适用于高并发、大数据量大场景。
有句老话说的好，性能不够，缓存来凑。当需要在架构层进行优化时我们第一时间就会想到缓存这个神器，在应用与数据库之间增加一个缓存服务，如Redis或Memcache。
当接收到查询请求后，我们先查询缓存，判断缓存中是否有数据，有数据就直接返回给应用，如若没有再查询数据库，并加载到缓存中，这样就大大减少了对数据库的访问次数，自然而然也提高了数据库性能。
不过需要注意的是，引入分布式缓存后系统需要考虑如何应对缓存穿透、缓存击穿和缓存雪崩的问题。
2、读写分离：用于解决 “数据库读性能问题”。
一主多从，读写分离，主动同步，是一种常见的数据库架构优化手段。
一般来说当你的应用是读多写少，数据库扛不住读压力的时候，采用读写分离，通过增加从库数量可以线性提升系统读性能。
主库，提供数据库写服务；从库，提供数据库读能力；主从之间，通过binlog同步数据。
当准备实施读写分离时，为了保证高可用，需要实现故障的自动转移，主从架构会有潜在主从不一致性问题。
3、水平切分：用于解决“数据库数据量大的问题”。
水平切分，也是一种常见的数据库架构优化手段。
当你的应用业务数据量很大，单库容量成为性能瓶颈后，采用水平切分，可以降低数据库单库容量，提升数据库写性能。
当准备实施水平切分时，需要结合实际业务选取合理的分片键（sharding-key）。
4、SQL 优化套路：
一、查看执行计划 explain sql
二、如果有告警信息，查看告警信息 show warnings;
三、查看SQL涉及的表结构和索引信息
四、根据执行计划，思考可能的优化点
五、按照可能的优化点执行表结构变更、增加索引、SQL改写等操作
六、查看优化后的执行时间和执行计划
七、如果优化效果不明显，重复第四步操作
5、SQL 优化通用技巧：
--> 合理使用索引
索引少了查询慢；索引多了占用空间大，执行增删改语句的时候需要动态维护索引，影响性能 选择率高（重复值少）且被where频繁引用需要建立B树索引；一般join列需要建立索引；复杂文档类型查询采用全文索引效率更好；索引的建立要在查询和DML性能之间取得平衡；复合索引创建时要注意基于非前导列查询的情况
--> 使用UNION ALL替代UNION
UNION ALL的执行效率比UNION高，因为UNION执行时需要排重；
--> 避免select * 写法
执行SQL时优化器需要将 * 转成具体的列；每次查询都要回表，不能走覆盖索引。
-->JOIN字段建议建立索引
一般JOIN字段都提前加上索引
-->避免复杂SQL语句
提升可阅读性；避免慢查询的概率；可以转换成多个短查询，用业务端处理
-->避免where 1=1写法
-->避免order by rand()类似写法
RAND()导致数据列被多次扫描
-->执行计划
要想优化SQL必须要会看执行计划，执行计划会告诉你哪些地方效率低，哪里可以需要优化。通过explain sql 可以查看执行计划
本文有参考如下：
版权声明：本文为CSDN博主「瘦弱的皮卡丘」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ThinPikachu/article/details/122152689