提取网站子页面邮箱,公众号微网站建设认证,app免费制作网站哪个好,网站做权重有用吗背景在当今这个互联网的时代无非要解决两大难题#xff0c;其一是信息安全#xff0c;其二就是数据的存储。而信息安全则是在数据存储的基础之上。一个公司从刚开始成立到发展成一个有上百人甚至上千人团队的时候#xff0c;公司的业务量是呈上升趋势#xff0c;客户及用户… 背景在当今这个互联网的时代无非要解决两大难题其一是信息安全其二就是数据的存储。而信息安全则是在数据存储的基础之上。一个公司从刚开始成立到发展成一个有上百人甚至上千人团队的时候公司的业务量是呈上升趋势客户及用户也会越来越多之前设计的表结构可能会显得不合理表与表之间的联系没有一个稳定的业务功能划分从而表现出来的是相关表的备用字段越来越不够用甚至新加字段最坏的情况就是不同业务表之间会有数据冗杂。从而暴露出一些设计的问题这也就是SQL优化点之一数据库表结构设计的合理性。近年来大数据越来越火而大数据也是为了解决数据的存储的手段之一其目的是从海量的数据中收集到有价值的信息然后存储到数据库中因为数据量大传统的数据库无法储存那么多的信息所以需要分析有价值的信息后再做决定是否持久化。优化点前提必备知识学会是用explain关键词查看SQL语句性能explain好像是从MYSQL5.6.3开始支持 select、update、delete语句分析之前只支持select语句。现在我们普遍都是用5.7所以的话不需要太担心。这里的话不详细讲如何解读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_id20180910242360此时order_id实际占用了14个字节但是这个字段的属性长度是32所以还有18个字节长度是无用的但却占用着内存空间。建立合理的索引索引就是用某种数据结构来查找对应的信息从而减低时间复杂度提高查找效率。建立索引的前提也要明确综合考虑再打算是否需要建立索引毕竟索引是需要占用存储空间的有时候牺牲的空间却换不回时间。优化之二 - 从SQL语句优化方面考虑1. 尽量将要输出的字段写出来不要使用 select * from where xxxxx 这种形式的语句。我在这测试时是使用*代替但是记住在生产环境上尽量将字段替代*。2. 合理使用连表查询不仅是表的连接需要较大的内存消耗另外一方面如果表设计的不是很合理也会导致索引无效从而造成极坏的结果。3. 查询的时候要注意是否走索引假如你在name列建立了一个 name_index索引查询你使用 name Like%xxxx 或者 name Like%xxxx% 这种模糊查询那么此时可能就不会走索引你应该这样 name Likexxxx% 。以下就是实际的一个例子 建立索引-- 为cust_third_acct 建立一个普通索引alter tablecust_infoadd index cust_third_acct_index(cust_third_acct); 通过SQL查询信息 select * from sp_tunnel_user where cust_third_acct like0200%; 以下就是满足查询条件的部分信息 分析Like%xxxx%的查询性能 select * from sp_tunnel_user where cust_third_acct like%0200%; 通过Explain性能分析命令可以知道在这种查询条件下并没有执行索引typeall表明该语句执行的时候进行的是全表扫描虽然我们在 cust_third_acct 这个字段建立了索引但是 possible_keysnull 则说明了 用 like%0200% 这种形式的条件是一定无法使用到 cust_third_acct_index 这个索引。 分析Likexxxx%的查询性能 select * from sp_tunnel_user where cust_third_acct like0200%; 与b查询语句相比这个查询的 possible_keyscust_third_acct_index 这说明这个语句可能会用到 cust_third_acct_index 这个索引但是keynull表明在实际的执行过程中并没有用到 cust_third_acct_index 索引刚才我们也说了这种条件查询只是可能会走索引但是不一定发生这个跟MySQL的存储引擎相关但是我们使用的时候尽量以这种方式去查询。 4. 使用索引遵循最佳左前缀特性建立联合索引的时候将常用的属性放在左边。比如我们需在在一张表的 cust_id 和 cust_tp 建立一个联合索引 cust_id_type,设定cust_id不是唯一 是比较常用的那么我们就将cust_id放在左边。建立联合索引-- 为cust_id与cust_tp建立一个联合索引alter tablecust_infoadd index cust_id_type(cust_id,cust_tp);5.使用符合索引的时候需要注意使用联合索引需要从左往右不间断索引才会生效也就是说联合索引使用的时候必须要连续但不要求全部使用。如以上4我们建立了一个 cust_id_type 索引,当我们在使用的时候如果where条件中只使用了 cust_id,那么也会走索引如果where条件中只使用了 cust_tp那么这条语句不会走索引以下就是一个实例 select * from sp_tunnel_user where cust_id8888888888 and cust_tp04 当查询条件用到cust_id与cust_tp两个字段并且cust_id在前面的时候就会用到联合索引通过 keycust_id_type可以看到实际执行过程中是用到索引了的。 select * from sp_tunnel_user where cust_id8888888888 ; 当查询条件只用到cust_id一个字段时也用到了联合索引通过 keycust_id_type可以看到实际执行过程中是用到索引了的这就是左前缀原则。 select * from sp_tunnel_user where cust_tp04 ; 当查询条件只用到cust_tp一个字段时但却没有用到索引通过 keynull 可以看到实际执行过程并没有用到索引这也是左前缀原则。 优化之三 - 读写分离与分库分表当数据量达到一定的数量之后限制数据库存储性能的就不再是数据库层面的优化就能够解决的这个时候往往采用的是读写分离与分库分表同时也会结合缓存一起使用而这个时候数据库层面的优化只是基础。读写分离适用于较小一些的数据量分表适用于中等数据量而分库与分表一般是结合着用这就适用于大数据量的存储了这也是现在大型互联网公司解决数据存储的方法之一。至于怎么读写分离、怎么分表、怎么分库这里不做过多的阐述后续文章会有相关知识分享。原文出处https://www.cnblogs.com/wind-june/p/9638356.html
