优化之一 - 从数据库设计方面考虑
优化之二 - 从SQL语句优化方面考虑
优化之三 - 读写分离与分库分表
背景在当今这个互联网的时代无非要解决两大难题，其一是信息安全，其二就是数据的存储。而信息安全则是在数据存储的基础之上。一个公司从刚开始成立到发展成一个有上百人甚至上千人团队的时候，公司的业务量是呈上升趋势，客户及用户也会越来越多；之前设计的表结构可能会显得不合理，表与表之间的联系没有一个稳定的业务功能划分，从而表现出来的是相关表的备用字段越来越不够用甚至新加字段，最坏的情况就是不同业务表之间会有数据冗杂。从而暴露出一些设计的问题，这也就是SQL优化点之一：数据库表结构设计的合理性。近年来大数据越来越火，而大数据也是为了解决数据的存储的手段之一，其目的是从海量的数据中收集到有价值的信息然后存储到数据库中，因为数据量大传统的数据库无法储存那么多的信息所以需要分析有价值的信息后再做决定是否持久化。
优化点前提必备知识
学会是用explain关键词查看SQL语句性能，explain好像是从MYSQL5.6.3开始支持 select、update、delete语句分析，之前只支持select语句。现在我们普遍都是用5.7，所以的话不需要太担心。这里的话不详细讲如何解读explain输出的性能信息。请参看博客文档：《MySQL优化之Explain命令解读》
优化之一 - 从数据库设计方面考虑
表与表之间的业务联系要明确：表之间其实是有业务联系的，比如：class(primary key:class_id,所有班级信息表)、student(primary key:student_num,所有学生信息表)、student_class(primary key:stu_class_id,所有学生所在班级信息表)着三张表，如果现在需要一张老师对应哪个班级的班主任的信息表；那么此时正确的方法是：新建 teacher、teacher_class表，而不是直接把老师的信息插入到student表中然后用一个字段来标识是老师还是学生。可能你看到这个你会想 “我肯定会按正确的那种方式啊”，但是这只是举一个例子，其实在实际项目开发过程中表与表结构往往不会那么单一，这个时候你就会犯错误而用字段标识。但是也不能说是不能用字段标识，这个要看字段标识的两种信息对应的业务是否有交叉点来取舍。
表字段尽量使用数值型：因为数值型字段在MySQL底层应用的时候相比string类型的话性能更好；具体为什么性能更好就需要了解MySQL底层机制了，反正记住这点就好。
属性尽量使用定长：以减少占用储存空间；如果你定义了一个 order_id varchar(32) ,当在存储的时候有一条记录的order_id=20180910242360，此时order_id实际占用了14个字节但是这个字段的属性长度是32，所以还有18个字节长度是无用的但却占用着内存空间。
建立合理的索引：索引就是用某种数据结构来查找对应的信息，从而减低时间复杂度提高查找效率。建立索引的前提也要明确，综合考虑再打算是否需要建立索引，毕竟索引是需要占用存储空间的，有时候牺牲的空间却换不回时间。
优化之二 - 从SQL语句优化方面考虑
1. 尽量将要输出的字段写出来；不要使用 select * from where xxxxx ；这种形式的语句。我在这测试时是使用*代替，但是记住在生产环境上尽量将字段替代*。
2. 合理使用连表查询；不仅是表的连接需要较大的内存消耗另外一方面如果表设计的不是很合理也会导致索引无效从而造成极坏的结果。
3. 查询的时候要注意是否走索引：假如你在name列建立了一个 name_index索引，查询你使用 name Like'%xxxx' 或者 name Like'%xxxx%' 这种模糊查询，那么此时可能就不会走索引；你应该这样 name Like'xxxx%' 。以下就是实际的一个例子：
建立索引：
-- 为cust_third_acct 建立一个普通索引
alter table
cust_info
add index cust_third_acct_index(cust_third_acct);