首先，公司有专业的监控平台，比如说Prometheus + Grafana。会监控数据库的QPS，慢查询的数量，连接数这些关键的指标，一旦告警响了，或者我们每周去查看的时候，发现某个库的慢查询突然增多，或者CPU的使用频率飙升了，我就知道有问题了，到底是什么SOL语句拖后腿，首先啊去看慢查询日志，这个是最直接的，我们会把它打开，设置一个合理的阈值，比如说超过1秒的SQL语句，都会记录下来。然后通过mysqldumpslow，或者说一些日志分析工具，我们立马就能把有问题的SQL语句揪出来，还能看到它的执行次数，平均耗时，做到心里有数，找到问题SQL以后。
我的下一个动作一定是掏出explain，去看它的执行计划，盯紧几个关键的字段，type 这是最重要的，他们至少是range级别，理想状态呢是ref或者 const，如果看到是ALL或者说index，那么基本呢就是需要去优化了，然后就是key，他实际用到了哪个索引，如果这一栏为空，那么就是没有用索引，还有rows预估扫描的行数，这个数字越大，那么可能问题也就越大，速度也就越慢，还有附加信息，如果出现像Using filesort文件排序，或者说用了临时表，那么我就特别需要注意，这个两个往往是性能的杀手，它会拖慢我们的整个性能，根据explain的结果，我会从几个方面去入手。
第一，索引优化，比如说针对WHERE条件，ORDER BY GROUP BY的字段，考虑建联合索引，会注意是否满足最终匹配原则，把区分度比较高的字段放在前面，然后避免索引失效，比如说索引字段是否做函数操作 计算，或者说用了is null等之类的一些语句
第二，覆盖索引，让查询只需要扫描索引树，就能拿到所有的数据，避免回表，性能提升呢，比如说我们平时会避免使用*。
第三，我们会去进行SOL的改写，核心思想呢，就是减少扫描的数据量，比如说不用SELECT * ，就是减少回表，比如说如果业务允许的话，我们会加一些limit的限制，然后对于一些复杂的关联查询，
会把它拆 拆成多个单表查询，然后在Java代码里面去做数据组装，虽然会发送多次请求，但比一个巨大无比的连接查询表要快，而且更加利于缓存和扩展性，还有我们会注意in和not in的用法，
数据量比较大的时候呢，会去用EXISTS或者 JOIN来代替。
第四，就是数据库和表结构的设计了，如果单表的数据量比较大，那么我们就可能需要考虑分库分表，或者说用一些组件来做，然后呢接下来根据业务特点，我们需要做一些数据归档，冷热数据迁移等等，
保证我们主库的表体积是可控的。
最后一步啊，效果验证，我改完SQL或者说优化完索引以后，绝对不会直接上生产，我们一定会在预发布环境，然后或者压测环境，用改造前同样的数据和同样的请求，去跑一下，看一下是否生效。4
