十年经验倾囊相授,Mysql优化经验,拿走不谢!
举报
香菜聊游戏
发表于 2021/06/23 14:11:10
2021/06/23
【摘要】 最近一直在忙工作的事情,也有点懒,不想写,划水了好多天了,今天就水文一篇,聊聊积累的一些mysql 的优化经验。 大部分的游戏数据库都是使用mysql ,开源,免费是他的法宝,虽然没有oracle 牛逼,但是对于日常的使用,完全够用,所以大多的公司都是使用mysql 作为数据的落地选择,因为之前一直使用的InnoDB 引擎,所以今天今天大概聊一下对数据库的优化原则问题,都是基于InnoDB ...
最近一直在忙工作的事情,也有点懒,不想写,划水了好多天了,今天就水文一篇,聊聊积累的一些mysql 的优化经验。
大部分的游戏数据库都是使用mysql ,开源,免费是他的法宝,虽然没有oracle 牛逼,但是对于日常的使用,完全够用,所以大多的公司都是使用mysql 作为数据的落地选择,因为之前一直使用的InnoDB 引擎,所以今天今天大概聊一下对数据库的优化原则问题,都是基于InnoDB 引擎,希望你能在遇到同样的问题时能解决问题。OK,我们开始吧。
1、查询语句的执行顺序
select[distinct]
from
join(如left join)
on
where
group by
having
union
order by
limit
执行顺序: from where 聚 having order limit
sql 的查询执行顺序我想有些人还是记不住的,我的建议就是自己整理一个简单的记忆短句,然后反复阅读,直至记住,下次再遇到问题的时候自己回想下自己记忆的短句,能解决问题就行了,死记硬背就好,尽量简短。
2、数据类型的选择
• 尽量避免NULL:含NULL复合索引无效. 可为NULL的列会使用更多的存储空间,在Mysql中也需要特殊处理。
TIMESTAMP空间利用比DATETIME小的多,比整形方便处理,整形不会带来任何好处。
IPV4的地址,经常使用VARCHAR(15)来存储。然而它实际是32为无符号整数,不是字符串。用小数点将地址分成四段只是为了让人们容易阅读。
对象关系映射(ORM)系统(以及使用它们的“框架”)通常都是低效的,一些ORM系统会存储任意类型的数据到任意类型的后端数据存储中。这种设计对开发者很有吸引力,因为这使得开发者可以用面向对象的方式工作,不需要考虑数据是怎么存储的。
原则:尽可能小(占用存储空间少)、尽可能定长(占用存储空间固定)、尽可能使用整数。
3、索引优化
主键索引
InnoDB通过主键聚集数据,数据按主键顺序存储,更新主键索引列的代价很高,因为会强制InnoDB将每个被更新的行移动到新的位置
多列索引
一个常见的错误就是为每个列创建单独的索引,这种错误的认知一般都是听了“把where条件里面的列都建上索引”这样模糊的建议导致的。
实际上,在多个列上建立独立的索引大部分情况下都不能提高mysql的查询性能,有时反而会使查询变的更慢。
因为索引需要额外的空间记录,在查询到时候如果索引使用不当,需要同时加载索引和数据,会造成查询慢。
正确的顺序依赖于使用该索引的查询,并且同时需要考虑如何更好地满足排序和分组的需要
4、查询性能优化
1、查询的生命周期
客户端 -> 服务器查询缓存 -> 解析器 -> 预处理器 -> 查询优化器-> 查询执行引擎 -> 存储引擎 -> 数据
2、SELECT语句尽量指明查询字段名称
-
select * 会增加不必要的消耗,如果使用的字段很少,会导致读取的数据量变多,网络传输也会变慢,消耗cpu,所以 select count(1) 优于 select count(*)
-
在表进行修改的时候,代码里的查询字段可能会忘记修改,导致代码报错,是安全隐患。
3、小表驱动大表
1、是否向数据库请求了不需要的数据,减少数据加载和网络传输
2、查询是否扫描了大量不需要的记录(返回的行数/扫描的行数),降低读取数据的时间
总结
• 使用小而简单的合适的数据类型,尽量避免NULL
• 避免过度设计,例如会导致复杂查询的schema设计
• 合理混用范式化和反范式化设计,以空间换时间,适当的冗余带来速度
• 单行访问是很慢的,最好读取的数据块中能包含尽可能多所需要的行
• 当数据量逐渐增大时,不恰当的索引会导致性能急剧下降
要想写一个好的查询,必须要理解schema设计、索引设计等知识。他们之间环环相扣,密不可分。只有综合考虑各方需
推荐
【版权声明】本文为华为云社区用户原创内容,未经允许不得转载,如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
评论(0)