发现问题
业务监控
1、基于 Artharts 运维工具进行线上系统监控。
2、基于 Promethues 进行 MySQL 系统监控。
有一天我们的线上系统的某一个接口突然发生频繁的请求失败、超时等情况经过定位发现是 XXX 接口导致的相关问题，我们怀疑是慢 SQL 问题，并为此进行了排查。
压测
系统上线前我们对某一个接口编写了相关的脚本进行压测 + Grafana 可视化压测结果，发现某一个接口的性能远远达不到我们的上线要求，所以我们对该接口缓慢的原因进行了分析，最后定位到是由于某一个 SQL 没有走索引导致的。
MySQL 慢日志
DBA 同学在查看 MySQL 慢日志的过程中发现有一条 SQL 的耗时明显高于正常值且改表没有较多的 join 操作，所以把该 SQL 单独提取出来进行了分析发现是索引失效导致的。
分析问题
操作系统
1、由于部署 MySQL 的服务器性能较差，可能会导致 SQL 运行缓慢 。
2、由于部署 MySQL 使用的服务器使用的磁盘性能原因导致的。
3、由于部署 MySQL 服务器的 I/O、CPU 负载过大导致性能下降。
MySQL 层面
1、基于 MySQL Work Brench 工具对 MySQL 系统的运行指标进行分析 Network status 、Mysql Status、Innodb Status。
2、基于 SQL 语句进行分析
# 获取数据库连接数
mysqladmin -h localhost -u root -p status | grep "Threads_connected"
# 获取数据库查询数
mysqladmin -h localhost -u root -p status | grep "Queries"
# 查询慢日志中执行时间最长的10条记录
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;
3、查看慢日志文件中是否包含前面监控业务发现接口相关的 SQL 语句，或者明显执行时间过长的 SQL 语句进行分析; 对于发现的 SQL 语句进行分析大致可以分为以下四种情况： 1、SQL 编写不当 (join 没有采用小表驱动大表的理念、深分页、使用 * 查询数据)。
2、索引失效 (使用函数、not in、%like%、or 、隐士字段转换、编码错误)。 3、使用 explain 关键字分析没有走索引 （关注 type/rows/extra 等关键字）。
4、索引建立不当 （索引建立过多、索引的区分度不够）。
5、死锁。
4、MySQL 配置相关问题： max_connections 配置过小 bin-log 日志大小设置不合理 cache 设置不合理 process 设置不合理（在配置文件里面开启慢日志会导致性能略微下降）。
业务层面
1、业务层面出现大事物问题。
2、查询数据量过大、数据总量太多。
3、系统被恶意攻击大量请求直接打入数据库。
4、数据架构设计不合理。
问题及时避免
操作系统层面
1、数据服务器采用集群 + 单独部署的方式，做好相关的性能监控。
2、数据库服务器性能尽量好一点。
MySQL 层面
1、业务代码中的 SQL 语句经量使用 explain 关键字进行检查了之后在使用。
2、上线前对 MySQL 配置情况进行检查。
3、建立索引要符合相关的规范 命名: order_idx_unique / order_id_primary_key 等、索引的区分度尽量要大一些、如果建立关联索引时间字段最好后置、对于字符串考虑建立前缀索引。
4、做好系统监控 + 报警。
业务层面
1、避免大事物问题。
2、热点数据前置。
3、读写分离策略 / 特定数据可以采用强制走主库的方式避免数据同步延迟等情况。
4、分库分表。
5、聚合数据计算采用 fink/spark/hadoop/clickhouse 等大数据技术。
6、热点数据归档 es / clickhouse。
