【思考】--慢sql治理/千万级数据量优化

一、前言

就最近一、二个多月所做的工作想仔细记录下，背景是这样：随着业务的迭代，每天都会有大量的告警，如慢sql、接口响应慢、mysql查询连接超时等。每天早上来公司第一件事是梳理检查下是否影响到主流业务功能。其实这些问题总的来说就是：“慢sql治理/千万级数据量优化”。
仔细回想下，这一、二个月的工作挺“脏”的。这个“脏”就是表达这个工作做起来比较麻烦、考虑的细、鱼与熊掌不可兼得，很难有完美的解决方案。
结合这段时间做的工作，针对上述的问题，主要可以从下面几点进行思考【个人见解，在大神们眼里可能是不全面，勿喷】。

按照上面总的归纳，其实在一开始设计表时，就需要考虑业务对应的表具有可扩展性，设计出合理的表，以及表进行查询、DML操作的sql也需要设计完美。另外，索引也需要设计合理。

二、sql语句优化

书写第一个sql语句是关键，拥有可扩展性的sql可以方便后续其他开发人员复用、维护。在考虑表后续可能会数据量暴增时，sql语句尽量减少联合表查询。前期书写一时爽，后续维护只骂娘-----这种事要少做，哈哈哈哈。

一般sql语句要考虑或满足下面情况【后续慢慢补充添加…】：
尽量避免大事务操作，提高并发能力；
尽量避免一次查询大量的数据；
Sql语句要利用到索引查询【