MYSQL的优化建议

前文：        

        在IT的领域，尤其是作为后端开发，基本处处都是需要跟数据存储打交道，而数据存储最常用的无非就是文件存储、内存存储、数据库存储，而数据库作为持久化数据存储的一种媒介，很多时间，它的效率问题往往会成为客户体验度好坏的一个因素，现在市面上比较热门的数据库一般就是如下几种：结构型数据库（mysql、oracle、sql server等）、nosql（redis、mongodb等），那么在数据库方面的优化，有如下几点建议以供参考。

---

硬件方面（资金充足的情况下可以考虑这么做）：

1.对服务器（电脑）进行扩容（例如增加它的内存条、硬盘的存储空间）；

2.集群布置数据库，以减少单个服务器数据库的访问压力；

3.数据库上云（阿里云、腾讯云等），借助第三方服务商成熟的解决方案维护自己的数据库。

---

编程方面（结合我自身经历过的公司总结）：

 数据库表设计的建议：

        1.在设计数据库时，能指定索引的则要指定索引，尽量让数据唯一的列走索引，如主键等；

        2.对字段的类型大小设置不能盲目过大，例如一个存放省份名字的文本，varchar类型，长度一般在50一般就足够用了，不能一开始就给个varchar(255)，这样会影响操作效率，而且浪费磁盘空间；

        3.减少对blob类型的引用，大文件查询，都很影响效率；

        4.对于一些状态值的字段类型设置，一般建议采用tinyint或int类型，不用使用varchar类型存文本，数据库对数字类型的数据处理是相对由于对文本类型数据的处理；

        5.设置索引方面，要具体问题具体分析，不是索引越多就越好，不能盲目设置索引，要结合实际场景设置。

写法方面的建议：

1.一定要走事务，要开启数据库的事务机制，如mysql可以用它本身的innodb引擎（InnoDB支持事务,MyISAM不支持）；

2.以查询为例：

        a,减少或不要在返回字段中再嵌套子查询，如图，这种情况如果数据表的结果有十条，这个子查询就会执行十次，严重影响查询效率，尽量不要这么写，不然容易被友好问候

select id, (select name from dual2) as name from dual;

        b.在写查询语句时，尽量或减少在select语句外面在嵌套一层或多层查询语句，如图，这样的话，你嵌套多少层，就等同于它执行了多少次

select * from (
    --如果这个语句执行用时1秒，那么在外层嵌套了一层，那么它的查询所花费我的时间就可能是翻倍了
     select * from dual 
) tab  

        c.写查询语句时，where执行顺序是从左往右执行的，在数据量小的时候不用考虑，但数据量多的时候要考虑条件的先后顺序，此时应遵守一个原则：排除越多的条件放在第一个。如图，先执行主键的检索，在执行其他的效率是优于先执行其他后再执行主键索引的。

SELECT * from dual a where a.id = 1 and a.name = '小明';

        d.如果是left join关联查询的，建议数据量小的表作为主表。

        e.并不是所有的字段都通过一条sql查询就很好，有时候强行整合，反而会导致查询效率下降，或者难维护（你见过一千多行的sql查询吗？维护起来是真吐血），所以可以考虑将一条复杂的sql拆分成多条简单的sql去执行，让它们专司其职。

        f.如果查询的字段明确的时候，要具体指定返回的字段，如图，不能直接返回所有，因为这些多余的字段，会影响到查询效率，而且会增加前端方面的阅读成本。

--假设我需要name这个字段，却这样写，就等同于返回了所有字段，增加查询压力
select a.name, a.* from dual

        g.代码方面，减少在for循环里面执行数据库查询。

---

总结： 

这里只是一家之言，数据库优化可以从方方面面入手，具体问题具体分析，困了，未完待续。。。